Chapter 6

Why does a memory system need a delete button?

Why an agent that never forgets gets worse over time, not better. We will also see the three forgetting policies that keep a store small and true, and what forgetting has to do with privacy.

4 min read846 words3 recall cards

Before you read, guess

How should a memory system handle duplicates, old data, unused events, and total user removal?

Take ten seconds and guess — even a wrong guess makes the answer stick. Tap to see where the chapter lands, or just read on.

Dedup at the door, close old rows instead of deleting them, let unused events fade after ninety days, and keep one clean switch that erases a whole person.

In this blog, we will learn why an agent that never forgets gets worse over time, not better. We will also see the three forgetting policies that keep a store small and true, and what forgetting has to do with privacy.

The hoarder

A hoarder never throws anything away, and soon cannot find the one thing they need. An append-only memory store is a hoarder. Every session adds a few candidate facts, forever.

one active user, append-only
2 sessions/day x 3 candidates = 6/day -> 2,190/year -> 4,380 in two years
5 of them say where Maya lives; 4 are stale

The class simulation over 24 months: append-only reaches 4,320 memories per user. Consolidation plus decay holds it at 1,544, about 64 percent smaller. At a million users that is 14 TB versus 5 TB. Storage is the loud reason.

The quiet reason: retrieval dilution

The quiet reason matters more. Retrieval returns the top three. If two of the three are stale, the model reads the wrong answer first.

query: "where does Maya live?"   top 3 from an append-only store

rank  score  memory                   status
  1   0.89   Maya lives in London.    stale (2024)
  2   0.88   Maya lives in Paris.     current
  3   0.88   Maya lives in Bristol.   stale (2021)

Near-duplicate sentences embed within 0.01 of each other, so which one ranks first is luck. Precision at 3 is one in three. Forgetting is not data loss; it is precision.

Policy 1: dedup at write time

The cheapest forgetting is never storing the duplicate. Two checks, no LLM:

Same text hash as an existing memory: skip.
Cosine similarity above 0.95 to an existing memory: skip.

Mem0 v3 does the first and asks the extractor to do the second by showing it the ten most similar memories. We do both in code, so a sloppy extractor still cannot flood the store.

Policy 2: supersede, then hide

From the last blog: a changed fact closes the old row's validity window instead of deleting it. The old row stays for history questions, but the default search only returns open rows. So "where does Maya live?" sees one address, and "where did she live before?" is still answerable.

This is forgetting from the read path's point of view without forgetting from the audit's point of view. Both sides are happy.

Policy 3: decay by category

Category	Policy	Why
semantic	never expire; supersede on change	"vegetarian" does not age out
episodic	expire ~90 days after last access	"dentist Tuesday" decays to noise
procedural	never expire; user-editable	standing orders
everything	dedup at write time	duplicates dilute top-k

The clock for episodic decay is last_accessed, not created_at. A memory that keeps getting retrieved keeps earning its place. One that nobody asks about for three months goes to cold storage.

recency = 0.995 ^ hours_since_last_access
   1 hour     0.995
   1 day      0.887
   1 week     0.431
   1 month    0.027
   3 months   0.000 (effectively)

The same curve that ranks memories on the read path decides who gets expired by the nightly job. One formula, two uses.

What the merge rate does to the numbers

The simulation assumed a fixed 45 percent of candidates merge into existing memories. Real profiles saturate: after a year, most new candidates about a well-known user are duplicates or updates. Solving for the merge rate that lands a heavy user at the notes' 200 memories gives about 93 percent. That is where a mature profile ends up, and it is why the store size in the notes (200 per user, 664 GB total) is a reasonable planning number.

Forgetting on purpose: privacy

Some things must be forgotten before they are ever stored, and some must be forgotten on demand.

Write-time policy. The extraction prompt refuses financial details, credentials, and anything the user asked not to remember. The class experiment stores "switched to oat milk" and "use metric units" and withholds the salary, the wifi password, and the surprise party. The withheld list names the kind of thing, never the secret.

The right to be forgotten. Every row carries user_id, so one delete-by-filter call erases a user: 3 memories to 0 in about 4 ms in the experiment, while the other user keeps theirs. The vectors are personal data too (embeddings can be inverted back to text), so erasure has to cover the vector column, caches, and logs.

One edge case worth remembering: deleting a chat does not delete the memories extracted from it. Those are separate rows with their own delete path.

Closing

A memory that never forgets is a hoarder who cannot find anything. Dedup at the door, close old rows instead of deleting them, let unused events fade after ninety days, and keep one clean switch that erases a whole person. That is how the store stays small, true, and legal.