What the agent-memory vendors actually differ on
The memory vendors’ documentation converges on retrieval and diverges on two things: what the store physically is, and what happens to a fact that stops being true. Those two questions separate the products more cleanly than any feature list does, and both are answerable from public documentation in an afternoon.
What follows compares documented mechanisms — substrate, superseded facts, licence, self-hosting — and nothing else. Pricing, funding and star counts are deliberately absent: they move on a scale of weeks, and a comparison built on them is stale before it is useful. Every source here was retrieved on 26 August 2026 and none of it is a ranking.
Four substrates
mem0 extracts facts on write into a vector store, and its own paper documents what the update phase does: existing memories closest to the candidate fact are retrieved, handed to a model along with the new fact, and the model picks one of four operations — ADD, UPDATE, DELETE or NOOP. Its documentation also declares three memory types while marking one as implemented, which CM-006, The three types of agent memory: semantic, episodic, procedural, covers in detail.
Zep, on the open-source Graphiti engine, stores facts in a temporal graph. Graphiti’s own description: “Each fact in a context graph has a validity window: when it became true, and when (if ever) it was superseded.” What follows from that is the distinguishing behaviour in this group — “When information changes, old facts are invalidated — not deleted. Query what’s true now, or what was true at any point in time.” It is Apache-2.0 and runs on Neo4j 5.26+, FalkorDB, Amazon Neptune, or Kuzu, which its own README marks deprecated because the upstream project is unmaintained.
Letta puts memory in the context window rather than behind a retrieval step. Its memory blocks are “structured sections of the agent’s context window that persist across all interactions. They are always visible - no retrieval needed,” and they are “read-write by default (so the agent can update the block using memory tools)” unless you mark one read-only. The lineage is the MemGPT paper, which framed this as “virtual context management, a technique drawing inspiration from hierarchical memory systems in traditional operating systems.”
Cognee treats the problem as a pipeline rather than a store, building a self-hosted knowledge
graph from your sources — its remember operation runs add, cognify and improve as one workflow —
and it advertises “cognitive-science-grounded ontology generation” as part of that. Apache-2.0.
The dimension that actually separates them
| Substrate | A fact that stops being true | Licence | |
|---|---|---|---|
| mem0 | Vector store, facts extracted on write | Model picks ADD / UPDATE / DELETE / NOOP per write | Apache-2.0 |
| Zep / Graphiti | Temporal graph, validity window per fact | Invalidated, not deleted; earlier state stays queryable | Apache-2.0 |
| Letta | Blocks held in the context window | Agent rewrites the block through a memory tool | Apache-2.0 |
| Cognee | Pipeline into a graph, ontology-generated | Defined by the pipeline you build | Apache-2.0 |
| AgentCore Memory | Managed, short-term plus long-term | Not documented as a distinct operation | Managed service |
| Anthropic memory tool | Whatever you back it with | Whatever your handler does | Client-side |
Four different answers to the same question, and only one of them — Graphiti’s — treats “was true, now isn’t” as a first-class state rather than an overwrite. That is a difference in what the store can be asked, not a claim about which is better: a system that overwrites answers “what is true now” and cannot answer “what did we think last quarter”, and for a great many applications the second question never arrives.
The platforms ship it too
AWS Bedrock AgentCore Memory documents two types. Short-term “captures turn-by-turn interactions within a single session”; long-term “automatically extracts and stores key insights from conversations across multiple sessions, including user preferences, important facts, and session summaries.”
Anthropic’s memory tool answers the substrate question by handing it back: “The memory tool
operates client-side: Claude requests file operations, and your application executes them. You
control where and how the data is stored through your own infrastructure.” Claude reads and writes
files under a /memories prefix that your handler maps onto real storage. Anthropic ships no store
of its own here, which makes this a different kind of product from the four above rather than a
competitor to them.
The benchmark numbers have a documented history
Anyone comparing these products meets the LoCoMo benchmark quickly, so the artefacts are worth reading in order. What the benchmark itself contains — ten synthetic conversations, 1,986 annotated questions, and a scoring method the evaluator chooses — is in CM-010, What LoCoMo actually measures; what follows here is only the argument about the scores.
On 6 May 2025, Zep published a critique of mem0’s evaluation of Zep, listing three implementation errors — a user graph “designed for single user-assistant interactions but assigned the user role to both participants”, timestamps appended to messages “rather than using Zep’s dedicated created_at field”, and searches “performed sequentially instead of in parallel, artificially inflating Zep’s reported search latency”. Corrected, Zep said, its score was 75.14% ±0.17 rather than the 65.99% mem0’s paper reported.
Two days later, on 8 May 2025, mem0’s co-founder and CTO opened an issue against Zep’s own papers repository arguing that Zep’s separately published 84% included adversarial-category questions in the numerator while excluding them from the denominator, which “artificially inflated the reported accuracy by approximately 25.56 percentage points (84% vs. actual 58.44%)”, and noting that mem0 averaged ten independent runs where Zep published one.
So the same product and the same benchmark carry 58.44% and 75.14% depending on who ran it, and both parties allege the other misconfigured the thing being measured. Notice what both are actually demonstrating, since neither states it as such: configuration moved the number by more than the gap either was arguing about. A published score is therefore a fact about one configuration, and the inference from it to “this product is better” is a reading rather than a demonstration.
Vendor self-reporting is still the norm. Cognee’s README currently states 0.79 on the BEAM benchmark against roughly 0.33 for a RAG baseline at 100K tokens — its own figure, on its own page, with no independent replication cited. That is not an accusation; it is the category’s normal practice, and it is why the numbers are the last thing to compare rather than the first.
What to read before choosing
Four questions, each answerable from a vendor’s own documentation in a few minutes.
What happens when a new fact contradicts a stored one, and what decides? CM-007, How agent memory gets written: hot path versus background, is the longer version of why this is the question that matters and what silence in the documentation usually means.
Is the substrate one you already operate? A graph engine you do not run today is an operational commitment, not a feature.
What is the licence, and can you self-host? All four projects above are Apache-2.0 today, which is a fact with a date on it rather than a permanent property.
What comes out on export, and in what shape? A store of extracted facts is not the conversation it came from, and the two are not interchangeable when you need to leave or to rebuild. Whether the export is a contractual obligation or a product feature that can be withdrawn is a separate question, and CM-011, Who owns the company brain?, reads the published agreements for it.
Everything above was read on one day from primary pages, and two of those pages carry no publication date at all. Re-read anything load-bearing rather than citing this piece for it.