Mem0 vs Zep vs Letta: AI Agent Memory in 2026

Which AI agent memory tool should you use in 2026?

Short answer. Pick by memory type, not by feature list. Mem0 for layered conversation and user memory. Zep for entity memory on a temporal knowledge graph. Letta for agent-managed context in the MemGPT tradition. LangMem for memory primitives native to LangGraph. All four remember what flowed through the agent. None of them covers database-grounded semantic context: what is actually in your databases, what it means, and how it connects.

That fifth category is the organizing idea of this roundup. Instead of ranking tools on features, we sort them by the type of memory they implement, because that is what determines fit. Every claim about a vendor below comes from that vendor's own documentation, linked in the sources.

A taxonomy: sort tools by what they remember

"Memory" in agent systems is not one thing. The tools in this roundup implement at least four distinct types:

1. Conversation and user memory. What was said, summarized and promoted into durable facts about a user or session. This is the crowded category.
2. Entity and relational memory. Facts structured as a graph of entities and relationships, often with time awareness, so the agent can reason about how facts connect and when they stopped being true.
3. Agent-managed context. The agent itself curates a set of editable memory blocks inside its context window, deciding what to keep in view and what to archive.
4. Procedural and behavioral memory. Learned rules about how the agent should behave, typically fed back into prompts.

Each of these four maps onto a storage and retrieval pattern; the agent memory layer architecture guide covers the schemas and retrieval behind them. Then there is the fifth type, which we will get to: semantic context grounded in your databases rather than in your conversations.

The 2026 memory tool landscape by source and scope. The conversation-derived quadrants are crowded. The shared, database-grounded quadrant is largely unclaimed.

Mem0: layered conversation and user memory

Mem0 organizes memory into four layers by scope: conversation memory for the current turn, session memory for short-lived task facts, user memory for long-term personal knowledge, and organizational memory for shared team context. Messages enter at the conversation layer and get promoted upward based on identifiers like user_id and run_id, and retrieval ranks user memories first, then session notes, then raw history. The docs summarize the design goal as separating memory into layers "so agents remember the right detail at the right time." (Mem0 docs)

Within those layers, Mem0 maps to the classic categories: factual memory for preferences and account details, episodic memory for summaries of past interactions, and semantic memory for conceptual relationships. The fit is strongest when your problem is a personal assistant or support agent that should stop asking users the same questions.

Zep: entity memory on a temporal knowledge graph

Zep's core abstraction is a temporal knowledge graph: nodes are entities, edges are facts and relationships, and the graph updates as new data arrives from chat, business data, documents, or JSON. Its distinguishing feature is fact invalidation. When a fact stops being true, the time it became invalid is stored on that fact's edge, so history is preserved rather than overwritten. Zep exposes six primitives: facts, entities, episodes, thread summaries, observations, and user summaries, assembled into token-efficient context blocks for the agent. (Zep docs)

Pick Zep when your agent needs to reason about how facts relate and evolve: a customer changed plans, a preference was superseded, an account moved owners. Flat fact stores lose that temporal structure; a graph with validity intervals keeps it.

Letta: agent-managed context, the MemGPT lineage

Letta descends from the MemGPT research line and takes a different stance: the agent manages its own memory. Core memory lives in labeled, editable blocks (the canonical examples are a human block describing the user and a persona block defining the agent), and the agent can rewrite these blocks itself as it learns. Beyond core memory sits archival memory, a separate store for information that does not need to stay in the context window, and shared memory blocks let multiple agents work from common state. Letta's newer Agent SDK adds a filesystem-style, git-tracked memory model on top of the original blocks-only design. (Letta memory blocks, archival memory)

Letta fits when you want a persistent agent with an evolving identity, something closer to a long-lived digital coworker than a stateless tool, and you are comfortable giving the agent authority over its own context.

LangMem: memory primitives for LangGraph

LangMem, from the LangChain team, provides functional primitives for extracting important information from conversations, maintaining semantic and episodic memory collections, and refining agent behavior through prompt optimization, which is procedural memory in practice. It is storage-agnostic in principle but integrates natively with LangGraph's long-term memory store, using the BaseStore interface with backends from in-memory up to AsyncPostgresStore. (LangMem docs)

If you are already on LangGraph, LangMem is the default answer. It is less a standalone product than a set of building blocks that assume you own the surrounding agent architecture.

Mem0 vs Zep vs Letta vs LangMem, side by side

Notice the last row. It is unanimous, and it is not a criticism of these tools. They were built to remember interactions, and they do it well. The database-grounded row is being approached from the other side, by catalog and lakehouse vendors pushing metadata toward agent consumption, but not by any of the memory tools an agent team evaluates first.

Match the memory type to the tool.

The uncovered category: database-grounded semantic context

Run the taxonomy to its end and a gap appears. Every tool above learns from what flows through the agent: messages, extracted facts, documents fed in. None of them learns from the systems of record themselves. Ask a Mem0-backed agent what orders.status = 3 means in your Postgres database and it can only answer if someone happened to say it in a conversation it stored. The database that defines the answer was never a memory source.

This matters because conversation-derived memory of data systems has two structural problems. It is anecdotal: the agent remembers what one user once said about a table, which may have been wrong or may have expired when the schema changed. And it is ungoverned: there is no owner, no validation, no way for the people who own the data to say "that definition is stale." A schema dump does not fix this either: the dump shows structure, not meaning, which is how a team ends up with three columns that all look like revenue and no record of which one finance trusts.

What the gap calls for is a different layer with a different contract: a semantic map of your actual databases, covering what's there, what it means, and how it connects, kept current against the live systems and validated by the people who own the data. If you want to see the shape of that map before buying anything, build one for Postgres yourself. That is not a memory layer, and the distinction is worth being precise about; we draw the full boundary in memory layer vs context layer, and define the layer itself in what is an agent context layer. In short: memory personalizes, context grounds. If you are architecting the memory side properly, the agent memory layer architecture guide walks the design end to end, and the two layers compose rather than compete.

Hypotheticals make the difference concrete. Consider a team with an analytics agent that answers revenue questions. Memory tooling lets it recall that this user prefers monthly granularity. Only database-grounded context can tell it that revenue appears in three tables, that two are deprecated, and that finance's definition excludes refunds. Both are useful. Only one prevents a confidently wrong number.

Where Datapace fits

Datapace is building for exactly that empty quadrant: a semantic context layer over your databases (Postgres first in depth, multi-database through OpenMetadata connectors) that resolves what's there, what it means, and how it connects, and carries the operational side of the same graph, cost, performance, usage and freshness, quality checks, and end-to-end lineage. A policy gate sits in front of it, and agents consume it through a Context API and MCP, so the context they get is governed rather than anecdotal. It is in development, not shipping, and this roundup lists it as an honest in-progress entry rather than a fifth product to compare. If the gap described above is the one you are hitting, see safe AI access to your databases or book a call and tell us how your agents currently learn what your data means.

Sources

1. Mem0 Documentation: Memory Types
2. Zep Documentation: Concepts
3. Letta Documentation: Memory Blocks
4. Letta Documentation: Archival Memory
5. LangMem Documentation