2026 Best Agent Memory Open-Source Projects Compared

Mem0 is the first project to evaluate when you need a lightweight, general-purpose memory layer. Choose Letta when the agent itself must remain stateful across sessions, Zep when changing relationships and time-aware facts are central, and Semantica when explainability, decision lineage, and context-graph reasoning matter most.

The correct order is simple: define what your agent must remember, classify the memory model, then run a small dual-track test before migrating production data.

Last updated August 14, 2026. Project status, deployment boundaries, dependencies, and architecture claims were checked against the official repositories and documentation available on this date.

This guide is for:

• Developers adding long-term memory to chat or task agents.
• Enterprise teams that need self-hosting and data control.
• Architects comparing graph memory with stateful-agent runtimes.

Start by defining the memory problem

The phrase “Agent Memory” covers several different requirements. A customer-support agent may need to remember a user’s preferred language. A research agent may need a time-ordered evidence trail. A coding agent may need persistent task state, tool results, and editable instructions.

Those are not the same problem.

Before comparing projects, classify your data into five categories:

A common architecture mistake is to store every message in a vector database and call that “memory.” Vector retrieval can help find semantically related text, but it does not automatically provide current state, temporal validity, causal links, permission boundaries, or reliable deletion.

If your requirements contain words such as “before,” “after,” “approved by,” “superseded,” or “explain why,” a plain similarity layer is unlikely to be enough by itself.

Compare the four abstraction layers before scoring them

The four projects do not compete at exactly the same layer.

Mem0 is primarily a memory layer that can be embedded as a library or deployed as a self-hosted server. Its documented model focuses on adding, searching, updating, and configuring memory components such as the LLM, embedder, vector store, and reranker. The official documentation describes both library and self-hosted server paths. Read the official Mem0 open-source overview.

Letta is closer to a stateful-agent platform. Its documentation and repository describe agents with advanced memory that can learn and improve over time. The project was previously known as MemGPT, so older tutorials and migration notes may use that name. Check the official Letta repository and current Letta documentation.

Zep should be separated from Graphiti. Graphiti is the open-source temporal context-graph framework associated with Zep. Zep’s commercial context platform adds capabilities beyond the open-source Graphiti component. The official product documentation presents Graphiti as the framework and Zep as the broader context platform. Review the official Graphiti repository.

Semantica is positioned as a semantic and accountability layer around an existing AI stack. Its documented context module includes agent memory, context graphs, decision tracking, causal chains, provenance, policy enforcement, and multi-hop retrieval. That makes it less useful to treat Semantica as merely another vector-memory package. Read the official Semantica context documentation.

Do not rank these four with a single “best memory” score. A lightweight preference store and a decision-audit graph have different success criteria.

Evaluate retrieval by the question your agent must answer

The retrieval path determines what your agent can reliably remember.

Mem0: efficient general-purpose memory operations

Mem0 is a reasonable first candidate when your agent needs to extract durable facts from conversations and retrieve them later. Its open-source documentation describes support for library use, a self-hosted server, configurable LLM and embedding providers, vector stores, and optional reranking. The documented default library setup uses a local Qdrant path for vector storage and SQLite for history, while the server setup uses PostgreSQL with pgvector by default. These are defaults, not universal requirements.

The main risk is not installation. It is memory quality. If the extraction prompt incorrectly turns a temporary statement into a permanent preference, the agent can repeatedly make the same mistake. You need tests for false memories, conflicting facts, user corrections, and deletion requests.

Letta: stateful memory belongs to the agent runtime

Letta is the stronger fit when your agent needs a persistent identity, editable memory blocks, tool access, and a runtime that manages state over multiple interactions. Its official examples create agents with memory blocks such as human and persona information, while the platform documentation focuses on building stateful agents rather than adding an isolated retrieval endpoint. Review the official Letta platform documentation.

The key distinction between Zep and Letta is therefore architectural. Zep and Graphiti organize changing facts and relationships in a temporal graph. Letta organizes an agent that acts, reads, writes, and updates its own state. You can use a graph with a stateful agent, but they solve different primary problems.

Choose Letta when “what is this agent currently doing?” matters more than “which historical entities are connected?”

Zep and Graphiti: time and relationships are first-class

Graphiti is designed for temporal context graphs. Its repository describes entities, relationships, episodes, custom types, provenance, hybrid search, and historical validity windows. It also documents incremental updates rather than requiring a complete graph rebuild for every change.

