Proactive Interference: When an Agent Retrieves the Wrong, Earlier Value Instead of the Current One

Proactive interference is the failure mode where an agent asked to retrieve the current value of something that has been updated more than once inside its own context returns an earlier, already-superseded value instead. A support agent tracking a customer's shipping address across a conversation, updated twice as the customer corrects itself, answers with the first address. A coding agent tracking a config flag that got flipped three times in one session reports the second setting, not the third. The correct value is not missing and is not buried deep in a long-forgotten turn; in the benchmark that isolates this effect, the current value sits immediately before the query, with input length held fixed, and the agent still reaches past it for something older. What fails is not memory capacity in the sense of "not enough tokens," it is the ability to suppress a competing, no-longer-relevant value that is still sitting in the same context window.

This is a different axis from three adjacent patterns already covered here. Context rot is accuracy degrading as a function of how much is in the window; proactive interference is measured with input length held constant across trials specifically to rule that out, and it still appears, which means it is a separate, independently-acting variable rather than a symptom of context rot with a new name. Memory poisoning requires an adversary corrupting what's stored; proactive interference shows up from entirely benign, legitimate updates, three consecutive corrections to the same field with no attacker involved. And it is not the positional "lost in the middle" bias, where retrieval accuracy depends on where in the context the target sits; the benchmark that documents this effect deliberately places the correct, current value last and closest to the query, which minimizes search difficulty, and the decline shows up anyway, driven by how many prior, similar-looking values came before it rather than by where the right one is.

Mechanism

The core evidence comes from PI-LLM, a benchmark built specifically to isolate interference from context length as separate variables, adapting the proactive-interference paradigm from cognitive psychology into a key-value tracking task. A model is shown a stream of key-value pairs, some fixed set of keys, each updated repeatedly with a new value, and is asked only for the final, current value of each key, a value that is always the most recent thing said about that key. Testing 35 models spanning 0.6B parameters (Qwen3-0.6B) to 637B parameters (DeepSeek-V3), including GPT, Claude, Gemini, and Grok families, the study found retrieval accuracy declines log-linearly toward zero as the number of updates per key grows, a pattern that held across every model tested regardless of architecture, and held even in a second experiment where total input length was fixed and only the update count varied, confirming the decline tracks interference load and not context length (Wang & Sun, arXiv:2506.08184). At the highest tested update count, 400 updates per key, mid-sized models in the study's own grouping collapsed to near-zero accuracy with only one exception, while the largest models held a relatively higher accuracy, a gap the authors capture in an Interference Endurance Score, where model size predicted higher endurance but the model's nominal context window length did not predict it at all.

The same paper traces a three-stage progression in what a failing model returns as interference increases, not just whether it fails. At low interference, wrong answers cluster tightly around the correct value, typically an adjacent, immediately-preceding update for the same key. As interference rises, the error distribution spreads to much earlier updates, values from far upstream in the sequence rather than the value next to the target. At high interference, the model's output shifts again, a growing share of wrong answers are values that never appeared in the input at all, outright hallucinations rather than retrieval of any real prior value. The authors also found that update order changes the shape of the curve: strictly sequential updates (no re-shuffling) produce a step-function collapse, near-perfect accuracy up to a model-specific threshold and a sharp drop after it, rather than the gradual log-linear decline seen under randomized update order, which means a model can look fully immune at a shallow test depth and fail sharply just past it.

