All lessons · 44
Context Failure Modes: When More Context Makes Things Worse
Lost-in-the-middle, context poisoning, context rot, and contradictory instructions — how context breaks, how to detect it, and how to prevent it.
Context does not just run out. It goes bad.
The previous articles treated the context window as a budget to fill. This one is about the nastier truth: a full window can be worse than a small one. Everything the model sees influences its answer — including the junk.
Why care? Because these failures are the ones that survive testing. Your demo prompt works, the staging run looks great, and then a real user with a longer history and a messier question gets something confidently wrong. Nothing crashes, no error appears in the logs. Here are the four failure modes you will meet in production — and what to do about each.
A quick word on hallucination, since it comes up below: it is just the name for the model stating something plausible and false. It is not lying and it is not random — usually the context made the wrong answer the most likely next sentence.
The counter-intuitive part: more context can lower accuracy
The instinct is to treat context like fuel — more of it means the model can go further. It behaves much more like a desk: every extra sheet is one more thing competing for attention. Three separate mechanisms make adding context an actively bad move:
- Distraction. Irrelevant material is not ignored, it is used. A chunk that merely shares keywords with the question competes with the right chunk, and the model will weave both into one fluent answer. Going from 5 trusted chunks to 25 hopeful ones is a downgrade, not an upgrade.
- Position. Attention is strongest at the beginning and end of the window and weakest in the middle. So new context does not merely add noise — it pushes existing facts into the dead zone. A fact that was perfectly visible in a short prompt can effectively vanish once you pad around it.
- Contradiction. Every block you add is another chance to introduce a second, conflicting rule. The model then silently picks one today and the other one tomorrow.
The consequence is uncomfortable if you have spent weeks improving retrieval recall: precision usually beats recall. Ten chunks you trust beat fifty you hope contain the answer. When quality drops, subtracting context is almost always faster than adding more of it.
Poisoning: one irrelevant chunk derails everything
The most common failure. Your retrieval matches on keywords, pulls in a document that looks related but is not — and the model weaves it into the answer. Click through this support conversation and watch it happen:
The price was in the context the whole time. But snippets two and three — retrieved because “canvas” matched — polluted the window, and the model kindly summarized the pollution into the answer. Nothing was wrong with the model’s arithmetic or its pricing data; the window was simply dirty.
Look at the last two messages: the same model, the same question, one filter added upstream. The fix is almost always retrieval, not prompting — better filters, fewer and more relevant chunks, and instructions like “use only the pricing snippet for pricing questions”.
Lost in the middle: the dead zone
Model attention is not uniform across the window. Facts at the beginning and the end get noticed; facts buried in the middle of a very long context are reliably under-used — like a reader who skims the middle chapters of a very long report. This is the classic “lost in the middle” effect: put the critical constraint in the middle of 60K tokens, and the model may follow every instruction except that one.
Here it is happening, in a brief with forty instructions:
The 150-word limit was instruction 20 of 40 — dead center of the pile. The model obeyed instruction 1, instruction 2 and instruction 40 perfectly. The one in the middle did not exist for it.
The practical countermeasure is ordering: put the most important material first (system prompt, key facts, hard constraints) and the most recent user message last. If you must process a huge haystack, split the job across calls and merge the results, instead of praying the middle gets read.
Rot: slow decay in long sessions
Context rot is the gradual quality decline in long sessions. Turn forty of a conversation carries turn twelve’s abandoned approach, three outdated assumptions and an error message nobody cleaned up. Each individual item looks harmless; together they blur the model’s picture of the task. Symptoms: the model re-answers questions already settled, mixes up old and new requirements, or gets slower and vaguer. The fix is the one from the previous article: compaction and a fresh start when a session gets long.
Contradictory instructions: the silent tie
Old instructions never die in a context — they just get outvoted. If the system prompt says “always answer in JSON” and turn twenty of the history says “actually, plain text is fine from now on”, the model holds both rules and guesses which one wins today. Output format drifts between requests, and nothing crashes — it just quietly becomes unreliable.
Prevent it by treating old instructions as code: never append “ignore what I said before” into history. Either edit the standing instruction (system prompt, memory) or start a fresh session with the new rule baked in.
Detecting and preventing
- Read the actual context. Log the full payload sent to the model and inspect it when answers go wrong — most failures are visible in one read.
- Trace retrieval. For every RAG answer, record which chunks were used. Irrelevant chunks in the log usually explain the hallucination.
- Evaluate context quality briefly and cheaply: sample real sessions and ask three questions — is everything in the window relevant? is the critical fact near the edges, not the middle? do any two instructions conflict? If you want it automated, have a model grade each context for relevance and contradiction before it is sent.
- Prefer subtraction. When quality drops, removing context almost always helps faster than adding more of it.
The debugging ritual
Wrong answer? Do not rewrite the prompt first. Pull the exact context that was sent, read it top to bottom, and ask: what in here would mislead a tired human? You will find the culprit in minutes.
Your RAG bot underperforms, so you raise the number of retrieved chunks from 5 to 25. What usually happens?
A support bot keeps adding irrelevant facts to correct answers. Where is the bug most likely?
You have three hard constraints and a 60-page brief. Where should the constraints go?
Output format drifts between requests, and nothing crashes. The most likely cause:
Where this leaves you
You now have the full context toolkit: what goes in the window, techniques to fill it well, and how it fails. That is exactly the skill set agents demand — because an AI agent is nothing but a model plus a context that it rewrites itself, turn after turn.
Questions?
Join the Telegram channel — happy to discuss context design and share examples.