all posts
architecture · sep 2026

The frontier stopped deleting: ADD-only memory and the end of overwrite

In 2026, the best memory systems independently converged on the same design: never update, never delete — append new memories and invalidate old ones. Here's why overwrite was a mistake, and what replaces it.

The old world: extract, update, delete

The first generation of agent memory worked like a database row. The agent learned something new about you, the system extracted a fact, and then it had to decide: is this a new fact, an update to an old fact, or a deletion? Mem0's original pipeline made exactly this three-way call on every write — ADD, UPDATE, or DELETE — and the LLM had to get the classification right, every time, from a single conversation turn.

It didn't. Updates merged facts that shouldn't have been merged. Deletions fired on ambiguous phrasing. And worst of all, every overwrite destroyed information: once "Alice works at Acme" was updated to "Alice works at Globex," the system could no longer answer "where did Alice work in March?" The write path was making irreversible decisions with partial information — the exact thing a memory system should never do.

April 2026: Mem0 stops updating

The break came from Mem0's 2026 update: the pipeline switched to single-pass ADD-only extraction. No UPDATE. No DELETE. Every observation becomes a new memory, and contradictions are resolved at retrieval time — when the system has the query, the full context, and the strongest reason to care about which version is current.

This is the right division of labor. At write time you have the least information and the most pressure to decide quickly; at read time you have the most information and a concrete question to answer. Moving the hard decision from the worst moment to the best moment is the whole insight.

figure · move the hard decision to the best moment
old write path · decide with partial infonew observationLLM: ADD / UPDATE / DELETE?irreversible writeevery UPDATE bets you'llnever need the old versionadd-only · decide at read timenew observationsingle-pass ADDversion chain growscontradictions resolved at read time,with the query in hand

Zep's version: invalidate, don't delete

The graph camp arrived at the same place from a different direction. Graphiti (the engine behind Zep) gives every edge a bi-temporal validity window — t_valid and t_invalid. When Alice changes jobs, the old edge isn't deleted; its validity window is closed and a new edge opens. Contradictions invalidate rather than destroy.

The payoff is temporal queries. "Where does Alice work now?" filters to edges valid today. "Where did she work in March?" filters to edges valid in March. A system that deletes can answer the first question; only a system that keeps history can answer the second. Temporal reasoning is the hardest slice of every memory benchmark — and it's unanswerable by construction if you overwrite.

figure · invalidate, don't delete
marjunnowmutate-in-placeAlice @ AcmeAlice @ Globex✕ overwritten — “where did Alice work in March?” is unanswerableadd-only · invalidatev1 · Alice @ Acmet_valid mar → junv2 · Alice @ Globext_valid jun → nowcontradicts“where did Alice work in March?” → validity filter → v1
takeaway
Premature consolidation destroys information. Every UPDATE is a bet that you'll never need the old version. The field spent two years losing that bet before it stopped making it.

What this looks like in MemOS

We implemented the convergent design locally, in SQLite, with no cloud service involved:

  • Typed edges. Memories link through typed relations — relates_to, supports, contradicts — so a superseded fact isn't edited in place; it gains a contradicts edge to its replacement. Both versions survive, with provenance.
  • Version timeline. memos history <id> (and the memos_history MCP tool) walks the full lineage of a memory — every version, when it changed, and why. Nothing is ever truly gone.
  • Retain pre-filter. Since we never delete, the write path needs a bouncer instead: incoming observations are scored on length, signal density, action verbs, and novelty, and anything below threshold never pays for an embedding round-trip. Append-only doesn't mean append-everything.

The twist: never deleting is a local-first luxury

Here's the part the vendors won't advertise: ADD-only memory is expensive to store. Every contradiction kept is tokens on disk and vectors in an index, forever. For a cloud platform charging per stored token, history is a cost center — which is exactly why the managed services were the last to give up deletion.

Local-first flips the economics. A SQLite file on your disk holds years of memories for effectively zero marginal cost, and retrieval filters by validity window before the LLM ever sees the stale versions. The architecture the research converged on is one that only makes economic sense when you own the storage. That was always the bet behind MemOS: the best memory design and the cheapest memory deployment are the same design, as long as the disk is yours.