A context window is the maximum amount of context a language model can process in a single invocation, measured in tokens and subject to the model’s input and output limits. An agent that accumulates more context than the model can accommodate must select, summarize or store material outside the active window.
Anthropic’s documentation describes the context window as all the text a model can reference when generating a response, including the response itself, a kind of working memory for the model. For a chatbot, that is mostly the conversation. For an agent, it is everything the agent can act on right now: its instructions, the tool definitions, the task so far, and every tool result it has collected. What is not in the window, the agent cannot use.
Why agents fill it
An agent’s context grows with every step. Each tool call adds the call and its result, and tool results are often large: file contents, search results, API responses, test output. Instructions and tool definitions are sent again with every request. A long-running agent can fill even a large window, and every request it makes carries the accumulated context with it, which is why the window is also a cost question (see context cost).
Window sizes vary by model and change often. As of October 2026, Anthropic documents windows of up to one million tokens for some current models and smaller windows for others. Sizes are best read from the provider’s current model documentation rather than from articles, including this one.
Bigger is not the same as better
A larger window holds more, but models do not use all of it equally well. Researchers found that models often perform best when relevant information sits at the beginning or end of the input, and worse when it is in the middle. Chroma’s 2025 study of 18 models found that performance consistently degrades as input length grows, a pattern now widely called context rot. Anthropic’s documentation describes the same effect: as token count grows, accuracy and recall degrade.
So an agent that keeps everything is not necessarily better informed than one that keeps the right things.
When the window fills
There are four broad responses, often combined:
- Truncation. Drop the oldest material. Simple, and it silently removes whatever was first, which is often the instructions.
- Compaction. Summarize older material and continue from the summary. Anthropic offers server-side compaction for some models, and many agent frameworks do it in the application.
- Context editing. Remove specific material, such as old tool results that are no longer needed.
- Offloading to memory. Store material outside the window and retrieve it when needed.
If nothing is done, the request fails: Anthropic’s API, for example, rejects input that exceeds the window outright.
What must survive compaction
Every one of those responses decides what the agent forgets, and most designs treat all context as equally compressible. It is not. Three kinds of context need different handling:
| Kind of context | Example | How to handle it |
|---|---|---|
| Working material | Tool results, intermediate reasoning, the conversation so far | Can be summarized or dropped |
| The mission | The objective, permissions and prohibitions | Rebuilt on every request, never summarized |
| Execution evidence | What the agent actually did | Recorded outside the window, independently of both |
The mission is the dangerous case. If an agent’s limits arrive only as its first message, a summary can drop them, and the agent continues without them: a quiet route to agent drift. Compaction also has a budget of its own: what cannot be compressed, such as instructions and tool definitions, plus the most recent exchange, plus anything pinned to survive, sets a floor on how small a request can get. In our own experiment, a compaction triggered too early made the next request larger, not smaller.
An example
This example comes from a recorded experiment, described in full in The Price of Remembering.
An agent investigating a customer case was told, in its first message, not to modify records, delete anything or contact the customer. When its input reached the compaction trigger, the application summarized the older turns. The words “modify”, “delete” and “contact” were absent from the next request. Six requests later, the agent called its contact tool and sent the customer a courteous summary of its findings. The contact was simulated and no customer existed.
We did not establish that compaction caused the call: the observation came from two runs, and other runs lost the same words without acting on it. What the sequence shows is the mechanism: a limit can leave the window, and nothing inside the window records that it left. The same experiment kept the limits present in every compaction by rebuilding them on each request.
How Sentience Governor relates
Sentience Governor keeps an agent’s declared intent and scope in its execution record, outside the agent’s context window, so a compaction cannot remove them from the reference the agent’s actions are evaluated against. In the experiment above, the contact call still stood out against the declared scope after the agent’s own copy of its limits had gone. Where an integration records context snapshots, Governor keeps how large the context was at each step, but not what a compaction removed.
Often confused with
Agent memory. The window is what the model sees on one call. Memory is what is stored outside it and can be brought back.
Context length or token limit. Often used interchangeably with context window. Some providers also limit output length separately, and output counts against the window.
Where the concept stops
A context window defines how much a model can consider at once. It does not determine which material the model actually uses well, it does not decide what should be kept when it fills, and it keeps no record of what was removed. Those are design decisions, and for agents they decide whether the mission survives the task.