In LLM memory consolidation, recency of mention decides what gets written back
Measured across two model families: a retired value echoed last is re-stored 45-85% of the time; put the correction last and it drops to 0.00. Over three real write-back cycles the error locks in rather than grows. A write-path guard zeroes it unconditionally; a prompt instruction works only if the model obeys.
The problem. Agent memory has a write-back loop nobody benchmarks: the agent retrieves memories, acts, and then consolidates — it writes something back into the store. If the retrieved surface contains a corrupted item (a stale value someone restated after it was corrected), the consolidation step can re-store the corruption, and the store hands it back next time. A production bug report shows where this ends: in mem0 issue #4573, one hallucinated "User prefers Vim" spawned 808 copies through exactly this loop (stored, recalled, re-extracted as ground truth), and upgrading the extraction model did not fix it. We measured the loop's model layer directly.
The setup. Two model families (glm-5.2, deepseek-v4-flash), n=20 per cell, Wilson 95% CIs, zero errored calls. Synthetic config-style facts the models cannot know parametrically, so nothing can be rescued from training data — measured rates are the clean-propagation condition and plausibly an upper bound for well-known facts. Each case: a value is asserted, corrected, then the retired value is restated (an echo). The model is asked, in a separate call with no action question, what single value should be stored as current.
Finding 1: consolidation re-stores the echoed stale value, and the driver is recency of mention.
| condition (store-only consolidation) | glm-5.2 | deepseek-v4-flash |
|---|---|---|
| permissive surface, echo mentioned last | 0.45 [0.26, 0.66] | 0.85 [0.64, 0.95] |
| same three lines, correction mentioned last | 0.00 | 0.00 |
| surface cleaned by a write-path guard | 0.00 | 0.00 |
Asked alone, with nothing to act on, the model re-stores the retired value in 45 to 85 percent of cases. Flip the order so the correction is the last line mentioned and the rate drops to zero in both families, even though the stale value now appears twice. This is consistent with pure recency of mention deciding the write-back, not majority of mentions and not content plausibility. (We first measured act and store in one call, 0.60/0.75; the separate-call control rules out within-response consistency as the explanation. CIs overlap.)
Finding 2: over real write-back cycles, the error does not grow. It locks in. We ran the actual loop for three cycles: the model's consolidation is written back into the store, and the next cycle reads what the store now returns. On a naive append-only store, the average stale share decays (glm 0.30 → 0.15 → 0.10; flash 0.75 → 0.60 → 0.50), because correct consolidations compound too. But at cycle three, half of flash's cases are still returning the retired value. One consolidation event tends to decide the fact's fate; the loop then preserves whichever way it went. This is persistence, not amplification — the 808-copy production case additionally involved re-extraction on recall, which we did not model, so we reproduce the mechanism's lock-in, not its multiplication.
Finding 3: the mitigation stack has a clear ordering.
| defense | echo write-back | cost |
|---|---|---|
| write-path guard (echo retirement at the store, here inspeximus's) | 0.00, every condition, all 3 cycles | none measured on this task; adaptive attackers untested |
| "store only verified values" instruction | 0.00 on this fixture, both families | depends on the model obeying; glm abstained 6/20, and the recall cost of abstention is unmeasured |
| extractor-layer semanticization (mem0 pipeline) | partial: 0.25 | blurs revert intent elsewhere: on a "go back" surface the model honors the user's instruction only 0.45–0.65 of the time, vs 1.00 on raw or guarded surfaces |
The store-level guard wins because it removes the stale item before the model ever sees it, and it does not rely on model obedience. Fair credit: mem0's extractor genuinely dampens the echo; the cost shows up on a different case. And an honest warning cuts against us too: the recency mechanism hands an attacker the recipe (get your value mentioned last), and our guard has only been tested against the patterns these fixtures cover.
Where this sits. Zombie Agents (arXiv:2602.15654) showed injected memories persist through memory evolution; Faulty Memories (arXiv:2605.12978) showed consolidation degrades even clean inputs; STALE (arXiv:2605.06527) measured the retrieve-versus-act gap. The specific coupling — what a model acts on, it also re-stores, at what rate, and which layer of defense severs it — was the unmeasured seam. It is also the natural sequel to our cross-system integrity benchmark: that measured whether stores hold the corrected value; this measures whether the model puts the stale one back. It rhymes with a much older result: from DNS cache poisoning to model collapse (Shumailov et al., Nature 631), the durable fix for read-act-write corruption has always been a gate at the write path, because the write is the only point in the loop where clean and corrupted are still distinguishable.
Honest scope. n=20 per cell, two model families, one fixture family, three cycles, synthetic facts by design. inspeximus's cells run on our own fixture and we make inspeximus — the harness and every result JSON are in the repo, and the mem0 cells run its real pipeline (on an Ollama stack, disclosed in the probe; Graphiti was excluded because that stack degraded its extraction below measurement grade, which is a statement about our budget, not about Graphiti).
The falsifierIf the separate-call control had shown low store-only rates, write-back would have been prompt-artifact and dead. If the reversal control had not moved the rate, recency would be the wrong mechanism. If the guarded arm had leaked in the loop, the write-path claim would be dead. Each control could have killed its claim; none did.
FAQ
What is write-back contamination in agent memory? When an LLM agent consolidates memory, it can re-store a stale or corrupted value it just retrieved, closing a loop in which the store re-poisons itself. In our measurement, models re-stored an echoed retired value in 45 to 85 percent of cases on a permissive surface.
Does the corruption grow over time? Not in our three-cycle measurement. It locks in: the average stale share decays, but half of one model's cases were still returning the retired value after three write-back cycles. Persistence, not amplification.
What actually decides what the model writes back? The last-mentioned value. With the correction mentioned last, stale write-back fell to zero in both model families, even when the stale value appeared twice. Recency of mention, not recency of truth.
Can a prompt instruction fix it? On this fixture, yes: "store only verified values" dropped stale write-back to zero. But it depends on the model obeying, one model abstained on 6 of 20 cases (an unmeasured recall cost), and a store-level write-path guard achieves the same zero unconditionally.
Is this the same as memory poisoning attacks? No attacker is needed. The practitioner phrase is that nobody is poisoning us, we poison ourselves: the loop runs on benign restatements. Attack work (AgentPoison, MINJA, Zombie Agents) studies adversarial injection; this measures the everyday mechanism those attacks exploit.