Pruning context made agents more accurate, not just cheaper

Most advice about shrinking an agent’s context window assumes a tradeoff: give up some accuracy, save some money, pick your ratio. A June 2026 paper on long-horizon tool-using agents found no tradeoff to make. The configuration that kept everything was the worst one available, on accuracy and on cost.

If carrying the full history made the agent both slower and wrong more often, nobody was paying a premium for it. They were paying for a defect. The better finding is buried in how they clawed the difference back. What took the agent from 79% to 91.6% had nothing to do with compressing what its tools returned. It was a running record of what the agent itself had done, which points at a different account of why long tasks degrade.

Keeping the full history was the worst option on every axis

Agents that retained their complete tool-call history completed 71.0% of tasks while burning 1,480,996 tokens and 14.56 hours, and both pruning configurations beat it outright. The benchmark, from Less Context, Better Agents by Lodha, Varnosfaderani, Chakraborty, and Mithal, covers automated expense itemization in Microsoft Dynamics 365: 50 hotel expense tasks, five GPT-5 configurations plus Claude Sonnet 4.5 for cross-model validation, averaged over five independent runs.

Complete itemization is the share of tasks where the remaining amount reached exactly $0.00, which is the business bar, since any nonzero residual blocks the report from being finalized. Amount itemized is the average share of each receipt correctly allocated. Neither came from the agent’s own report. The authors read the saved form state back out of Dynamics 365 and checked it against ground truth.

That second column is the uncomfortable one. The agent carrying complete history misallocated roughly 8% of the money it was supposed to itemize.

Dropping everything except the five most recent tool call and response pairs then improved completion by 8 points while cutting tokens 64% and runtime 63%, with nothing added to compensate. The agent stopped carrying material it was not using and got better at its job.

The mechanism is the same one that makes context compression work at all: attention is finite and spreads across whatever sits in the window, so every stale record competes with the one the agent needs now. Cost compounds on a separate track. You do not pay for accumulated history once. It gets resent every turn, so a long task buys its early tool responses over and over. The 14.56 hours against 5.39 is that compounding showing up as wall-clock time.

Pruning saves the tokens, summarizing saves the task

Pruning captured 64% of the token reduction. Summarization on top delivered another 12.6 points of completion for roughly 3% more tokens. That split separates two effects that usually get discussed as one.

Pruning is what makes the run cheap. Once the old tool responses are gone the window stops growing and per-turn cost flattens. But it evicts by recency rather than relevance, so state the agent established early and needs late goes out with everything else. That is the gap between 79.0% and 91.6%. Roughly one task in eight failed because the agent had discarded something it turned out to need.

The summary closes that gap for almost no extra tokens, so the missing piece was small. What it contains is worth quoting. The summarizer is a single free-form pass, firing only when pruning actually evicts something, and it records “forms opened, controls interacted with, buttons clicked, and data entered.” That is a log of the agent’s own actions, with the tool responses themselves nowhere in it.

So those 12.6 points bought back position rather than content: which step the agent was on, and what it had already committed. That makes the lesson harder to apply than “keep less.” Discarding the material while keeping the trail means deciding what counts as position, which is a different judgment from deciding what counts as important.

Or let the agent ask where it is

Storing the trail is one solution, and the paper is forced into it by what its agent does. Filling a form in an enterprise system is a sequence of committed actions, and there is no way to ask the system what you were in the middle of. The trail has to be carried because it cannot be recovered.

Retrieval works differently. An agent moving through a body of material can ask where it is: what sits next to this passage, and what it belongs to. When the tool surface answers, the agent need not carry its position, because it can ask again. When the surface cannot answer, every follow-up becomes a fresh search that throws away where the agent had got to. That is the expensive path, and it is also the one that loses the thread.

These two families get conflated constantly. Pruning and summarization are reduction in place: the material leaves the window and is not stored anywhere. Context offloading moves it somewhere the agent can query later. Both keep the window small. They differ entirely in what happens when the agent needs something it dropped.

Left on their own, agents handle this badly. ContextBench ran 1,136 issue-resolution tasks across 66 repositories and eight languages and found substantial gaps between the context agents explored and the context they used, with a consistent preference for breadth over precision. An agent that cannot navigate compensates by grabbing everything. That is where the accumulation came from in the first place.

What navigation did to our own numbers

Adding a traversal tool to a retrieval surface reduced total tool calls from 199 to 152 and raised correctness at the same time. We ran this on Wire containers across 64 questions with data and model held fixed, comparing two overloaded retrieval tools against three single-purpose ones with typed provenance on every result.

Adding a tool made the agent do less work. That is not the usual direction. The new tool let it land on a relevant passage once and move from there, pulling adjacent passages, the full source, or related entries, instead of issuing a fresh search for every follow-up. Each fresh search had been an act of forgetting.

The strategy it settled on is the more interesting part. Roughly 77% of exploration calls used keyword mode instead of semantic search, and nobody instructed that. The agent read the tool descriptions and worked out that for lookup-shaped questions, keyword matching over classified entities beat a full semantic pass on cost and on precision, then applied that per question. The full methodology and per-question breakdown is published separately.

Across both experiments the shared mechanism is clearer than the shared token savings. Their agent improved when it stopped losing track of what it had done. Ours improved when it stopped having to rediscover where it was.

The obvious reading of that overshoots, though. The expense agent was committing actions into a business system, not reading from a corpus, and there is nothing to navigate back to in a submitted form. Traversal does not substitute for the paper’s summarizer there. The claim is narrower: where an agent moves through material rather than through committed steps, position can be recovered instead of carried.

What neither experiment tested

Neither setup measured what happens when an agent needs a detail that reduction already discarded. The paper’s summary is the sole record of everything pruned, so a fact it failed to carry is unrecoverable, and the residual margin in both accuracy columns suggests this happened. The untested fourth configuration is reduction with a recoverable destination, where the summary carries pointers into material the agent can still retrieve instead of standing in for it. That is the argument that context engineering lives in the substrate rather than the harness, and as far as I can find nobody has benchmarked it against plain summarization on a long-horizon task.

Fifty tasks in one enterprise workflow is narrow, and the paper does not claim otherwise. The five-call pruning window and three-interaction summary window were swept independently and chosen at the knee of both curves, so those numbers were measured, not guessed. They were measured on this workload, though, and the knee sits elsewhere for a different tool mix. Our own benchmark is 64 questions against one container, a retrieval-shaped task that says nothing about long-horizon transactional work.

What to change first

If your agent carries full conversation history through long tool-using tasks, that is now the configuration with the weakest published evidence behind it. Prune first, since it is simple and captures most of the cost reduction, then add a running summary if tasks depend on state established early and referenced late. Make that summary a record of what the agent did, not a digest of what its tools returned.

Before tuning any of it, though, look at what your tools let the agent do, not just what they return. An agent that can search but never move has to rediscover where it is on every call, and it compensates by grabbing more than it needs.

Then ask the question neither benchmark answers. When your reduction step drops something the agent later needs, can it get the detail back, or is the summary the only copy that ever existed?

Sources: Less Context, Better Agents · ContextBench: A Benchmark for Context Retrieval in Coding Agents · Agentic Context Engineering · Wire: More tools, fewer calls, restructuring agentic retrieval