Why Giving AI More Context Can Make the Answer Worse
You gave the tool everything. The full dataset, last year's numbers for comparison, the vendor's report, three sets of notes from people who had opinions about the project, and the original brief somewhere near the bottom of the pile. You did this because it felt responsible. More information seemed safer than less. And the answer that came back was competent, professional-sounding, and somehow not what you needed at all.
It addressed the general topic. It just missed the point.
If you have run into this more than once, the instinct is usually to blame the tool. It didn't understand the assignment, you think, or it needs a cleverer prompt next time. But the more common explanation is less flattering to the person doing the briefing. You gave the tool too much, and it did exactly what you asked: it tried to honour everything you handed it, all at once, with no signal about which parts actually mattered.
Context is not neutral filler. Every piece of background material you include tells the tool what to weigh and what to prioritise. When that direction is precise, the output sharpens. When it is vague, cluttered, or simply too abundant, the output softens in ways that are hard to trace back to a single cause. The reader looks at a flat, unfocused result and assumes the model lacks judgement, when in reality the model responded faithfully to an input that pointed in several directions at once.
This is a different problem from the one covered in briefing an AI task clearly. Task clarity is about what you're asking for. Context is about what you're providing alongside that ask. A well-defined task can still produce a weak result if the material surrounding it is bloated or irrelevant, and a slightly loose task can sometimes produce a strong one if the context is well chosen, because good background material narrows the range of plausible answers even when the instruction itself leaves room to move.
More is not the same as thorough
The instinct to include everything feels responsible. It feels like the opposite of cutting corners. But thoroughness in context selection has almost nothing to do with volume, and treating it as a matter of quantity is where the trouble starts.
Picture a human resources manager preparing an engagement survey summary for the executive committee. She has the full dataset, the vendor's analysis report, two years of internal benchmarking, a folder of manager comments, and notes from a focus group. Hand all of that to an AI tool as context and ask it to write the summary, and the output will try to do what you implicitly asked: address the statistical trends, the qualitative themes, the year-over-year movement, the departmental variation and the individual comments, all in one document. The result will be long, generically thorough, and hard for a committee with fifteen minutes to act on.
The alternative is not to trim for its own sake. It's to decide first what the committee actually needs to understand: the biggest shifts from last year, where engagement dropped below the company's internal threshold, and any qualitative themes suggesting emerging risk. Once that's settled, the selection makes itself. The benchmarking data is essential. The vendor's report is useful for the threshold comparison. The focus group notes speak to the qualitative theme. The raw dataset is redundant, since the vendor's report already does that work. The manager comments might add colour, but they also risk pulling the output into granular, department-specific territory the committee doesn't need at this stage. Include the first three. Leave the rest out. What comes back is shorter, sharper, and considerably more useful, not despite the missing material but because of it.
That is the shift worth making: stop treating context as a matter of thoroughness and start treating it as a matter of precision. A well-chosen context is one where every included piece serves the task, and nothing included pulls the output somewhere the task doesn't need to go.
There's a simple way to test this before you hand anything to the tool. Ask three questions. First, what is the output actually for, and who is it for? That settles relevance, and it's worth noticing that a briefing written for an executive requires a genuinely different context than a working document meant for the team doing the work. Second, what would a capable colleague need if you handed them this exact task? That settles sufficiency. If a colleague would need the project timeline to write a status update, so does the tool. If they wouldn't need the full history of the project to write one paragraph, neither does the tool. Third, and this is the question almost everyone skips, what would pull the output away from what it's actually for if you included it? That settles exclusion, and it's the hardest of the three, because leaving something out feels like risk. It feels like the thing you didn't include might turn out to be the thing that mattered. The cost of including it anyway, though, is a diluted, generic result that ends up needing more revision than a tightly scoped one would have needed in the first place.
An operations manager at a logistics company ran into a version of this during a quarterly review. Asked to draft commentary on cost variances, an analyst on her team handed the tool the raw numbers and little else. No context about what had actually caused the overruns. No note on which ones were expected. No mention of a client mix shift that had changed the revenue picture that quarter. The output was accurate about the figures and wrong about the story behind them, attributing a shortfall to seasonal patterns when the real cause was a delayed contract signing the business unit already knew about. The correction itself was minor. The credibility cost wasn't. For two quarters afterwards, the unit head asked to see source assumptions alongside every commentary draft the analyst produced, adding hours to a process that a handful of extra sentences about the actual drivers would have avoided.
That example matters as much as the crowded-desk ones, because it points at the other half of this. The goal was never minimalism. Too little context is exactly as capable of producing a weak result as too much, just through the opposite mechanism: instead of competing signals, you get invented ones. A tool with insufficient grounding doesn't pause and ask for more. It fills the gap plausibly, and plausible is not the same as true.
Context also has to keep up with the task
There's a version of overload that builds gradually rather than arriving all at once. A project manager working on an internal proposal began with a clean set of context: objectives, budget constraints, two departments' requirements. The first draft came back well-aligned. Then a third department asked to be included, and she added their email to the context for the next round without adjusting anything else. The second draft tried to honour all three departments equally, and the original framing blurred. She added notes from a call with her director suggesting a phased approach, and the third draft tried to reconcile the phased approach with the expanded scope and the original budget in one document, reading like something a committee had written by consensus. Every addition, taken on its own, was reasonable. Stacked together, they created a context in which no single priority was clear, and the output reflected that faithfully. Rebuilt from scratch, keeping only the current requirements, the phased approach and the updated budget, the fourth draft came back focused on the first pass.
None of this means every task now needs a context audit. Plenty of work is simple enough that a reasonable amount of background material performs fine without anyone curating it line by line. The principle earns its keep when the stakes are higher, when a specific audience is waiting on the result, or when you've already noticed that what comes back reads as generic. In those situations, cutting context down to what the task actually requires is usually the fastest fix available, faster than a cleverer prompt and faster than another round of edits.
Context is not storage. Handing a tool everything you happen to have is not the same as briefing it well, and the difference isn't effort, it's judgement about what the task in front of you actually needs to see.
Anthony Velland
Interested in going further?
The three-question framework behind this article sits alongside the fuller method for structuring reliable AI work set out in AI Without Guesswork.
Ad · Amazon affiliate link.
