AI Agent Memory Migration: 4 Options by Memory Type

An engineer replacing six months of agent memory needs a destination that preserves the identity, time, source episodes, or relations the workload uses. Map each memory type to a documented extraction and import path before switching clients. This guide compares destinations by those preservation requirements and a representative migration test.

Key takeaways

What should you compare before moving six months of memory?

Compare both the shape of your existing records and the path into the target system. A search or read endpoint lets you inspect records; a migration path also needs enough identity, time, scope, and metadata to rebuild the meaning those records had in your agents.

Treat a migration as a data conversion project, not a database swap. A team moving six months of records should first inventory which entries are original conversations and which are derived memories, then map source identities to destination scopes and preserve timestamps, source references, and metadata where available. A stable record ID makes deduplication and retry behavior easier to test, while a mapping table makes it possible to explain how one old record became one or more new records.

Treat copied user_id or agent_id labels as data, not authorization: map source principals and tenant permissions to destination access policies, and test that one user cannot retrieve another user's records. Scoped search filters alone do not prove access control.

Distinguish the source event time from the time it was imported, and preserve temporal validity (when a fact was true) separately from recorded time (when the system learned or stored it), where those fields are available.

Record pagination cursors or other extraction state and reconcile expected totals so a successful-looking export is not mistaken for a complete one; also map source deletions or tombstones to destination removals or equivalent suppression.

Keep extraction, import, and agent access as separate checks. The Model Context Protocol tools specification defines how an MCP client discovers and calls tools exposed by a server; that connection lets an agent interact with a service, while historical data still needs its own export and write path. Test both tasks: can the target agent call the knowledge service, and can the migration process represent the old records correctly inside it?

Score usefulness separately from portability. The independent LoCoMo long-term conversation-memory benchmark uses conversations averaging 600 turns and 16,000 tokens across as many as 32 sessions, with tasks including single-hop, multi-hop, temporal, and adversarial questions. Use these task categories as a starting point for a representative test set, with questions drawn from your own data and agent workflows.

A practical move starts with a bounded sample rather than a full cutover:

1. Inventory the records: Group a representative sample by memory job, source format, identity, timestamp, metadata, and access scope.
2. Extract a stable snapshot: Retain record IDs and original content, capture pagination state, and reconcile pages and record totals to check extraction completeness; log available fields and deletion or tombstone records.
3. Map the fields: Decide how source IDs, user or agent ownership, event time, recorded time, temporal validity, relations, provenance, and deletion or tombstone signals become destination records; distinguish source event time from import time.
4. Load a test set: Import the sample into an isolated destination and replay representative questions from the old workflow.
5. Compare outcomes: Check retrieval usefulness, temporal interpretation, source traceability, duplicates, and access behavior before directing production agents to the new layer.

For quality tests, choose the retrieval settings with a tuning set and then check the selected setup against held-out questions.

When should you evaluate Mem0?

Evaluate Mem0 first when most of your stored state is tied to a user, agent, application, or run and your current system can map those identities cleanly. Mem0's entity-scoped memory API accepts identifiers in a filters object for client.search, client.get_all, and exports. On the default extraction path, Mem0 attributes each extracted fact to the user or agent that stated it, while app_id and run_id are stored on every memory produced by the call.

Those scopes give a migration engineer useful grouping keys for a user-personalization workload. Mem0's export API supports structured AND/OR filters over user_id, agent_id, app_id, and run_id. Map each target record to the intended identity scope, then verify scoped retrieval and metadata after transfer.

Mem0's memory update guide distinguishes OSS SDK behavior from Platform operations. Pin the edition and interface used for export and correction; map only the text, metadata, and time fields that that interface actually returns or accepts.

When does Zep fit time-aware conversational memory?

Evaluate Zep when a useful answer depends on what was said, when it was said, and how conversation facts changed over time. Zep's episode records store each episode verbatim alongside the entities, edges, and summaries derived from it. Zep's SDK can list recent episodes for a user, fetch one by UUID, list episodes for a document, and search a graph for episodes.

Preserve each available episode identifier and time or relationship field in your migration map, then test target answers to questions about event order and changed facts. A useful sample could include a preference that changed, a plan discussed and later revised, and two sessions that refer to the same person or project.

Graphiti's documentation identifies it as an open-source framework for temporal knowledge graphs that power Zep; it incrementally updates graphs as episodes arrive, allowing facts and relationships to evolve with source data. That makes Zep a good shortlist candidate when your application needs to reason over evolving conversation context rather than retrieve only a standalone preference.