This makes Zep’s open-source boundary important. Graphiti can be run locally with supported graph backends, but the broader Zep platform is not identical to the open-source component. You should record which features are available in the version and deployment mode you select instead of assuming that “Zep” means every platform feature is self-hostable.

Semantica: retrieval includes reasoning and provenance

Semantica’s documented context layer includes vector-backed agent memory, context graphs, decision objects, causal relationships, provenance, policy checks, and hybrid retrieval. Its AgentMemory interface supports storing and retrieving memories, deletion, clearing conversation memory, and conversation history. Its broader graph layer is aimed at explaining how facts and decisions connect.

That extra structure has a cost: you must define entities, relationships, decision records, and policy boundaries clearly enough for the graph to remain useful. If your application only needs “remember that this user prefers dark mode,” Semantica may add unnecessary modeling overhead.

Test writing, updating, conflict handling, and forgetting

A production memory system is not successful because it can retrieve one relevant sentence. It must also know when not to remember, when to update, and when to delete.

Use the following five-step test sequence for every candidate:

1. Write a stable fact.
   Add a durable preference, such as a preferred output format, and verify that it can be retrieved in a later session.

2. Write a temporary fact.
   Add a short-lived constraint, such as a deadline for one task, and check whether it is incorrectly promoted to a permanent user preference.

3. Create a conflict.
   Store “the user prefers Python” and later store “the user now prefers Rust.” Check whether the system preserves history, replaces the current value, or returns both without ranking them.

4. Invalidate the old value.
   Ask a time-sensitive question after the update. A correct system should avoid presenting an obsolete value as current.

5. Delete and verify.
   Delete the memory, conversation, or subject scope, then run a direct retrieval test and inspect logs or storage where possible.

Graphiti explicitly documents temporal validity and preservation of historical relationships, which makes it a natural candidate for the conflict and time tests. Semantica documents deletion, retention controls, provenance, and decision relationships, which makes it suitable for audit-oriented tests. Mem0 and Letta require you to inspect the specific extraction, state, and storage behavior used by your integration rather than assuming that every memory category is handled identically.

Do not use a single retrieval question. Build a small dataset containing paraphrases, contradictory updates, stale facts, private facts, and facts belonging to different users or agents.

Compare self-hosting and data-control boundaries

All four projects can be evaluated for local or self-managed deployment, but “open source” does not mean “every feature is self-hosted.”

Mem0 documents two open-source paths: an application library and a self-hosted server with a dashboard, API keys, and request auditing. The server still depends on configurable infrastructure such as a database, model provider, embedding provider, and optional retrieval components.

Graphiti’s documented deployment requirements include Python, a supported graph database, and an LLM or compatible provider for extraction and embedding. The official repository lists Neo4j, FalkorDB, and Amazon Neptune paths, while also noting that Kuzu support is deprecated in the current documentation. This is a meaningful operational dependency, not a minor installation detail.

Semantica offers a core package and optional integrations for vector stores and database systems. Its repository lists selectable extras for systems such as Qdrant, Weaviate, Milvus, pgvector, and other integrations. The benefit is flexibility; the cost is that your final architecture depends on which optional components you select and maintain.

Letta’s official materials describe both hosted usage and self-hosted operation. A self-hosted deployment still requires an agent server, persistent storage, model-provider credentials, network protection, and operational monitoring. The deployment boundary is therefore “you control the server and data path,” not “you have no infrastructure work.”

Before approving a project, check the repository license, current release status, database support, authentication path, backup method, and whether the hosted product contains functionality absent from the open-source distribution.

Separate multi-agent sharing from agent isolation

Multi-agent memory introduces a security problem that basic retrieval tests miss.

A shared knowledge base can help agents reuse facts, but it can also leak one customer’s data into another customer’s context. A stateful runtime can preserve an agent’s identity, but that identity must be isolated by tenant, project, and permission scope. A graph can provide excellent lineage, but only if source records and relationships carry access boundaries.

Use these controls:

• Assign every memory item a tenant, user, project, and agent scope.
• Store the source event or document identifier with every durable fact.
• Separate shared organizational knowledge from private user memory.
• Log who wrote, changed, retrieved, and deleted a memory.
• Test cross-agent retrieval with deliberately similar queries.
• Test whether a deleted source still appears through summaries, embeddings, graph edges, or cached context.
• Require explicit approval before an agent promotes an uncertain observation into shared memory.

