Context bloat: why long-running agents break

A coding agent runs clean for the first dozen tool calls. It reads files, runs searches, edits code, and checks output. Then somewhere past the thirtieth call it starts slipping: re-running a search it already ran, editing a file it already fixed, asking for a path it established twenty steps ago. The model is the same one that handled the early calls cleanly, and the window still has room to spare. What changed is that the window filled with the agent’s own tool-call output, and that output now competes with the task for the model’s attention.

This is context bloat: the accumulation of low-signal tool-call results that crowd out the instructions, plans, and state an agent actually needs. It is one of the most common reasons long-running agents degrade, and one of the least instrumented, and it is a context engineering problem rather than a model one. Bigger models and bigger windows delay it without preventing it.

What context bloat is

Context bloat is the buildup of accumulated tool-call output that fills an agent’s context window with content the model no longer needs. Every thought-action-observation cycle appends to the window: the tool call, its full result, and the reasoning around it. Unlike a chat, where each turn is roughly the size of a human message, an agent turn can append thousands of tokens of raw tool output: an entire file, a directory listing, a stack trace, or a result set. Most of that output mattered for exactly one step and is dead weight for the rest of the run. It does not get removed on its own. It sits in the window, and the model reads past it on every subsequent turn.

Tool calls, not window size, predict when an agent degrades

The volume of accumulated tool output predicts agent performance better than model choice does. In Anthropic’s analysis of its multi-agent research system, token usage alone explained 80% of the performance variance on the BrowseComp evaluation, with the number of tool calls and the model choice accounting for the rest. What mattered most was how many tokens a run had spent, not which model ran or how cleverly it called its tools, and token spend is mostly a function of how much tool output has piled up. Agents already consume roughly four times the tokens of a chat interaction, and multi-agent systems around fifteen times, so the window fills quickly. When the variable that explains most of your performance is token volume, the content driving that volume, raw tool results, is where the problem lives.

What raw tool output does to the attention budget

Raw tool output is the highest-volume, lowest-density content in an agent’s window, and that combination is what dilutes attention. Transformer attention spreads across every token in context, so adding 5,000 tokens of a file the agent read four steps ago measurably weakens its grip on the 50-token instruction that still matters. Stanford’s lost-in-the-middle research shows models attend most strongly to the start and end of the window and weakest to the middle, which is exactly where stale tool output piles up. The ACON study of long-horizon agents names the result “context distraction” and shows that compressing accumulated observations and action history cuts peak token usage by 26 to 54% while improving task performance by up to 46%. The capability was there the whole time; the accumulated history was burying it.

The symptom is measurable. A January 2026 study of graph-guided agent investigations found that GPT-OSS-120B fell into degenerate tool-repetition loops about 12% of the time, re-invoking the same calls and “consuming context budget without advancing the investigation.” Repetition compounds with trajectory length, so the deeper a run goes, the less room is left for novel work and the more likely the agent is to spin.

Why bigger context windows make it worse

A bigger context window does not solve context bloat and often makes it worse. A model’s effective context, the length over which it stays reliable, is far shorter than its advertised window: Chroma’s context rot research across 18 models shows accuracy falling from around 95% on short inputs to 60 to 70% on long ones, on identical tasks. A larger window does not flatten that curve, it just delays the point at which you notice the agent has crossed it. More headroom also removes the forcing function that would have made you manage tool output early, so the agent accumulates more debris before anything breaks, and when it does break, it breaks with a fuller and noisier window. The window size sets the ceiling. It does not set the point where context rot begins, which is much lower.

The fix is at the tool-output layer, not the conversation

The highest-leverage fix targets tool output specifically, not the conversation as a whole. Anthropic’s guidance on context compaction calls clearing old tool results the lowest-hanging fruit: once a tool has been called deep in the history, the agent rarely needs to see its raw result again, only the conclusion it drew from it. Four interventions, in rough order of effort, do most of the work.

Summarizing tool output before it re-enters the window is the cheapest move and the one most frameworks skip. One-job-per-tool design helps here, because a narrow tool returns a narrow result that is easier to compress without losing the part that mattered. Clearing stale results goes further: once the agent has extracted a conclusion from a file read, the raw file can leave the window. Context offloading generalizes this by moving results out of the prompt entirely, into a store the agent queries on demand, which is the only option that keeps a 40 KB payload from ever touching the window. Sub-agent isolation is the heaviest lever and the cleanest: each sub-task runs in its own window and returns only its result, so no single window carries the whole run’s debris.

An agent connected to a Wire container does this offloading explicitly: it writes a large tool result with wire_write and on the next turn pulls back only the slice it needs with wire_search, so the raw payload lives in the container instead of the window and never re-enters the attention budget. (How Wire keeps long runs under the context limit)

How to measure context bloat before it breaks your agent

You can catch context bloat early by instrumenting three signals, and most teams instrument none of them. Track tokens added per step: a healthy run adds roughly constant tokens per step, while a bloating run shows tool output growing faster than progress does. Track the tool-repetition rate: the same call with the same arguments appearing twice is the earliest sign the agent has lost track of what it already did. Track signal density: classify each block in the window as instruction, fresh tool result, or stale tool result, and watch the stale fraction climb. When stale output dominates the window, the agent is operating on debris, and re-running it on a bigger model will not help.

This is the same root cause behind agent drift, viewed through one specific lens: of everything that accumulates in a long-running window, tool-call output is the largest and the easiest to remove. Manage it deliberately, starting with the raw results the agent no longer needs, and most of the late-run degradation that gets blamed on the model simply stops happening.

Sources: Anthropic: How we built our multi-agent research system · ACON: Optimizing Context Compression for Long-horizon LLM Agents · Think Locally, Explain Globally (arXiv 2601.17915) · Chroma context rot research · Lost in the middle (Liu et al.) · Anthropic: Effective context engineering for AI agents