BuildNot yet confirmed elsewhere1 publisher3 min readPublished
Agent memory products differ on one thing: whether anything decides a fact is dead
A comparison of Mem0, Zep and LangChain's memory classes puts the split at adjudication rather than storage. Mem0 pays two model calls per message to get it.
The Engineer · Build desk
What happened
- A dev.to comparison of four agent memory stacks argues most of them are a vector store with a label: embed every message, cosine-search the top-k next turn.
- Its worked failure case has the agent insisting at turn 40 that a user's favourite colour is blue because that record ranked highest, three messages after the correction.
- LangChain's ConversationKGMemory extracts triples but cannot invalidate one when a later fact contradicts it, so both sit in the graph with no ranking between them.
- Zep's Graphiti engine timestamps edges with event and ingestion time and flags superseded facts invalid instead of removing them.
Why it matters
- cost Adjudicating facts moves spend onto the write path, so a chat product that stores after every turn pays per message written, not only per message answered.
- contradiction The two managed options disagree on what survives a correction, which means a retention or compliance requirement, not retrieval quality, picks the library for you.
- constraint Re-summarising every turn puts a ceiling on session length that arrives as latency long before anyone notices the token bill.
- decision Choosing the LangGraph building blocks is a decision to staff conflict resolution yourself and keep maintaining it.
Line the designs up and the variable is not where facts sit, it is where the ruling on truth happens, or whether one happens at all. In LangChain's `ConversationKGMemory` it happens nowhere: triples go in, a contradicting triple goes in beside it, and retrieval has no basis for preferring either [9]. In Mem0 it happens on write, as a second model call that compares each extracted candidate against what is already stored and returns ADD, UPDATE, DELETE or NOOP [10]. In Zep it happens at query time, because edges carry both event time and ingestion time and superseded facts are flagged invalid rather than removed, which is how the graph can still answer where someone worked in 2023 after they have changed jobs [14][15].
That gives you the price list. A top-k recall loop spends no model calls deciding what remains true, which is exactly why it repeats the corrected answer [5][6]; Mem0 spends two per ingested message, one to extract and one to adjudicate [10], so the reconciliation design carries an extra model call per message over the retrieval-only baseline [19]. The author is direct about where that lands: an extra hop with extra cost and latency on the write path, plus the failure mode of an over-eager extraction prompt producing hundreds of low-value facts that dilute retrieval [13]. Writes are async by default [12], which moves the latency off the response path without moving the spend.
The worst arithmetic in the piece belongs to the option that looks cheapest. `ConversationSummaryMemory` re-summarises the entire history every turn, so cost and latency climb with conversation length while the stored output stays the same size [8]. Summarise N turns of history once per turn and the tokens you have paid to summarise by turn N scale with the square of N, even though what you keep does not grow at all [20]. Long sessions are where that bill arrives.
The two managed approaches also disagree about what a correction leaves behind. Mem0's decision set includes DELETE [10]; Zep's Graphiti never deletes, it invalidates, which the author frames as an audit trail you get for free and as overkill if you only ever need current state [14][16]. Same user correction, two different records afterwards: one store can show what it believed last month, the other cannot [21]. That is a retention question dressed as a library choice.
Two caveats on the source. It frames four architectures as claiming the same territory while solving almost none of the same problems, Letta included [17], but the text supplied here stops mid-sentence in the Zep section and never reaches Letta [22]. And it carries no benchmark figures at all [18], so the reconciliation quality that the whole argument turns on is described rather than measured. The mechanisms are checkable from the descriptions. The claim that one of them remembers better is not, yet.
What to watch
- Whether any vendor publishes contradiction-handling accuracy separately from retrieval benchmarks, so the decision layer can be measured rather than described.
- Measured write-path token cost per turn for a reconciliation design against a retrieval-only baseline on the same conversation.
- Whether invalidate-never-delete stores ship retention or compaction controls as the graph grows.
Clarity's read
What the record supports and how the coverage leans. The claims behind it follow.
Reality
- Evidence42
- Adoption
- Insufficient
- Hype gap+12
- Incentives
- Insufficient
- Confidence38
Claim ledger
Ranked by verification strength, evidence, and original report placement.
- [1]
The piece states that real memory is not retrieval but deciding what is still true.
- [2]
The author recommends LangChain memory when you are already deep in LangGraph, have specific extraction logic you do not want a black box deciding, and are willing to build conflict resolution yourself.
- [3]
The author recommends Mem0 for multi-session, multi-user products such as support bots, personal assistants and CRM copilots, where facts genuinely change over time and automatic reconciliation is needed.
- [4]
The author recommends Zep where point-in-time correctness matters, such as support timelines and longitudinal user profiles.
- [5]
The dev.to comparison argues most "AI memory" demos are a vector store with a marketing label: embed every message, cosine-search the top-k on the next turn, and call it memory.
- [6]
The author's illustrative failure: at turn 40 the agent tells a user their favourite colour is blue because that memory came back highest-ranked, even though the user corrected it three messages later.
- [7]
LangChain's ConversationBufferMemory, ConversationSummaryMemory, ConversationKGMemory and VectorStoreRetrieverMemory are described as building blocks rather than a memory service, leaving the user to own extraction logic, storage schema and every keep-or-discard decision.
- [8]
ConversationSummaryMemory re-summarises the whole history on every turn, so cost and latency grow with conversation length even though the output size does not.
- [9]
ConversationKGMemory extracts triples but has no mechanism to invalidate a triple once a new fact contradicts it; old and new coexist in the graph and retrieval has no way to prefer one.
- [10]
Mem0's core loop is two LLM calls: an extraction pass that pulls candidate facts from a message, then a second call that compares each candidate against existing memories for that user and decides ADD, UPDATE, DELETE or NOOP.
- [11]
Mem0 stores memories as embeddings in a pluggable vector store (Qdrant, Chroma, pgvector, Weaviate) with metadata, and added a Neo4j-backed graph layer for relationship queries.
- [12]
Mem0's memory addition is async by default, so it does not block the response path.
- [13]
The author's stated tradeoff for Mem0: the conflict-resolution LLM call is an extra hop with extra cost and extra latency on the write path, and an over-aggressive extraction prompt causes memory bloat, hundreds of low-value facts that dilute retrieval quality.
- [14]
Zep's differentiator is Graphiti, a temporal graph engine that timestamps edges with both event time and ingestion time (bi-temporal) and marks superseded facts as invalid rather than deleting them.
- [15]
Because the Zep graph retains history instead of collapsing to a single current value, it can answer where a user worked in 2023 correctly even after the user has changed jobs.
- [16]
The author says Zep's invalidate-rather-than-delete model yields an audit trail for free, valuable in compliance-sensitive domains and overkill if you only care about the current state of a fact.
- [17]
The piece frames four architectures - Mem0, Zep, LangChain's memory classes and Letta (formerly MemGPT) - as claiming the same territory while solving almost none of the same problems.
- [18]
The supplied text contains no benchmark or accuracy figures for any of the systems compared.
- [19]
A retrieval-only memory loop spends zero LLM calls per message on deciding what is still true, while Mem0 spends two, so reconciliation adds two model calls per ingested message over the retrieval-only baseline.
- [20]
If the whole history is re-summarised once per turn, the cumulative summarisation tokens paid by turn N grow with N squared while the retained summary stays a fixed size.
- [21]
Because Mem0's decision set includes DELETE while Zep only invalidates, the same user correction leaves a queryable prior belief in Zep and no record of it in Mem0.
- [22]
The supplied text of the comparison ends mid-sentence in the Zep section and contains no detail on Letta beyond the framing.
Sources
1 independent publisher whose own reporting we read for this story.
- dev.toMem0 vs Zep vs LangChain Memory vs Letta: Which One Actually Remembers?
1 article · August 26, 2026
Topics and entities
Follow any of these and your For You feed starts watching them — no settings page required.