Memory for Every Agent Stack

Acme runs a LangGraph support agent, a LiveKit voice line and an n8n workflow that files tickets. Until now, giving all three the same memory of a customer meant writing three integrations against the REST API, each with its own retry logic and its own way of naming the customer.

Release 2.8, published today, replaces that work with official packages for the frameworks, coding agents, voice stacks and automation tools those systems run on. It also changes what conversation capture stores, and it adds one-command migrations from three other memory services.

What release 2.8 includes

Agent frameworks

Packages for LangChain, LangGraph, the Vercel AI SDK, CrewAI, Mastra, the OpenAI Agents SDK, LlamaIndex, Google ADK, Pydantic AI, AutoGen, AG2, Microsoft Agent Framework, Strands, NVIDIA NeMo Agent Toolkit, Agno, CAMEL-AI, ChatDev and Eve, plus an AWS Bedrock reference architecture.

Each one plugs into its framework's own extension point, such as a chat history class, a store, a middleware or a session. A few examples: MemorySyncChatMessageHistory and create_memorysync_tools for LangChain, MemorySyncStore and MemorySyncMemoryMiddleware for LangGraph, createMemorySyncMiddleware for the Vercel AI SDK, MemorySyncStorage for CrewAI, withMemorySync for Mastra and MemorySyncSession for the OpenAI Agents SDK.

Coding agents

One plugin package covers Claude Code and Cowork, Cursor, Codex, OpenCode, Devin and Windsurf, VS Code, OpenClaw, Hermes Agent and Antigravity. It ships with a building-with-memorysync skill that teaches an agent how to integrate MemorySync correctly on the first try. The plugins live in memorysync-plugins on GitHub, and the Claude Code walkthrough shows one end to end.

Voice

livekit-memorysync, pipecat-memorysync and elevenlabs-memorysync run recall under a hard time budget, so memory never delays a reply. If recall is slow, the turn goes ahead without it.

Automation and platforms

n8n nodes (n8n-nodes-memorysync), a Zapier app, a Dify plugin and a Flowise node, so a workflow can store and recall facts about a customer without custom code.

Observability

opentelemetry-instrumentation-memorysync records every memory operation as an OpenTelemetry span, and AgentOps and Respan show those spans beside your model calls. Memory content is excluded from spans by default.

Popular stacks at a glance

The packages most teams start with, and where their guides live. Docs paths are on docs.memorysync.io.

Whichever you pick, the memories land in the same place. A fact Acme's voice line learns about customer-7 is there when the LangGraph agent searches for that customer, as long as both use the same project and the same end-user id for them. Agreeing on that id across services matters more than which package each service uses.

Rules every adapter follows

The packages target very different frameworks, but they share a handful of design rules:

• Tools never raise. Memory tools return failures as readable results instead of exceptions, so a memory outage cannot abort an agent run.
• Writes are idempotent. A retried save, a re-run graph node or a reconnected voice turn is recognised, so nothing is stored or extracted twice.
• Read-only modes exist. Tool sets can be built to expose only search and list, for an agent that should consult memory but never change it.
• Every call is scoped to one end user. A delete issued for one customer cannot reach another customer's memory.
• Hooks cannot break a session. The coding-agent plugin's hooks exit cleanly on every failure, so memory being down never interrupts your editor.

In LangChain, scoping and the read-only mode look like this. The tools come from one factory call, and read_only=True returns only the search and list tools:

from langchain.agents import create_agent
from langchain_memorysync import create_memorysync_tools

# add, search, list, update and delete, all scoped to customer-7
tools = create_memorysync_tools(end_user_id="customer-7")
agent = create_agent(model, tools=tools)

# search and list only, for an agent that must not modify memory
read_tools = create_memorysync_tools(end_user_id="customer-7", read_only=True)

The LangChain walkthrough builds a full agent around these tools.

Facts, not transcripts

Since September 2, every integration that captures conversations stores curated facts instead of transcripts. Turns are distilled server-side by the same extraction pipeline the connectors and the API use, so a voice call, a LangChain agent and a direct add_turn call all produce the same kind of memory.

A single user turn such as I am a backend engineer at a logistics startup, I write mostly Go, and I am training for a half marathon in March. becomes four memories: Works as backend engineer, Works in logistics industry, Writes mostly in Go and Training for half marathon in March. Each can be found, superseded or deleted on its own.

Surfaces whose job is to replay history are the exception. LangChain chat history, the LangGraph store and OpenAI Agents sessions stay byte-exact, because those frameworks read back exactly what they wrote.

If you call the API yourself, the same advice applies: send only user turns. Assistant, system and tool turns store nothing but still count as one add each.

Imports and migrations

Moving existing data in is now a supported path instead of a script you write:

• Background import jobs. create_import() uploads a whole JSON or JSONL file as one job, and get_import() reports its progress, for datasets too large to send fifty records at a time through bulk_add().
• Idempotent `client_ref`. Every record can carry your own id, up to 128 characters. Re-sending it returns a skipped response with reason already_ingested and the ids the first write produced, so an interrupted import is safe to re-run.
• One-command migration from Mem0, Supermemory and Zep, with a dry run first.

from memorysync import AddSkippedResponse, MemorySyncClient

ms = MemorySyncClient(api_key="...", base_url="https://api.memorysync.io", end_user_id="customer-7")

ms.add("Prefers phone calls to email for urgent issues.", client_ref="crm-note-8812")
retry = ms.add("Prefers phone calls to email for urgent issues.", client_ref="crm-note-8812")

if isinstance(retry, AddSkippedResponse):
    print(retry.reason, retry.memory_ids)  # already_ingested, plus the first write's ids

The migrations run from the CLI:

# Preview a Mem0 export: reads the file, writes nothing
memorysync migrate mem0 --file mem0_export.json --dry-run

# Run it
memorysync migrate mem0 --file mem0_export.json

# Supermemory and Zep can be read from their APIs directly
memorysync migrate supermemory --key $SUPERMEMORY_API_KEY --dry-run
memorysync migrate zep --key $ZEP_API_KEY --dry-run

Each Mem0 record lands under its Mem0 user_id as the end user, with its Mem0 id sent as client_ref, so a second run skips what already moved. Zep thread ids become session_id. Supermemory container tags that start with user_ become the end user, and --scope-tag-prefix handles other conventions. In application code, Mem0's search becomes query, top_k becomes k, and the user moves from a filter to the end-user header. The guides for Mem0, Supermemory and Zep cover each format.

Accounts, CLIs and fixes

Two account changes from August are part of this release too. An agent can sign itself up and a person can claim the account later, and the Node and Python CLIs are interchangeable and share stored keys.

Fixes in 2.8:

• The v1 forget and summarize operations honour the API key's environment.
• Distilled facts no longer appear as extra transcript entries.
• Replayed histories keep every turn.

Find your stack

Browse the integrations catalog for your framework, coding agent, voice stack or automation tool, and follow its guide from there.