Semantica is the most natural candidate when decision provenance, causal chains, policy checks, and audit trails are primary requirements because those concepts are part of its documented context model. Graphiti is attractive when the audit question is temporal and relational: what changed, which episode created the fact, and what relationship was later invalidated. Letta is better suited to agent-level state and behavior isolation. Mem0 can be a practical shared memory layer, but you should implement tenant and permission policies explicitly around the selected deployment.

Official claims and verified implementation are not the same thing. Mark your architecture notes with one of three labels: documented by the project, verified in your test environment, or still requiring implementation around the project.

Use a fair performance and cost acceptance method

Avoid quoting precise latency, accuracy, or cost numbers unless you can reproduce them under the same model, database, dataset, hardware, and query mix. Star counts are not quality measurements, and an attractive benchmark result may describe a different memory task from yours.

A fair test should include:

1. One fixed dataset.
   Include user preferences, long conversations, task updates, temporal changes, entity relationships, and deletion cases.

2. One fixed write budget.
   Keep the number of conversations, events, and updates identical across candidates.

3. Four query classes.
   Test semantic recall, exact fact lookup, temporal questions, and multi-hop relationship questions.

4. Correctness labels.
   Mark whether the answer retrieved the current fact, the historical fact, the correct source, or an unauthorized record.

5. Operational measurements.
   Record model calls, embedding calls, database writes, storage growth, error recovery, and administrator effort.

6. Failure review.
   Sample incorrect memories manually. A system that retrieves more results but produces more stale or unauthorized context may be worse for production.

You can use the official evaluation materials as starting points, but adapt them to your own agent tasks. Letta provides an evaluation repository intended for stateful-agent testing and private custom evaluations. That is useful for measuring agent behavior, but it does not replace a cross-project memory dataset.

Apply the four-team selection matrix

Use this decision matrix before you commit engineering time:

Your final choice should follow the data model, not the project’s popularity.

Use Mem0 when the memory requirement is broad and conventional: durable facts, user preferences, conversation-derived memories, and application-controlled retrieval.

Use Letta when the agent must carry an evolving identity, manage state, and operate through a persistent runtime.

Use Zep or Graphiti when “what is true now?” depends on time, relationships, and historical changes.

Use Semantica when the important question is “what did the system know, why did it decide this, and which source supports the decision?”

Run a two-track test before migrating production data

Do not replace your existing memory layer immediately. Run two candidates in parallel against the same sanitized dataset.

Follow this checklist:

• [ ] Define the five memory categories your agent actually needs.
• [ ] Select two candidates that match different architectural assumptions.
• [ ] Build identical write, update, conflict, deletion, and retrieval cases.
• [ ] Record model calls, database dependencies, storage growth, and operator steps.
• [ ] Test tenant isolation and cross-agent leakage.
• [ ] Inspect stale facts and false memories manually.
• [ ] Verify source lineage for every high-impact answer.
• [ ] Confirm the license and self-hosting boundary for the exact version deployed.
• [ ] Export and restore the stored memory in a clean environment.
• [ ] Keep production data on the existing system until both candidates pass the acceptance set.

If your current solution is a plain vector store, the migration risk is usually not the first write. It is the hidden behavior around updates, deletes, permissions, and stale summaries. Your acceptance dataset must test those cases before you approve a new memory layer.

A self-hosted deployment also needs a reliable development environment for database services, model integrations, and repeatable test runs. If your team does not want to maintain that environment on developer laptops, review ZavCloud’s cloud Mac development environment options and use a controlled machine for installation and regression testing. The ZavCloud Help Center can also help you confirm the operating details before committing to a longer test cycle.

Choose the architecture, then choose the machine

For a short prototype, your current local setup may be enough, but it often creates three practical problems: dependencies differ between developers, graph databases and persistent volumes are difficult to reproduce, and long-running evaluation jobs compete with normal development work. A generic cloud server may solve persistence but still leave you with manual environment setup, weak desktop access, or an inconvenient workflow for Apple-specific development and testing.

That does not mean renting a Mac is automatically the right answer. If you need continuous heavy workloads, dedicated physical interfaces, or a permanent production database, buying and operating your own infrastructure may be more suitable. If you need a temporary, repeatable environment to compare two Agent Memory candidates, run installation tests, validate local model integrations, and keep the test machine separate from your daily workstation, a ZavCloud Mac environment can be the cleaner option.

Once you have selected two candidates, move the same acceptance dataset to both environments, keep the test procedure unchanged, and only migrate production memory after the results are reproducible.