Context Failure Modes: Poisoning, Distraction, Confusion, and Clash

A model can only reason over what is in its context window, so every failure that is not a raw reasoning failure is a failure of what entered that window. Most teams treat these as a single blur of bad answers, but the failures have different causes and different cures, and lumping them together means fixing the wrong thing. The four modes below cover the large majority of context problems in real systems. This page defines each one precisely, shows how to recognize it, and gives the fix, so that when an answer goes wrong you can name the mode rather than guess. All four are distinct from context rot, the gradual quality decline that comes from window length alone, and they can each occur even in a short window.

Context Poisoning

Context poisoning happens when a false or unreliable piece of information enters the window and the model treats it as fact. Because the model has no way to independently verify what you put in front of it, anything in the context is taken as ground truth for that call. Once a poisoned fact is in the window, it propagates: the model reasons from it, builds on it, and produces an answer that is confidently wrong because its premise was wrong. This is one of the most damaging modes because the model gives no signal of trouble, the answer looks well reasoned and is internally consistent, it just rests on a falsehood you supplied.

The poison usually enters through one of three doors. Retrieval brings in a stale document, a draft that was never finalized, or a passage that is correct in its original setting but wrong for this question. Memory returns a fact that was true once and has since changed, such as a user's old shipping address or a superseded price. Tool output returns an error or an empty result that the model reads as a real answer. In agent loops the danger compounds, because a poisoned intermediate result written to a scratchpad gets read back on the next step and treated as established, so a single bad fact can steer many downstream decisions.

The fix is to gate what enters the window on reliability, not just relevance. A retrieval or memory item that is highly relevant but low confidence should be held back or flagged rather than injected as plain fact. This is exactly why a memory layer that tracks confidence matters: Adaptive Recall raises a fact's score when independent sources corroborate it and lowers it when something contradicts it, so the selection step can prefer well-supported facts and keep shaky ones out of the window. Freshness checks catch stale memories, and validating tool output before feeding it back catches errors masquerading as results. The principle is that the window should carry information you have reason to trust, because the model will trust all of it equally.

Context Distraction

Context distraction happens when irrelevant but plausible content in the window pulls the model away from the correct answer. Unlike poisoning, the distracting content is not false, it is simply not relevant to this request, and its presence lowers the fraction of the window that actually bears on the question. The model's attention is finite, and every irrelevant passage competes for it, so an answer that would have been clear from three relevant documents gets muddied when those three sit among forty that merely relate to the topic. Distraction is the direct cost of low relevance density, and it is the reason that adding more context often makes answers worse rather than better.

Distraction is the failure mode that punishes the instinct to stuff the window. A team worried about missing information includes everything that might be relevant, on the theory that more context is safer. The opposite is true: each marginally relevant item dilutes the signal and gives the model another plausible-looking thread to follow. A support question about a refund gets a worse answer when the whole policy manual is in the window than when just the refund section is, even though the manual contains the refund section, because the surrounding forty pages are all plausible refund-adjacent text the model now has to reason past.

The fix is aggressive selection and reranking. Retrieval should favor precision once candidates are gathered, keeping the few items that truly answer the question and dropping the rest, which is the method covered in how to retrieve the right context. A reranking step after initial retrieval is the single most effective defense, because raw similarity search returns many loosely related items and reranking is what separates the ones that answer the question from the ones that merely mention its topic. Being as disciplined about exclusion as about inclusion is the whole discipline here, and it is why a lean window usually beats a full one.

Context Confusion

Context confusion happens when the window contains two or more pieces of information that conflict, and the model cannot reliably determine which to use. The classic case is a current fact sitting next to a stale one: the window holds both the old price and the new price, or the user's previous preference and their updated one, and the model may pick either. Confusion differs from poisoning because both facts entered legitimately, the problem is that they contradict and nothing in the window tells the model which one wins. The result is nondeterministic, the same query can produce the right answer or the wrong one depending on which conflicting item the model happens to weight.

This mode is common in systems that accumulate memory or history without reconciling it. Every time a user states a preference, the raw statement gets stored, and over months the store holds a trail of contradictory preferences that all get retrieved together. History has the same problem: a long conversation where the user changed their mind twice contains all three positions, and including it verbatim hands the model a contradiction. Tool results can confuse too, when two tools return different values for the same quantity and both land in the window.

The fix is reconciliation before injection, so the window carries a resolved view rather than a raw pile of conflicting items. A memory layer should supersede old facts when new ones contradict them, keeping the current value authoritative and demoting or removing the outdated one, rather than storing every statement forever. History should be summarized in a way that captures the final state, the user wants option B, not the sequence of changes that led there, which is covered in how to manage conversation history. When a genuine conflict cannot be resolved automatically, the honest move is to surface it, letting the model note the ambiguity rather than silently guessing. A system that keeps its memory reconciled avoids most confusion before it reaches the window.

Context Clash

Context clash happens when content in the window contradicts the system instructions, producing inconsistent behavior. The system prompt sets the model's rules, its role, its tone, and its constraints, but retrieved documents, memory, or examples can carry information that pulls against those rules. A support assistant instructed never to promise refunds retrieves a help article that describes the refund process in encouraging terms, and the model, now holding both the rule and the encouraging text, behaves inconsistently. The instructions and the retrieved content clash, and the model has no principled way to know that the instructions should win.

Clash is subtle because each piece is individually correct. The system prompt is right, the retrieved article is right in its own context, the failure is only in their combination inside one window. It shows up most in systems that retrieve broadly from a knowledge base written for a different purpose, such as marketing pages or general documentation, and feed it to a model operating under stricter or different rules. Few-shot examples can clash too, when an example demonstrates a behavior that a later instruction forbids, leaving the model with mixed signals about what is actually wanted.

The fix has two parts. First, establish a clear precedence in the window so the model knows the system instructions are authoritative, which is partly a placement decision covered in how to structure the context window: pin the instructions where they will not be displaced and, where the model supports it, keep them in the dedicated system role. Second, filter retrieved content against the operating rules, so a passage that contradicts a hard constraint is trimmed or excluded rather than injected whole. When the knowledge base and the assistant's rules were written for different purposes, some curation of what that base is allowed to contribute is the durable fix, because you cannot rely on the model to always resolve the clash in favor of your instructions.

Diagnosing Which Mode You Have

When an answer is wrong, the fastest path to a fix is naming the mode, and the way to name it is to inspect the window that produced the answer. This is why observability matters: if you have logged exactly what entered the context for the failing request, you can read it and see which failure it was. If the window contained a false fact the answer relied on, it is poisoning, fix the source's reliability gating. If the window was full of loosely related content and the relevant part was buried, it is distraction, fix selection and reranking. If the window held two conflicting facts, it is confusion, fix reconciliation. If the window carried content that fought the instructions, it is clash, fix precedence and filtering.

Without that log you are guessing, and guessing tends to lead teams to blame the model or endlessly retune the prompt wording while the real fault sits in retrieval or memory. The four modes are distinguishable precisely because they leave different fingerprints in the window, so the discipline of capturing the assembled context on every request is what makes them diagnosable. Measuring these failures systematically rather than catching them anecdotally is the subject of how to measure context quality, and the broader practice of turning context into a testable system is covered in how to build a context pipeline. The payoff is that a class of bug that feels mysterious, the model just gives bad answers sometimes, resolves into four named problems with four known fixes.