Give agents useful context, not the whole backlog.
Across 104 AgentBench tasks with real earlier work in the history, Tileward Context solved 37 while sending 523,028 context tokens. Full histories solved 24 while sending 1,651,372. The 3.2× context reduction is stable; the 13-task gap is not. Identical runs can flip 14–19 task outcomes, so this report stands behind the repeated ordering rather than a fixed accuracy margin.
Read this alongside R-006. Long conversations produced the other result: far less context, but a lower answer rate than the full transcript.
See the matching eval card for the result and limits in one screen.
37 tasks solved on 3.2× less context.
Each task starts with about 4,100 tokens of genuine earlier work already in the agent’s history. This is the state a working agent is actually in, not a clean slate. Every approach below sees the identical history. The only thing that differs is what that history is turned into before it is sent.
| What the agent was given | Solved | Context sent | Less than everything |
|---|---|---|---|
| Tileward Context | 37 of 104 | 523,028 | 3.2× less |
| The newest turns that fit the same budget | 32 of 104 | 596,087 | 2.8× less |
| Nothing (history deleted) | 29 of 104 | 279,503 | 5.9× less |
| Everything, as-is | 24 of 104 | 1,651,372 | Baseline |
| The benchmark’s own trimming | 0 of 104 | 565,140 | 2.9× less |
The context figure is the solid one. It depends on how the history is put together, not on how the model happens to sample, so it does not move between runs: 3.2× less context for the same work.
Four controls test the obvious alternative explanations.
We reran the same setup, matched the context budget with newest turns, deleted history entirely, and checked the product path against a local copy. Together those controls show what survives and what does not.
| Control | What it rules out | What happened |
|---|---|---|
| The same setup, run twice | that the difference is run-to-run luck | a 14–19 task wobble; our margin sits above it |
| Newest-first, same budget | that we just sent fewer tokens | five tasks behind, on more context |
| Delete the history entirely | that the history was never needed | eight tasks behind |
| Measure against production | that a local copy flattered us | it did; production is the number above |
The ordering repeated; the 13-task gap is not pinned.
Tileward Context ranked ahead of full history in two production runs, and the 3.2× context ratio does not depend on sampling. The size of the accuracy gap is not pinned: it tests at p = 0.011 on this run and p = 0.078 on a near-identical run hours earlier, three tasks apart. We report the ordering, not a stable 13-task advantage.
Deleting the carried history entirely still beat sending all of it, which means part of what compression buys here is removing distraction rather than remembering anything.
One model, one model family. 104 tasks is enough to see this ordering and not enough to pin the size of the accuracy gap. A second environment is excluded from this page entirely, because the model could not do those tasks at all and a control stuck at zero cannot distinguish anything.
The benchmark’s own trimming removes the task.
The zero in the first table is not one approach failing. It reproduced three times and it is the only statistically unambiguous effect in the study.
AgentBench trims long histories by keeping the first message plus a recent window, on the assumption that the instruction lives in the first message. In its operating-system tasks the first message is the protocol and a worked example, and the actual task statement sits several messages later. Once a history grows past the trimming threshold, the task statement lands in the discarded region: the agent keeps the rules and loses the job, and the run completes normally with plausible-looking low scores.
Anyone running long-horizon agent work through that default path is affected. It is invisible from the outside, and it penalises exactly the long-history conditions that compression work cares about.
Re-run this comparison on the history your agents carry.
If you are evaluating context compression yourself, the four checks above cost almost nothing and they will change what you conclude, particularly running the same setup twice before believing any accuracy difference.
Or bring us an agent workload with real accumulated history and we will measure it the same way, including the cases where we come off worse. Talk to an engineer, or read how Tileward Context works.