Agent Memory Frameworks Tested: Mem0 vs Zep vs Letta

Why Memory Is the Defining Day-2 Agent Problem

A stateless agent is a fancy autocomplete with tools. The moment you want an agent that recognizes a returning user, recalls a decision from last week, or notices that a fact it stored is now wrong, you need a memory layer that lives outside the context window. The context window is working memory: fast, bounded, and wiped at the end of the turn. Everything that has to persist needs somewhere durable to go, and the act of deciding what to store, how to retrieve it, and when to invalidate it is the entire problem.

There are three sub-problems hiding inside "memory," and frameworks differ on which they solve well:

That third sub-problem, invalidation over time, is the one almost nobody designs for and the one that separates these four frameworks most sharply. It is also the reason a single benchmark number (LongMemEval) carries so much signal: it is built specifically to test whether an agent retrieves the currently true fact rather than any plausible-looking one.

Mem0: Hybrid Store, Automatic Extraction, Fast Time-to-Value

Mem0 (~47K GitHub stars as of mid-2026) is the most popular agent memory framework, and the popularity is earned by how little it asks of you. You call add() after a turn and search() before the next one, and Mem0 handles extraction and retrieval internally. Under the hood it runs a hybrid of three stores: a vector index for semantic recall, a graph layer for relationships between entities, and a key-value store for fast structured lookups. Automatic extraction means you do not write the "what should I remember from this turn" logic; an LLM call distills the salient facts for you.

The sweet spot is personalization. If your agent needs to remember that a user prefers concise answers, lives in Berlin, and is working on a TypeScript project, Mem0 stores and recalls those stable preferences cleanly with minimal integration effort. The free tier is generous enough to validate a prototype, and the managed cloud handles the infrastructure so you are not standing up a vector store and a graph database yourself.

Where Mem0 runs out of road is temporal reasoning. Its graph layer captures relationships, but it is not a first-class temporal model: facts are updated rather than versioned with explicit validity windows. When a user's plan changes, when a preference reverses, when a fact has a "true from X to Y" shape, Mem0 can store the new value but it does not natively reason about when each value was true. That limitation shows up directly in the LongMemEval gap. For agents whose memory is mostly stable facts, this never bites. For agents tracking changing state, it bites hard.

Pick Mem0 when: you want personalization with a five-minute integration, your facts are mostly stable, and you would rather buy automatic extraction than build it.

Zep: Graphiti and the Temporal Knowledge Graph

Zep is built on Graphiti, a temporal knowledge graph, and that single architectural choice is the whole story. Instead of storing a fact and overwriting it when it changes, Graphiti stores facts as edges with explicit validity windows. "User is on the Pro plan" does not get deleted when they upgrade; it gets marked invalid after the upgrade timestamp, and a new edge "user is on Enterprise" is created with its own valid-from date. The graph keeps the full history of what was true when.

This is exactly the capability LongMemEval stresses, and it is why Zep posts 63.8% with GPT-4o against Mem0's 49.0%. The benchmark deliberately includes questions where a naive system retrieves a fact that was true but no longer is. A temporal graph answers "what is true now" and "what was true in March" without confusion because validity is a first-class attribute of every edge, not an afterthought. A flat vector store cannot, because it has no representation of time beyond a timestamp it does not reason over during retrieval.

The cost is complexity and latency. A temporal graph traversal is more expensive than a vector nearest-neighbor lookup, and deep multi-hop queries can land in the low hundreds of milliseconds rather than the tens of milliseconds a vector lookup costs. For most agent workloads that overhead is acceptable next to model latency, but it is real, and you should benchmark it on your own graph density rather than trusting a vendor number. Graph-backed memory shares its conceptual roots with broader graph retrieval; if you are weighing whether to invest in graph infrastructure at all, our writeup on GraphRAG implementation at scale covers the operational realities of running a knowledge graph in production.

Pick Zep when: your agent tracks state that changes over time (subscriptions, account status, evolving preferences, anything with a "as of" qualifier) and you need point-in-time correctness, not just recall.

Letta: The MemGPT Runtime Where the Agent Manages Its Own Memory

Letta is the production framework from the MemGPT team, and it implements that paper's central metaphor literally. MemGPT framed an LLM as an operating system: the bounded context window is RAM, an external store is disk, and the agent uses tools to page information between them. Letta turns that into a stateful runtime. Main context holds the active working set. Archival memory holds the overflow. And critically, the agent itself decides what to promote into context and what to evict, by calling memory-edit tools, rather than a framework making that call for it.

This is a fundamentally different posture from Mem0 or Zep. Those are memory services you call from your application: store this, fetch that. Letta is a memory-managing agent runtime you deploy as a server with a REST API. The agent is long-lived and stateful by design; it owns its own memory budget the way a process owns its address space. That makes Letta a strong fit for long-running stateful services (a persistent assistant, a multi-session support agent, anything that lives for days and accumulates a working context it has to curate).

