The 2026 numbers ended the accuracy argument between agent memory frameworks. Mem0's April 2026 algorithm publishes 94.4% on LongMemEval and 92.5% on LoCoMo at roughly 6.8K to 7.0K tokens per query and p50 latency near one second, scored with GPT-5 as answerer and judge. Zep publishes 90.2% on LongMemEval and 94.7% on LoCoMo at 104ms and 87ms p50 retrieval and 4,408 to 5,760 tokens per query, scored with GPT-5.4. Those runs are not directly comparable: different readers, different judges, different retrieval depth, each vendor scoring its own system. What separates the four now is where the thing runs and what a turn costs, not recall. Mem0 is Apache-2.0 and self-hostable with SOC 2 Type I and HIPAA-ready claims, Zep is cloud or BYOC only with SOC 2 Type II and HIPAA business associate agreements, Letta moved memory into git-backed context repositories the agent edits with ordinary file tools, and Cognee runs fully local with no SOC 2 or HIPAA certification. Pull fifty real traces with contradictions in them and measure accuracy, p50 and tokens per query yourself before you argue about a leaderboard.
An agent that clears every eval on Monday and forgets the user's name by Wednesday does not have a model problem. It has a memory problem, and across the agent systems we have shipped and audited it is the defining Day-2 failure: the demo works because the whole conversation fits in one context window, and production breaks because real users come back across sessions, days and topics. Choosing an AI agent memory framework in 2026 means choosing how that gap gets closed, and the four candidates most teams shortlist (Mem0, Zep, Letta and Cognee) now answer it in four genuinely different ways.
What changed this year is that the accuracy argument ended. In 2025 the comparison was easy to write: temporal knowledge graphs beat flat vector stores on temporal retrieval by double digits, and one benchmark line proved it. As of September 2026 Mem0 publishes 94.4% on LongMemEval and Zep publishes 90.2% on the same benchmark, each measured by its own team, with a different reader model and a different retrieval depth. Both sit in the nineties. Neither number tells you which one to run.
What does tell you is the shape of the cost: how many tokens the memory layer spends per turn, how many milliseconds it adds at p50, whether it can run inside your perimeter, and which certifications it carries. This post walks each framework as it exists today, then puts the published numbers side by side with their methodology attached, because the methodology is where the decision lives. For the patterns underneath all four, our guide on how to make AI agents remember context across conversations covers the architecture; this one is about which framework to pick.
Why Memory Is the Defining Day-2 Agent Problem
A stateless agent is a fancy autocomplete with tools. The moment you want one 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 outside the context window. Deciding what to store, how to retrieve it and when to invalidate it is the entire problem.
Three sub-problems hide inside the word "memory," and the four frameworks split on which they solve in the store versus which they push to the model:
Invalidation is where the architectures still genuinely differ, even though the benchmark scores converged. That is the thing to keep in view while reading the rest of this post: two systems can land within four points of each other on LongMemEval while doing completely different work to get there, and the work is what you pay for on every turn.
Mem0: Additive Extraction and Multi-Signal Retrieval
Mem0 is the most-starred of the four at roughly 66,000 GitHub stars, Apache-2.0, and it still asks the least of you. You call add() after a turn and search() before the next one. An LLM extraction pass distills durable facts, entities get pulled out and linked across memories, and retrieval fuses three signals: semantic similarity over embeddings, BM25 keyword matching for names and identifiers, and an entity boost for memories linked to entities in the query.
The important architectural detail is that extraction is additive. If a user says they moved from Austin to Seattle, Mem0 stores the new fact without silently rewriting the old one, and you use explicit update or delete calls when the application needs a correction. Contradiction resolution therefore happens at read time, in the reader model, over candidates the store surfaced, rather than in the store through validity windows.
That design shipped in April 2026 and moved the published numbers a long way. By Mem0's own accounting the previous pipeline scored 67.8 on LongMemEval and 71.4 on LoCoMo; the current one publishes 94.4% on LongMemEval (472 of 500) and 92.5% on LoCoMo (1,425 of 1,540), with GPT-5 as both answerer and judge, at a retrieval depth of 200 memories. The temporal-reasoning slice of LongMemEval, the exact capability the 2025-era comparisons said Mem0 was weak at, comes in at 97.0%. Mean retrieval sits at 6.8K to 7.0K tokens per query and p50 latency at 0.88s to 1.09s.
Operationally it is the easiest of the four to start with: a free tier with 10,000 add and 1,000 search requests per month, $19 and $249 paid tiers above it, and a managed platform that spares you running the stores. Mem0 advertises SOC 2 Type I, HIPAA-ready and GDPR-ready, plus Kubernetes, private cloud and air-gapped deployment for teams that need the store inside their own network.
Pick Mem0 when: you want the fastest integration, you are comfortable with contradiction resolution happening in the model rather than the store, and you need the option to run the whole thing on your own infrastructure.
Zep: Graphiti, Fact Invalidation, and a Cloud-Only Product
Zep is built on Graphiti, a temporal knowledge graph that stores facts as edges with explicit validity windows. "User is on the Pro plan" is not deleted when they upgrade; it is marked invalid after the upgrade timestamp while a new edge carries its own valid-from date. The graph keeps the history of what was true when, which is a different claim from keeping both facts and hoping the reader model picks correctly. The architecture is documented in the Zep temporal knowledge graph paper.
Around that graph Zep has built a retrieval engine that is the actual product: hot graphs held in memory as adjacency lists and sparse matrices with vector and BM25 indexes alongside, and a context block assembled at query time by ranking and packing rather than by asking an LLM to write a summary. Zep's published results are 90.2% on LongMemEval (451 of 500) and 94.7% on LoCoMo (1,459 of 1,540), with GPT-5.4 as reader and judge, retrieval latency of 104ms p50 and 162ms p95, and a median context of 4,408 tokens per question. A single-call "auto search" mode trades accuracy for size: 86.5% on LoCoMo at 2,680 tokens.
The structural change buyers keep missing: Zep is no longer something you self-host. The product ships as managed cloud, cloud with your own encryption keys, or bring-your-own-cloud inside your VPC. The repository that used to hold the open-source server now holds examples and integrations, and the open-source piece is Graphiti, the graph library, not the engine or the service. In exchange you get the strongest compliance posture of the four: SOC 2 Type II and HIPAA business associate agreements. If you are weighing whether to invest in graph infrastructure at all, our writeup on GraphRAG implementation at scale covers what running a knowledge graph in production actually costs.
Pick Zep when: point-in-time correctness has to live in the store rather than the prompt, per-turn latency and token budget are tight, and a SOC 2 Type II vendor inside your VPC clears procurement faster than a self-hosted stack you would have to audit yourself.
Letta: MemGPT's Lineage Now Lives in Git-Backed Context Repositories
Letta is the team behind MemGPT, the paper that framed an LLM as an operating system with the context window as RAM and an external store as disk. That idea survives. The implementation it was famous for does not.
In March 2026 Letta refocused on Letta Code, a model-agnostic agent harness, and began sunsetting the server-side machinery the framework was known for. Memory moved from specialized tools that edit rows in a database to general computer use over memory projected into git-backed files, which Letta calls context repositories. Legacy memory tools such as core_memory_replace, the Letta Filesystem, templates, identities, server-side MCP integrations, server-side sleep-time agents and tool rules were all deprecated in favor of client-side equivalents. The older V1 API server now lives on an archive branch, and active development sits in the letta-code repository.
Read that as an architectural bet, not a retreat. Memory as versioned files means every edit the agent makes to its own working context is a diff you can read, revert and audit with tools your platform team already runs. For regulated environments that is a real property: an auditor can be shown the git history of what the agent believed and when it changed its mind, without anyone building a memory-provenance feature.
Letta's published position on the benchmarks everyone else quotes is that they do not measure much. In August 2025 it reported that Letta agents on gpt-4o-mini reached 74.0% on LoCoMo by storing conversation histories in plain files rather than calling any specialized memory tool, and argued from that result that retrieval benchmarks say more about the agent's context management than about the memory backend. The feature that produced the number has since been replaced by context repositories, and Letta now runs its own evaluations instead: Context-Bench for agentic context engineering, and a private Context-Bench V2 that scores how well models use existing memory and generate new memory from experience. Letta advertises no SOC 2 or HIPAA certification; its compliance answer is that you run it, on your own keys, on your own machine or server.
Pick Letta when: the agent should curate its own working set, you want memory edits to be reviewable as diffs rather than opaque row updates, and local-first execution with your own model keys fits better than a hosted memory service.
Cognee: A Self-Hosted Knowledge Graph With No Certifications
Cognee comes at memory from the data-engineering side. You add sources, run cognify to extract entities and relationships into a typed knowledge graph, then search it, with a memify pass that distills learnings back into the graph. Underneath sit three stores with distinct jobs: a relational store for documents, chunks and provenance, a vector store for embeddings, and a graph store for entities and relationships. It is Apache-2.0 with roughly 31,000 stars, and it is the only one of the four that will build memory from text with local extraction and embedding models before you have supplied any hosted model key.
On benchmarks Cognee has gone after BEAM, the long-horizon benchmark whose conversations scale to 10M tokens, rather than the two everyone else quotes. It reports 0.79 on the 100K setting against a previously reported state of the art of 0.735, and up to 0.67 at 10M against a reported 0.641, while stating plainly that the 10M result involved more parameter exploration on the target conversation than it would like and that per-question-type prompts were used. That candor is worth more than the score.
The gate is certification. As of September 2026 Cognee advertises no SOC 2 and no HIPAA. Its trust page covers GDPR alignment through a third-party data protection program, a DPA on request, and EU AI Act readiness tracking, alongside local, cloud and on-prem deployment. For procurement that requires a SOC 2 report, that is disqualifying regardless of technical merit. For teams whose actual requirement is that data never leaves the building, an Apache-2.0 engine that runs fully local is the stronger answer, which is the same trade we map out in cloud versus on-premise AI.
Pick Cognee when: you need a typed graph over heterogeneous documents, you self-host and audit your own stack, and your compliance story is control and residency rather than a vendor's attestation.
How to Read the 2026 Benchmark Numbers
Here is every figure the four vendors publish for these systems, with the methodology that produced it. Read the right-hand columns first.
Four things follow from that table. First, the two numbers everyone quotes against each other were produced by different reader models, different judges and different retrieval depths, so the four-point spread on LongMemEval is not a measurement of anything. Second, the latency columns do not measure the same span: Zep reports retrieval, Mem0 reports a figure that holds at or under 1.1s across every benchmark including BEAM at 10M tokens. Third, every row here was produced by the vendor scoring its own system, not by one neutral harness running all four. Fourth, Letta's only LoCoMo number is a 2025 result it published to argue the benchmark is a weak proxy, and Cognee publishes its own results on BEAM rather than on either of these, so half the field is not competing on this leaderboard at all.
Check the traces when a vendor ships them, because they are the only auditable artifact. Mem0 publishes per-question result files in its public benchmark repository, and they are a useful lesson in how much retrieval depth matters: the committed LongMemEval run from April 2026 scores 93.4% at a depth of 200 and 90.4% at a depth of 50, and the committed LoCoMo runs score 91.6% and 82.7% at those same depths, against headline table figures of 94.4%, 94.8%, 92.5% and 91.8%. The headline and the trace are not the same run, and the cheaper retrieval setting costs real points. Vendor benchmark numbers deserve exactly this treatment, for the reasons we set out in how one agent scored 100% on SWE-Bench without solving anything.
The last thing worth knowing is where all of this still falls apart. LongMemEval runs 500 questions over conversations averaging around 115K tokens, and LoCoMo runs 1,540 questions over ten multi-session dialogues. Both are now saturated in the low nineties. BEAM is not: at its 10M-token setting the published scores drop to 0.486 for Mem0 and up to 0.67 for Cognee with tuning, against roughly 0.79 for Cognee at 100K. If your agent accumulates months of history, the honest read is that nobody has solved your case yet, and the benchmark that reflects it is the one where every score collapses.
| System | LongMemEval | LoCoMo | p50 latency as published | Tokens per query | Reader and judge |
|---|---|---|---|---|---|
| Mem0 (platform, April 2026) | 94.4% at top-200 | 92.5% at top-200 | 1.09s / 0.88s, end to end | 6.8K / 7.0K | GPT-5 |
| Zep (multi-scope retrieval) | 90.2% | 94.7% | 104ms / 87ms, retrieval only | 4,408 / 5,760 | GPT-5.4 |
| Zep (auto search) | not published | 86.5% | 115ms, retrieval only | 2,680 | GPT-5.4 |
| Letta | not published | 74.0% (2025, files, no memory tools) | not published | not published | gpt-4o-mini |
| Cognee | not published | not published | not published | not published | n/a |
Decision Matrix: Deployment, Latency, Tokens, Compliance
Stars and headline accuracy are the wrong first filter. Deployment and compliance constrain the choice hardest, and they are the two dimensions where the four are genuinely far apart.
For regulated deployments the matrix collapses fast. If your requirement is a vendor attestation, Zep is the only one of the four carrying SOC 2 Type II and offering HIPAA business associate agreements, and BYOC puts it inside your network boundary. If your requirement is that your own auditors read the code that touches the data, Zep is the one option that cannot satisfy it: BYOC puts Zep's software inside your VPC, but the retrieval engine around Graphiti is closed, while Mem0, Cognee and Letta ship the whole layer under Apache-2.0. Those are opposite answers to the same word, "compliance", and which one your reviewers mean determines the shortlist before any benchmark is discussed.
Two smaller patterns hold across the matrix. Token budget is a product decision, not a footnote: Zep's auto search mode gives up eight points on LoCoMo to cut the context block from 5,760 tokens to 2,680, and a trade that size compounds with every turn you serve. And where invalidation happens decides what you can debug: a wrong answer from a validity-windowed graph is traceable to an edge, while a wrong answer from additive storage plus a reader model is a prompt-level forensics exercise, which is the practical version of the shift we describe in context engineering replacing prompt engineering.
| Dimension | Mem0 | Zep | Letta | Cognee |
|---|---|---|---|---|
| Persistence model | Additive fact store: vector, entity and history stores, graph memory on platform | Graphiti temporal graph, edges carry valid and invalid timestamps | Git-backed context repositories the agent edits with file tools | Relational, vector and graph stores built by a cognify pass |
| Invalidation | Reader model resolves contradictions over retrieved candidates | Validity windows in the store | Agent rewrites the file, git keeps the diff | Graph rebuilt, typed edges updated |
| Where it runs | Apache-2.0 self-host, managed cloud, Kubernetes, private cloud, air-gapped | Managed cloud, cloud with your keys, BYOC in your VPC; no self-hosted server | Apache-2.0 local app server, desktop app, cloud | Apache-2.0 fully local, BYOC, on-prem, managed cloud |
| Open-source component | The whole memory layer | Graphiti, the graph library only | The whole harness | The whole platform |
| Published p50 | 0.88s to 1.09s end to end | 87ms to 115ms retrieval | none | none |
| Compliance | SOC 2 Type I, HIPAA-ready, GDPR-ready | SOC 2 Type II, HIPAA BAAs | none advertised | none advertised, GDPR alignment only |
Recommendation by Scenario
We close every memory scoping conversation with one of four starting points. Every workload has wrinkles, but these hold up most often:
The move that survives all four choices is to stop reading leaderboards this week and build a fifty-question eval from your own traces: real contradictions, real time-dependent facts, real multi-session callbacks. Score each candidate on accuracy, p50 and tokens per query, on your data. That is the work we do when we scope a memory layer, and it settles the choice faster than another week of reading vendor pages. The strategic context for where memory sits in a production agent architecture lives in our AI Agents pillar.
Match the architecture to where you want contradictions resolved and where you need the data to live. 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.
FAQ
Quick answers to the questions this post tends to raise.



