A user moves cities. They tell the agent. Six turns later they ask where to get coffee near home, and the agent — confidently, helpfully — answers for the old city. Nothing errored. The agent "remembered." That's the problem.
Most agent memory is an append-and-retrieve log: every fact a user states gets written, and a query pulls back whatever ranks highest. That design has a blind spot it cannot see past — it has no way to express that a fact changed. The old value and the new value both sit in the index, equally real, and the retriever has no signal telling it which one is current.
The budget illusion
Here's where it gets deceptive. Take a plain vector store, feed it a fact that drifts over time ("X lives in A" becomes "X lives in B"), and ask a current question whose subject and predicate match every historical version.
At a tight, realistic budget — room for roughly one fact — the store picks the current version only about one time in depth. In the benchmark, recall collapses to 0.281, against 0.801 for the same store on a no-drift baseline. The drift didn't make retrieval noisier; it filled the candidate pool with confident wrong answers.
Now widen the budget and watch recall climb back toward 1.000 — and watch why. The store isn't getting smarter. It's returning everything: the current fact and every stale version, all at once, with nothing to distinguish them. You "recovered recall" by handing the agent a pile that happens to contain the right answer somewhere inside it. That's the budget illusion: a generous budget hides a missing capability behind a flood. The tight-budget number is the one telling the truth.
The fix is a capability, not a model
This is the part worth sitting with, because it's where the reflex ("use a better embedder") fails. Give the store one capability — SUPERSESSION_CHAIN, the ability to retire a superseded version from the candidate set — and a current query suddenly sees one candidate per fact instead of a stack of history. Tight-budget recall jumps from 0.281 to 0.867 at a 32-character budget. A +0.585 gain, with the embedder held byte-for-byte identical to the baseline's.
No model was upgraded. The retrieval math didn't change. The store simply stopped offering stale versions as answers. This is the first place in the benchmark where a capability, not a better model, moves the primary metric — and it moves it a lot.
History should still be answerable
Retiring the old version raises a fair objection: what if I want the past? "Where did X live in 2023?" is a legitimate question, and a store that hard-overwrites can't answer it.
This is the second capability, BI_TEMPORAL — resolving a query against valid time, so a superseded fact is still the correct answer to a question about when it was true. In the benchmark, a bi-temporal backend reclaims 373 historical (as_of) queries per seed at the hard tier that are not low-scoring for every other backend — they're unscorable, because no other backend can even attempt them. N/A becomes ≈1.0. That's not a recall improvement; it's a category of question that goes from impossible to routine.
Supersede the present, preserve the past, keep them separable. The two capabilities are different operations and you want both.
Credit where it's due
This isn't a novel insight we're claiming for ourselves — it's a mature idea from temporal databases (valid time vs. transaction time has been formalized for decades) that the agent-memory world has mostly not yet imported. And at least one system has: Zep's bi-temporal knowledge graph tracks both when a fact was true and when it was recorded, which directly anticipates this axis. We think that's the right instinct, and the benchmark quantifies how much it buys: the difference between an agent that answers for your old city and one that doesn't.
The subtle part
The uncomfortable implication for the category: if your memory layer is fundamentally an append-and-retrieve log — and many are — then it cannot represent change, and "recall looks fine at a large budget" is not evidence that it can. It's evidence of the flood. The only honest test is a tight budget, where there's no room to paper over a missing capability by returning everything at once.
So the next time a memory product shows you a high recall number, ask two questions: at what budget, and what happens when a fact changes? The answers separate a store that remembers from a store that merely accumulates.
This is the drift-and-conflict result (W2) from the GRAFOMEM benchmark. Full findings, per-budget sweeps, and the reproducible corpus are at grafomem.com; the code is on GitHub.