What is memory staleness in AI agents, and why decay doesn't fix it

Memory staleness is what happens when a stored fact was true when it was written, has since stopped being true, and nothing in the system knows that. The agent keeps retrieving it, keeps ranking it highly, and keeps answering from it with full confidence.

TL;DR

• Staleness is not a retrieval problem. The right record comes back — it is just no longer true.
• Time-based decay solves the easy half. It removes memories nobody asks for. The dangerous stale memories are the frequently-retrieved ones, and frequency is exactly what decay protects.
• Similarity-based deduplication has the opposite failure: the more a fact changes, the less it resembles its old version, so the clearest contradictions are the likeliest to be missed.
• The fix is not a forgetting policy. It is making replacement an explicit operation — a new fact names the one it supersedes, and the old one is retired rather than deleted.
• Anything that resolves this at read time is guessing. Anything that resolves it at write time, keyed on what the fact is about, does not have to.

What actually goes wrong

A stale memory is not corrupt. It parses, it retrieves, it looks exactly like a good one.

Say an agent learns in March that a service runs on Postgres. In July it moves to SQLite. If both statements are in memory with nothing linking them, the agent has two facts that cannot both be true and no basis for preferring either. Retrieval will hand back whichever scores higher.

That is the shape of the problem: the wrong answer is the confident one. An agent with no memory says "I don't know" and you go and check. An agent with stale memory tells you Postgres.

Why decay and eviction miss the ones that matter

The standard answer is a forgetting policy — memories weaken with time, or with disuse, and get evicted below a threshold. It is a real technique and it works on a real problem: unbounded stores fill with things nobody will ever ask for again.

It does not address staleness, and the reason is structural. Decay is driven by how often a memory is retrieved. The stale memories that cause damage are the ones retrieved constantly — where the service runs, what the user prefers, who owns a system. High retrieval frequency is precisely the signal decay uses to keep a memory alive.

So the policy protects the dangerous records and evicts the harmless ones. It is not a weak solution to staleness; it is a solution to a different problem that gets mistaken for this one.

This is not a contested reading. Mem0's own writing on the subject reaches it too — describing staleness in high-relevance memories as "a harder, open problem", and noting that decay "does not fully solve high-relevance memories that have become wrong, like an outdated employer, which still require timestamp-aware resolution at the application layer."

Read that last clause again. It hands the problem to the application layer. That is a reasonable engineering position, and it means the memory system is not solving it.

Why similarity thresholds fail in the wrong direction

The other common approach resolves conflicts at write time by comparing the new fact to what is already stored, and superseding when they look similar enough.

The trap is what "similar enough" measures. If the comparison is token overlap across the whole content, then how much of the fact changed moves the score — and it moves it the wrong way.

Take two statements that cannot both be true:

goaltender is associated with the sport of ice hockey
goaltender is associated with the sport of pesapallo

Shared tokens: 7. Union: 10. Jaccard similarity: 0.7000.

A system superseding above 0.7 does not supersede this. Both records stay live, and a search returns both — with no ordering guarantee that the current one comes first. We have measured exactly this against a running server: both stayed marked as latest, neither recorded a supersession, and the stale record ranked first.

The perverse part is the gradient. A tiny correction (ice hockey → ice hockey (men's)) scores high and gets caught. A total reversal (ice hockey → pesapallo) scores low and gets through. The bigger the contradiction, the better its odds of surviving.

What resolving it properly requires

Three things, none of them a heuristic.

1. Key on what the fact is about, not on how it reads

Conflict detection should run on the subject and relation, not on how similar the whole sentence happens to read.

subject:  goaltender
relation: sport
value:    ice hockey

Later:

subject:  goaltender
relation: sport
value:    pesapallo

The values share nothing, and that no longer matters: both records describe goaltender / sport, and that pair has one current value by construction. The size of the change stops deciding whether the system notices the conflict.

2. Resolve at write time

At write time the system holds the old value and the new one side by side, which is the only moment the relationship between them is unambiguous. At read time it holds two contradictory records and a ranking function, and the best available move is a guess. Relevance is not truth.

3. Retire, don't delete

The superseded fact stays queryable and records what replaced it:

ice hockey
    ↓ superseded by
pesapallo

Now the system knows what it currently believes, what it believed before, and when that changed. Deleting destroys the audit trail — and the question "when did this change, and what did we believe before?" is one somebody eventually asks.

How Knowl handles it

Supersession is a primitive, not a cleanup job. Every fact carries a subject and relation, and writing a new value for an existing pair retires the old one and links the two. There is no delete verb in the product at all.

The effect is measurable. On MemoryAgentBench's FactConsolidation task, scored in the benchmark's own harness, turning supersession off drops the same system from 95.0 to 75.0 at 6k context and 89.0 to 73.0 at 262k. Same corpus, same order, same reader model — the only variable is whether contradictions are resolved on write.

Those are single runs at temperature: 0.7 and should be read as directional. The full method, the raw per-question records and the splits where we do worse are published in the findings write-up.

The test to apply to any memory system

Ask what happens to a fact that was true and is now false, and listen for which of these you get:

• "It decays." — then it survives exactly as long as it stays useful, which is the problem.
• "It gets deduplicated." — then ask what the similarity threshold is, and what happens to a fact whose value changed completely.
• "The application layer handles it." — then the memory system is a store, and correctness is your job.
• "The new fact supersedes the old one, and you can see both." — that is the answer.

Stale knowledge is worse than none, because none is honest.