Build1 distinct publisher3 min readPublished
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

Compiled by The EngineerSomething wrong?How this is made
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 [6]. 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 [7]. 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 [11][12].
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 [1][2]; Mem0 spends two per ingested message, one to extract and one to adjudicate [7], so the reconciliation design carries an extra model call per message over the retrieval-only baseline [1]. 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 [10]. Writes are async by default [9], 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 [5]. 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 [2]. 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 [7]; 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 [11][13]. Same user correction, two different records afterwards: one store can show what it believed last month, the other cannot [3]. 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 [14], but the text supplied here stops mid-sentence in the Zep section and never reaches Letta [18]. And it carries no benchmark figures at all [19], 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.
Ranked by verification strength, evidence, and original report placement.
The piece states that real memory is not retrieval but deciding what is still true.
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.
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.
The author recommends Zep where point-in-time correctness matters, such as support timelines and longitudinal user profiles.
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.
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.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
One practitioner explainer, mechanism-level and unmeasured
Everything rests on a single dev.to post with no second publisher, no vendor documentation, and no measurements. Its architectural descriptions are specific and internally consistent — named LangChain classes, Mem0's four-way decision set with a code snippet, Graphiti's bi-temporal edges, Letta's memory-editing tools — which is real evidentiary substance for design decisions. But the piece supplies no benchmark, accuracy, cost or latency figures, and the supplied text is truncated with the ledger's own account of where it breaks off contradicted by the body, so the record is thin and partly inconsistent.
No adoption data supplied
The cluster contains no deployments, usage disclosures, download or customer figures, release notes, or production case studies for Mem0, Zep, LangChain memory or Letta. The only adoption-adjacent datapoint is a secondhand, undated mention that Mem0 added a Neo4j-backed graph layer, which describes a capability rather than uptake. Inferring adoption from vendor prominence or from the author's recommendations would be a guess.
Mildly overstated framing, honestly hedged mechanics
Slightly positive rather than neutral. The framing claims are absolutist and unverified — that four named systems 'solve almost none of the same problems', that retrieval is 'the easy 20%', that real memory simply is deciding what is true — and none of it is backed by a measurement, so a reader could overrate how settled these distinctions are. Against that, the piece consistently discloses costs it could have hidden: Mem0's extra write-path hop and memory-bloat failure mode, Zep's audit trail being overkill for current-state-only needs, Letta's non-determinism, and LangChain leaving 'just work' as an exercise for the reader. That self-limiting keeps the gap small.
No affiliation or sponsorship information
The supplied material discloses nothing about the author's relationship to Mem0, Zep, LangChain or Letta, no sponsorship or affiliate arrangement, and no pricing or commercial terms for any product discussed. dev.to is a general developer publishing platform, which tells us nothing about this post's incentives specifically. Scoring incentive pressure here would require inventing facts about the author's interests.
Low — single unverified source, partly inconsistent record
Confidence is limited by structure, not by plausibility. One publisher, one author, zero corroboration, zero measurements, no adoption or incentive signal, and a truncated body whose truncation point conflicts with the ledger's description of it. The mechanism-level claims are coherent and the kind of thing readers could verify against vendor docs, which keeps this from the floor, but nothing in the cluster independently confirms any of them.
build
The query a vector index cannot answer, whatever you embed it with1 distinct publisher
build
Session isolation is not data isolation, and write-side memory defenses cannot see the difference1 distinct publisher
build
A Gulf bank's compliance rule priced out to $133 of GPU per seat1 distinct publisher
build
The one signal agent memory learns from is the one production traffic almost never sends1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 26, 2026