Collect a representative set of episode records and map each one into the structure your destination accepts. Compare the imported episode text, available timestamps, entities, and changing relations with the source, then replay temporal questions through the target agent.

When does Cognee belong on the shortlist?

Put Cognee near the top when your objective is to move records from another memory provider and then build or preserve a knowledge graph. Cognee’s official COGX exchange format is described as a way to import agent memories from Mem0, LangMem, Letta, Zep, or Graphiti, and to export, back up, or move Cognee memory.

Cognee's memory migration guide uses source adapters to read provider exports and emit COGX records. When an adapter uses stable source IDs, Cognee matches records by (external_system, external_id) and avoids duplicates when the same export is imported again. Carry user_id, agent_id, session_id, or run_id scopes and created_at or updated_at values when the source export includes them; place other fields in record metadata.

The guide distinguishes preserving memory from rebuilding its graph. For Mem0's short memory records, Cognee's re-derive mode rebuilds graph knowledge when that is the goal; preserve stores raw records without LLM calls, and a later cognify() step builds the graph for recall. These are different migration goals, not a guarantee of lossless equivalence; use only documented adapters and import paths, and do not assume an undocumented importer exists.

Use Cognee when those documented adapters and COGX mapping match your source provider and graph-oriented destination. A sample import can then test record counts, repeated-run behavior, preserved metadata, and whether graph-derived answers remain faithful to the original source.

When is AKB a relevant destination?

Choose AKB when the new job is shared organizational knowledge for agents, rather than preserving only isolated user memories. AKB provides agents with shared organizational knowledge through MCP, with versioned knowledge, documents, tables, files, hybrid semantic and keyword retrieval, and explicit relations. Those records give developers and knowledge teams a destination for agent-readable company information that can also represent links between concepts.

The current AKB README describes a PostgreSQL-native revision store and recommends Native for new installations. Explicit Bare Git installations remain supported for existing deployments. Confirm history, recovery and export against the selected backend; a change in installation defaults does not migrate an existing vault.

AKB's agent tools let agents read and write with akb_put, akb_search, akb_browse, and akb_relations, with document revision history; table, file, and relation preservation need separate tests. As of October 14, 2026, the AKB repository lists the akb-sessions plugin as capturing a coding session as structured notes, which suits teams turning recurring work and decisions into shared knowledge for coding agents. Its core is a read/write knowledge store, so collection and ongoing curation should be planned as separate operating work.

For a migration from Mem0, Zep, or another memory store, treat source export and AKB knowledge authoring as distinct steps. Before promoting personal conversation into broader organizational knowledge, confirm that the destination audience is permitted to see it and require an appropriate review. Exclude secrets and personal data that is not needed for the shared knowledge purpose.

Convert only approved records into a document, table, file, or explicit relation, then use AKB's read/write tools to test agent retrieval. This approach suits teams that want the destination to serve multiple agents or knowledge workflows from maintained, versioned knowledge, while a user-profile memory service may remain the better fit when each record is personal and scoped to an individual. A platform lead can evaluate AKB as a memory-only knowledge service alongside the current execution environment, then separately decide whether to change the agent runtime.

Which option should you evaluate first?

Choose the first candidate based on the shape and ownership of the records you need to keep.

A team can also split the destination by record purpose. Keep personal preferences in a user-scoped memory system when the data belongs to one user, while curating durable decisions or reference facts into shared organizational knowledge when many agents need them. That separation gives each record a clearer owner and retrieval context than copying every old memory into one undifferentiated store.

Test the destination mapping before cutover

Map original episodes, extracted facts, user/agent identifiers, time bounds, and relations to the fields the destination actually preserves. Rehearse a small export and import with documented interfaces; a Bare Git export path should not be described as a Native vault exporter. The README explicitly limits its Git-tree OKF exporter to Bare Git vaults. A portable document bundle, a full backup, and a migration into another product have different coverage.

Use this proposed cutover evidence record before switching agent traffic. Define a limited rollback window in advance; the fallback must reconcile deletions and revocations so rollback cannot reintroduce removed material, and permission checks must be tested on the fallback path:

Counts and checksums detect some omissions; representative task and access tests establish the remaining acceptance evidence. Keep migration work, latency and rebuild costs separate from query quality. These are tests to perform, not vendor migration guarantees.

Related background: Planning an Exit from an Agent Knowledge Platform

FAQ

Related reading

Which Sources Belong in an Agent Knowledge Base First?

October 12, 2026

Where Human Approval Belongs in Automated Knowledge Cleanup

October 12, 2026

Tracing an Agent Answer Back to a Source Version

October 12, 2026