The tradeoff is that you are buying into a runtime model, not a library. You run Letta as a service, you interact through its API, and you give the agent the autonomy to manage its own memory, which means you are trusting the agent's self-editing decisions. When that autonomy is the point (the agent genuinely needs to reason about its own working set), Letta is uniquely suited. When you just want to stash and retrieve facts from an app you already have, it is more machinery than the job requires. The self-management pattern connects directly to the broader shift we describe in context engineering replacing prompt engineering: the hard problem is no longer the prompt, it is curating what occupies the context window over time.

Pick Letta when: you are building a long-running stateful agent that should own its memory allocation, and a REST-addressable runtime fits your architecture better than a memory call inside an existing app.

Cognee: The ECL Pipeline and Typed Knowledge Graphs

Cognee approaches memory from the data-engineering side. Its pipeline is ECL (Extract, Cognify, Load): extract entities and relationships from heterogeneous sources, cognify them into a structured graph with typed nodes and edges, and load the result into a queryable store. The output is a typed knowledge graph, which is more rigorous than a loose pile of memories. If you need the agent to reason over structured entities (people, organizations, documents, and the typed relationships between them), Cognee gives you that structure rather than asking you to infer it from embeddings.

That rigor is genuinely valuable for knowledge-heavy agents: research assistants, agents that ingest large document corpora, anything where the relationships between entities matter as much as the entities themselves. The ECL framing also makes the pipeline inspectable; you can see what was extracted and how it was typed, which is harder with a black-box automatic-extraction store.

The blocker for many teams is compliance. As of mid-2026, Cognee does not advertise SOC 2 or HIPAA certification. For internal tooling, research prototypes, and unregulated data that is a non-issue. For healthcare, finance, or any enterprise procurement that gates on certifications, the absence is disqualifying regardless of how good the graph is, and that is worth knowing before you invest engineering time. The honest positioning: Cognee is the most interesting of the four for typed-graph use cases and the least ready for regulated production.

Pick Cognee when: you need a typed knowledge graph from heterogeneous documents, you value pipeline inspectability, and your data is not subject to compliance gates Cognee cannot currently satisfy.

Benchmark Gaps: Where the 15 Points Come From

Benchmarks in this category are noisy and you should treat any single number with suspicion, but the pattern across LongMemEval is consistent enough to act on. The headline gap (Zep 63.8% vs Mem0 49.0% on GPT-4o) is not a small-sample fluke; it is the predictable consequence of a temporal graph versus a flat-ish store on a benchmark designed to test temporal correctness.

Two cautions about reading benchmarks here. First, LongMemEval rewards temporal correctness specifically; if your agent's memory is mostly stable facts, the 15-point gap is largely irrelevant to you, because you are not exercising the capability the benchmark measures. A framework can lose on LongMemEval and still be the right call for personalization. Second, benchmark numbers shift with the underlying model, the configuration, and the version of the framework. The 63.8% / 49.0% figures are GPT-4o results; swap the model and the absolute numbers move, even if the ordering usually holds. The defensible takeaway is directional: temporal-graph approaches beat flat-store approaches on temporal-retrieval tasks by a wide margin, and you should match the architecture to whether your facts change over time.

The deeper point is that you should run the benchmark that matches your memory pattern, not borrow ours. Build a small eval set from real session traces (with contradictions, time-dependent facts, and multi-session callbacks) and measure recall accuracy and latency on each candidate. That is the work we do when we scope a memory layer at Particula Tech, because the published numbers tell you the shape of the difference but not its magnitude on your data.

Decision Matrix: Persistence, Coordination, Self-Host, Latency, Compliance

Pricing and stars are the wrong first filter. The first filter is your persistence model and your compliance posture, because those constrain the choice hardest.

A few patterns hold across the matrix:

The mistake we see most often is picking by familiarity ("we already use a vector DB, so Mem0") instead of by memory pattern. A vector DB you already run does not make Mem0 the right answer if your agent's whole job is reasoning about facts that change. Map your agent's memory pattern first (stable personalization, changing state, self-managed working set, or typed document graph), and three of the four candidates usually fall away immediately.

Recommendation by Scenario

We close every memory scoping conversation with one of four concrete starting points. Every workload has wrinkles, but these hold up most often:

The wrong move in every case is treating memory as an afterthought you bolt on once the agent "works." It does not work without memory; it just looks like it does in a demo. The strategic context for where memory sits in a production agent architecture lives in our AI Agents pillar, and the implementation patterns underneath these frameworks are in our guide on agent memory and context management.

Match the architecture to whether your facts change. Benchmark on your own traces, not ours. And design the memory layer before the demo, not after the first user comes back and the agent has forgotten who they are.