What Is "Context" in an AI Agent — and Why Does It Run Out?

Context is everything the model can see on the current turn — nothing more. It has no memory beyond what's placed in front of it right now: not what it "knows" from training, not what happened three sessions ago unless something wrote that history back into the current window, and not what a sibling process is doing elsewhere in the system. This is a deceptively simple definition, and the entire discipline of agent design is, in large part, the discipline of managing what does and doesn't make it into that window.

What actually fills the window

On any given turn, an agent's context is typically assembled from four kinds of material: system or project-level instructions that set standing behavior, the schemas of every tool and MCP server the agent has access to (whether or not any of them get called that turn), the conversation history accumulated so far, and any content retrieved or injected specifically for this step. All four compete for the same finite space and are visible to the model at once — efficient for continuity, but it comes with a real cost.

That cost sets up a problem we cover in depth elsewhere in this series: two different jobs placed in the same shared context can see each other's work. A reviewer that shares the same context as the work it's reviewing inherits that work's blind spots, because it's looking at the same evidence through the same lens — sometimes called the "blind review" problem, and the direct motivation for context isolation.

Why the window has limits — and why size alone doesn't fix them

Modern models offer very large context windows — well over 200,000 tokens in many cases — and it's tempting to treat that capacity as effectively unlimited. It isn't, for two separate reasons. The first is mechanical: every token of context has to be paid for and processed on every turn, so a bloated context is slower and more expensive regardless of whether the model reasons well over it.

The second reason is more subtle and more important: attention dilution, sometimes called the "lost in the middle" effect. This is a measured phenomenon, not a hand-wavy concern — information placed in the middle of a long context is recalled less reliably than information placed near the start or end, regardless of how much unused room is left in the window. A fact buried in the middle of a long document dump is genuinely less likely to influence the model's answer than the same fact placed at the very beginning or end.

What this motivates

Once this limitation is taken seriously, three mitigations follow naturally, and each reappears throughout the rest of this series in different guises: giving a subagent its own clean, bounded context rather than stuffing everything into one shared window; running multiple, narrower passes over a problem instead of one enormous one; and retrieving only the specific, targeted content a step actually needs, rather than expanding the raw size of the context and hoping the model finds the needle. None of these techniques make the context window bigger. All of them make better use of the window that already exists — which, once attention dilution is understood, turns out to matter more than raw capacity in most practical situations.