The five ways context fails
When an AI feature gives a wrong answer, the instinct is to blame the model. Sometimes the model is the problem. Often it's the information you handed it, and there are five distinct ways that goes wrong — and they have completely different fixes, which is why "improve the prompt" so often does nothing.
Here's the setup, in plain terms. Most AI features work by putting some relevant information in front of a language model along with the user's question, and asking it to answer using that information. The model doesn't know anything about your company. Everything it knows about your world, in that moment, is what you put in front of it.
That bundle of information is called context. Assembling it well is its own engineering discipline — and it is where many real failures start.
Below are the five failure modes, and for three of them, something I actually got wrong. The taxonomy isn't mine; it comes from Atlan's work on context engineering, and it's the most useful map I've found. What's mine are the scars.
This is the one everyone calls hallucination, and the name does real damage — it suggests the model is unreliable, when often the model behaved reasonably given what it was handed.
I spent months assuming our wrong answers were a model problem. When I finally categorised the failures properly, more than half were labelled as the knowledge base lacking the fact, not the model making something up. Then a closer look turned that around again: for most of them, the facts had been extracted all along. They were sitting in tables that nothing put in front of the model.
A lookup tool would report "no definition indexed" for things that genuinely existed — they just hadn't been indexed. The system's answer loop read that as proof the thing didn't exist. A gap in the index had been silently promoted into a fact about the world.
The fix isn't prompting. It's inventory: knowing what you actually hold, and treating "we don't have this" as a different answer from "this isn't true." No amount of prompt tuning reaches a fact that never made it into the context.
This is the failure people feel but can't name. Your demo was magic in March. It's mediocre in June. Nobody changed the model. Nobody edited the prompt. The world moved and the context stayed still.
It's insidious because staleness produces confident wrong answers, not obviously broken ones. A stale fact reads exactly like a fresh one. There's no error, no red test, no alert — just a slow decline in trust that's very hard to trace back to a cause.
The fix is freshness as a tracked property, not a vibe: when was this last verified, against what, and by whom. If you can't answer that for a given piece of information, you can't tell a user how much to trust it — and neither can your system.
Documentation says one thing. The code says another. Both get retrieved. The model picks one — effectively at random, or based on which happened to rank higher — and answers with total confidence.
The fix seems obvious: rank your sources by authority. Code beats docs. Verified beats inferred. We built exactly that — a tier for every source, a confidence score, and a ranking step that sorted by authority at every point where results were returned.
The tier was hardcoded to the same value for every prose document. Every piece of the machinery existed and was correctly wired. But because the field carried no actual information, the sort did nothing at all. We had an authority ranking that ranked nothing, and it looked completely healthy from the outside.
The fix is populating the thing you built. Governance that carries no data is decoration — and it is worse than no governance, because it produces the feeling of safety without the fact of it.
The most counter-intuitive one. Models have a limited window of information they can consider, and it's tempting to fill it — surely more context can only help.
It doesn't. Published research (Liu et al., "Lost in the Middle", TACL 2024) found that models often did best when the relevant information sat at the start or end of a long context, and significantly worse when it sat in the middle — even models built for long contexts. Padding pushes the thing that mattered into the position least likely to be used.
I fixed a real problem — questions asking for a complete list were returning three items when the true answer was forty — by building an authoritative list and promoting it to the top of the results. It worked exactly as designed.
It also surfaced on questions that had nothing to do with lists. The list document was so large and dense that almost any keyword matched something inside it, so it ranked highly on questions like "how do I debug…". Those answers came back as walls of constants instead of explanations — a regression that's easy to miss, and it landed on exactly the questions newcomers ask first, which is why I held the rollout to non-technical colleagues.
The fix is fitting the strategy to the question. One global ranking rule cannot serve every kind of question. Work out what's being asked, then assemble context for that.
The one that isn't really a bug. It's an incident.
Retrieval is very good at finding relevant information, and it has no opinion about whether the person asking is allowed to see it. If your index contains material with different audiences — internal and external, restricted and general — then any question can pull anything, unless you designed against it.
The subtle part is that filtering after the fact isn't enough. If restricted content influences an answer and is then removed from the citations, the information still leaked — it's just untraceable now. The boundary has to be applied when you decide what's eligible to retrieve, not when you decide what to display.
The fix is treating audience as a hard filter, not a preference. Enforce it as a strict condition on the query itself rather than a scoring adjustment — a nudge in a ranking function is not an access control, however much it looks like one on a dashboard.
Why the taxonomy is worth having
Because the fixes don't transfer. If your real problem is Missing and you respond by tuning retrieval, you'll burn weeks and move nothing — the fact isn't there to be found. If your problem is Irrelevant and you respond by adding more sources, you'll make it worse. If it's Conflicting, no amount of prompt engineering resolves a disagreement your system has no rule for settling.
Most teams debugging an AI feature are working with one undifferentiated category called "it gave a bad answer." Five buckets is not a lot of taxonomy, and it's enough to stop you from applying the wrong fix.
Every one of these is a failure of ownership, not intelligence. Someone has to be responsible for what's in the context, whether it's current, which source wins, how much is too much, and who's allowed to see it. When nobody owns that, all five failures arrive on their own schedule.
That's the part I find genuinely hard, and it's the part that isn't a technology problem. Atlan makes a related point from a different direction. Its context-engineering framework has five phases, the last being governance and lifecycle, and it says: "Misaligned ownership at Phase 4 is the single most common reason context products go stale in production." Elsewhere it puts the rule more simply: "No owner means no update means stale context."
Which is what the next post is about: what it looks like to actually own the lifecycle of the information feeding your AI — versioned, gated, promoted deliberately, and reversible when you get it wrong.