Attempts to fix this with instructions inside the same prompt, telling the model explicitly to forget or deprioritize earlier values, or asking it to first articulate the retrieval goal before answering, produced only marginal improvement in the same study. Interference overrode both recency and direct instruction: even with the correct value positioned last and the model told in plain language to ignore what came before it, the pull toward an earlier value persisted. A second study testing 39 models across a wider size range independently confirms proactive interference is a distinct, dominant failure axis, finding it produces substantially larger performance degradation than the reverse pattern, retroactive interference where new information disrupts recall of something learned earlier, a large effect (Cohen's d = 1.73) that held broadly across the model set, with the two interference directions only weakly correlated with each other rather than reducible to one underlying "memory capacity" score. That paper also reports a dissociation worth flagging honestly rather than smoothing over: model size predicted resistance to retroactive interference but not to proactive interference specifically, a partial tension with PI-LLM's own finding that larger models had higher endurance against exactly this effect. Both papers agree the effect is real, universal, and largely instruction-resistant; they do not yet agree on how reliably scale alone buys resistance to it, which argues for testing your specific deployed model rather than assuming a newer or larger one is safe by default (Chattaraj & Raj, "LLMs Remember First, Forget Last: Dual-Process Interference in Large Language Models").

How to detect it

• Build a PI-style eval for your own agent: pick a fact your agent tracks that legitimately changes more than once in a session (a status field, a stated preference, a config value), update it several times in sequence, and check whether the agent returns the final value, with total input length held fixed across trials so the result isolates interference rather than length.
• Test both randomized and strictly sequential update order at the same depths. A model can pass a shallow sequential test cleanly and still be sitting just short of the step-function threshold where accuracy collapses; testing only a handful of updates will not reveal that cliff.
• Classify failures by which wrong value came back: an adjacent, immediately-prior value signals low interference; a much-earlier value signals rising interference; a value that never appeared in the input at all signals the highest-interference, hallucinatory failure mode. The stage tells you how close to the model's collapse point the deployment already is.
• Do not accept a passing result on an instructed variant ("ignore earlier values," "focus on the most recent update") as evidence of immunity. The instructed condition showed only marginal gains over the unprompted baseline in the benchmark that tested it, so a model that follows the instruction on an easy case can still fail once the underlying interference load rises.
• Track accuracy as a function of update count per tracked fact specifically, not total conversation length or token count. The signature that separates this from context rot is a decline that appears even while total input length stays fixed.

Mitigation

Treat any fact that gets updated more than once or twice in a session as a candidate for an external, single-source-of-truth record rather than something to resolve by re-reading the in-context history. The state externalization pattern, an authoritative ledger the agent reads from directly, sidesteps this failure mode entirely rather than trying to make retrieval more reliable under a condition that in-prompt instructions were shown not to fix.

Where a value must live in context, overwrite rather than append. The PI-LLM benchmark's interference condition is, structurally, a sequence of key-value pairs sharing a key; a conversation or system state log that keeps every past value of a field visible recreates that exact structure. Replacing the old value in place, rather than adding a new line each time a field changes, removes the competing distractors the benchmark shows a model cannot reliably suppress.

Do not treat model size or model recency as a solved substitute for testing. One study found larger models hold a meaningfully higher endurance against this specific effect; a second found model size predicts resistance to the reverse interference pattern but not to this one. Given that disagreement, run the detection checks above against your actual deployed model rather than assuming scale has already handled it.

Test at the update depth your deployment will actually see, not the shallow depth that's convenient to write a quick eval for. Because sequential updates produce a threshold collapse rather than a gradual slope, a model that looks stable at three or five updates to a field can be sitting just short of a cliff that a normal week of real corrections will cross.

Where you can afford to modify inference internals, structural forgetting mechanisms are an early but concrete direction: one proposed approach adds a conflict-aware component that tags when a new value supersedes an old one, a learned gate that removes or compresses the superseded entries, and a periodic consolidation step, reporting 99.5% retrieval accuracy at a moderate interference depth and 97.0% at a higher one against baselines that stayed below 18% on the same task (Xie, "Learning to Forget: Sleep-Inspired Memory Consolidation for Resolving Proactive Interference in Large Language Models," arXiv:2603.14517). That result was demonstrated on a small-scale transformer rather than a frontier-scale deployed model, so treat it as a direction worth tracking rather than a fix available today, and lean on external state and overwrite-in-place discipline in the meantime.

Related terms

• Context rot: accuracy degrading as a function of context length; proactive interference is measured with length held fixed and still appears, making it an independent factor rather than a restatement of context rot.
• Memory poisoning: adversarial corruption of an agent's persistent memory; proactive interference arises from ordinary, non-adversarial repeated updates to the same fact.
• State externalization: the durable, overwrite-in-place record pattern this article's primary mitigation depends on.
• Calibration drift: a failure in the confidence attached to an answer; proactive interference is a failure in which fact gets retrieved in the first place, and the two can compound if a model states high confidence in a value it retrieved from the wrong update.

FAQ

Is this the same thing as the "lost in the middle" positional bias? No. Lost-in-the-middle findings are about retrieval accuracy depending on where the target sits within the context. The benchmark behind proactive interference deliberately places the correct, current value last, closest to the query, specifically to minimize positional search difficulty, and the decline still appears, driven by how many earlier, similar values preceded it rather than by the target's position.

Does a bigger context window fix it? No. The defining experiment holds total input length fixed and varies only the number of updates per key, and the decline appears under that condition too. Context window size did not predict a model's resistance to this effect in the same study; only interference load and, to a partially-contested degree, overall model size did.

Can I just prompt the model to ignore earlier values? Only marginally. Explicit instructions to forget or deprioritize prior updates, and prompts asking the model to state its retrieval goal before answering, produced only small improvements over an unprompted baseline in testing, even with the correct value positioned favorably. Treat prompting as a weak lever here, not a fix.

Is this an adversarial attack, like memory poisoning? No. It shows up under entirely ordinary, legitimate repeated updates to the same fact, no injected or malicious content required, which is what separates it from memory poisoning and argues for external, overwrite-in-place state rather than a security control as the relevant mitigation.

Does this only affect small or older models? No. The universal log-linear decline was observed across all 35 models tested, from 0.6B to 637B parameters, including current frontier GPT, Claude, Gemini, and Grok families. Larger models tend to endure more updates before collapsing, but every model in the study eventually collapsed as update count increased.