Portable agent memory is durable memory that can move between agent clients without losing source lineage, scope, or delete handles. Put the memory layer outside the model and expose it through open delivery surfaces, so Claude Code, Cursor, Codex, Gemini CLI, Windsurf, and future clients can recall the same facts.
Last updated: June 20, 2026.
What makes agent memory portable?
Portable memory has three boundaries: the source boundary, the schema boundary, and the client boundary. The source boundary says where the remembered fact came from. The schema boundary says how the memory stores source ids, tenant ids, timestamps, lifecycle state, and deletion handles. The client boundary says how an agent asks for memory.
The Model Context Protocol introduction defines MCP as an open standard for connecting AI applications to external systems. That helps with the client boundary because multiple tools can call one server. The MCP architecture overview is more precise: a host connects through clients to servers that expose tools, resources, prompts, and transports. A memory server can use that shape, but MCP alone does not decide what should be remembered or how it can be exported later.
Treat portability as a data contract, not a launch slogan. If a vendor says the memory is portable, ask for the export object, the source references, and the client configuration needed to read it elsewhere.
Why does memory lock-in happen?
Lock-in happens when a memory is saved inside the client that generated it, inside an opaque vendor profile, or inside a vector store with no source lineage. The team can keep chatting, but it cannot inspect, migrate, or delete the memory with confidence.
Common lock-in patterns look like this:
| Lock-in pattern | What breaks | Better portable shape |
|---|---|---|
| Client-only memory | Switching tools loses recall | Store memory in an external source-aware service |
| Raw chat dump | Useful facts are buried in noise | Write scoped facts with source ids and lifecycle metadata |
| Vector-only export | Embeddings move but citations do not | Export source artifacts plus derived artifacts |
| Vendor-only API | One client can read memory | Use MCP, REST, or CLI delivery surfaces |
| No delete handle | A memory cannot be targeted | Store stable ids for source and derived artifacts |
LangChain’s memory concepts separate short-term conversation state from long-term memory. That distinction matters here. Short-term state is naturally client-shaped. Long-term memory should be shaped around the sources and policies the organization controls.
How should you design a portable memory record?
A portable memory record should be boring. It should include a stable id, tenant or workspace scope, source reference, memory type, text, lifecycle state, created and updated dates, and a deletion target. If a system cannot export those fields, you may be able to move text but not memory.
Use this minimum contract:
| Field | Why it matters |
|---|---|
memory_id | Lets systems refer to one remembered fact |
tenant_id or workspace scope | Prevents cross-tenant recall during migration |
source_id and source URL/path | Lets the target system cite and inspect evidence |
memory_type | Separates fact, event, preference, instruction, and source artifact |
lifecycle_state | Marks current, superseded, deleted, or draft |
supersedes_id | Preserves replacements instead of silently merging facts |
delete_handle | Lets a later erasure request target the correct artifacts |
The OpenAI conversation state guide describes conversation state as something applications manage. Portability follows from that application-level responsibility: the product must decide which state becomes durable memory and how it leaves the system.
How do you migrate memory between frameworks?
Start with sources, not embeddings. Export original documents, transcript segments, tickets, pages, and metadata before exporting summaries or vectors. Then rebuild derived artifacts in the target system so embeddings, indexes, and summaries match the new retrieval stack.
A safe migration sequence is:
- Export source artifacts and memory records with ids and scope.
- Export lifecycle relationships such as supersession and deletion tombstones.
- Re-import source artifacts into the target memory system.
- Rebuild summaries, tags, embeddings, and retrieval indexes.
- Run a recall spot-check using known questions.
- Run a deletion spot-check for one memory that should not return.
Do not treat a vector database dump as a complete migration. Embeddings without source lineage are hard to debug and harder to delete.
Where does MCP fit in portability?
MCP is the strongest current client portability layer for agent memory because it lets many clients call the same server shape. The protocol still leaves memory policy to the server. A memory server must expose useful tools: search, retrieve, ask, save, append, inspect, and delete or disable memory.
Answer Engine uses this pattern by exposing memory through the answer-engine-mcp server and through REST and CLI surfaces. The same library can be queried from a coding agent, a command line, or an application integration. Read What is an MCP memory server? for the server shape and REST vs MCP vs CLI for delivery tradeoffs.
What should you ask vendors about portability?
Ask these questions before memory becomes expensive to move:
- Can I export source artifacts and derived memories separately?
- Does the export preserve tenant, library, user, and visibility scope?
- Can I see which memory replaced another memory?
- Can I delete a single exported memory and verify it does not retrieve?
- Can a different agent client use the same memory through MCP or API?
- Can I migrate without copying private customer data into a model-training path?
If the answer is “we store it for you,” keep asking. Portability is proven by the export and the next-client test.
What should you read next?
Start with Agent Memory: The Complete Guide, then read Memory is not RAG is not fine-tuning and the Memory Leaderboard. Keep the Agent Memory Glossary open for the exact definition.