The memorable version of mem0's original algorithm asked an LLM to choose among ADD, UPDATE, DELETE, and NOOP. It was an intuitive way to maintain a compact user profile. It also gave one probabilistic call the authority to rewrite history.

The current 2026 path takes a different position: extract additive facts once, deduplicate them deterministically, and move conflict resolution toward retrieval.

The V3 batch write path

The current Memory.add implementation builds a bounded context from the new messages and a small set of retrieved existing memories. Existing UUIDs are mapped to short integer IDs before they are shown to the model. That reduces a mundane but real failure mode: language models are poor at reproducing long opaque identifiers.

One extraction call returns candidate facts to add. There is no model-generated update or delete plan in this path. The deterministic phase then performs the bulk work:

  1. generate embeddings for the extracted facts in a batch;
  2. hash fact content for exact deduplication;
  3. persist new memories and ADD history records in batches;
  4. create entity links for the newly stored facts.

This architecture narrows the LLM's responsibility to semantic extraction. Identity, deduplication, persistence, and audit history remain code paths that can be tested independently.

It also changes the failure mode. A mistaken extractor can add a bad fact, but it does not silently erase the previous one. Contradictions accumulate instead of being resolved eagerly.

Retrieval now carries more semantic weight

The search path combines three signals:

  • vector similarity for semantic relevance;
  • BM25 for lexical evidence;
  • entity overlap as a bounded boost.

The implementation first applies a semantic threshold. BM25 is normalized with a sigmoid-like transformation, and entity matches add a limited score. The final value is normalized by the maximum possible contribution.

That ordering prevents a rare keyword or a same-named entity from rescuing a candidate that is semantically unrelated to the query. Lexical and entity evidence refine a relevant candidate; they do not replace the relevance gate.

The query is also lemmatized and entities are extracted before ranking. In other words, the system is not simply “vector search plus a few points.” It constructs three partially independent views of relevance and then fuses them under explicit weights.

Append-only does not solve time

Suppose memory contains both “the user lives in Beijing” and “the user moved to Shanghai.” ADD-only storage correctly preserves both events. A timeless ranker can still return the wrong current answer.

The missing dimensions are validity interval, source confidence, correction semantics, and expiration. mem0's hosted platform includes additional temporal and proprietary optimizations, and the repository explicitly distinguishes those from the open-source core. Benchmark gains from the managed service should not be attributed wholesale to the OSS write path.

This distinction is healthy. It also shows where the product frontier is moving: not toward a more elaborate CRUD prompt, but toward lifecycle-aware evidence ranking.

Operational consequences

An additive memory log is easier to audit and replay. It is also larger, and deletion becomes more complex. A privacy deletion must remove the primary record, vector entries, graph links, caches, and any derived summaries. “We never update old facts” cannot become an excuse for retaining a person indefinitely.

The architecture therefore benefits from two separate concepts:

  • an immutable event or evidence history for internal accountability;
  • a user-facing active profile with explicit retention and deletion policy.

Conflating the two recreates the original problem at a different layer.

Personal take

mem0 will resonate with teams building support agents, sales assistants, personalized applications, and any product that needs cross-session continuity without adopting a full agent framework.

The market opportunity is memory observability: why a fact was extracted, which source produced it, how it ranked, when it expired, and which derived stores still contain it. Companies will eventually monitor profile formation as carefully as database migrations.

I read ADD-only as a form of machine humility. The system records evidence before declaring which version of a person is canonical. But humility also requires forgetting. A good memory system must preserve the provenance of the past without making the past an inescapable identity lock.

Sources