What a Long-Running Agent Keeps and What It Throws Away
A task that takes an agent ninety minutes and sixty tool calls produces a history longer than any window. Something has to be discarded, and the naive answer, summarise the oldest part, throws away the part that explains why the agent is where it is.
Where It Breaks
Our document migration agent works through a batch: read a file, check a rule, transform, verify, move on. On a large batch it makes sixty or more tool calls, and around call forty the accumulated history exceeds what we are willing to send.
The first version summarised the oldest third whenever the history grew too long. It worked until it did not: the agent began retrying transformations it had already tried and abandoned, because the record of having tried them was in the part that had been compressed away.
Three Kinds of History, One Compression
A trajectory contains observations, which are what tools returned; decisions, which are what the agent chose and why; and errors, which are what failed. We had been treating all three as text of equal value, which is what a uniform summariser does.
They are not equal. An observation is usually recoverable, because the tool can be called again. A decision is not recoverable, and neither is a failed attempt, and losing either causes the specific failure of an agent going in circles.
The Research on Choosing What to Compress
Kang and colleagues published ACON in 2025, work on optimising context compression for long-horizon agents, treating what to compress as a decision to be made deliberately rather than as a uniform operation applied to whatever is oldest.
That framing matched what our incident had taught us the expensive way. The question is not how much to compress but which parts, and the answer depends on whether the content can be regenerated by calling something again.
| History element | What we do |
|---|---|
| Tool observations | Compress aggressively. Recallable |
| Decisions and their reasons | Keep verbatim. Not recoverable |
| Failed attempts and errors | Keep verbatim. Prevents loops |
| The original task statement | Keep verbatim. Always first |
The Rule We Landed On
Observations compress, decisions and errors stay. In practice the agent writes a short structured note when it decides something and when something fails, and those notes are never summarised. Tool outputs are summarised down to what the decision referred to.
Repeated work fell to almost nothing and the history stayed within budget on batches twice the size we could previously handle. The cost is a small amount of structure the agent has to maintain, which is a prompt instruction and a schema rather than an architecture.
Keeping the Task Statement First
A detail that mattered more than it should. The original instruction was at the start of the history, which meant it was in the oldest third and got compressed along with everything else, and an agent forty calls in was working from a summary of its own brief.
It is now pinned outside the compressible region. That single change fixed a class of drift we had been attributing to the model, which is a useful reminder that a system-level explanation should be exhausted before a model-level one.
Where We Cap Instead of Compressing
Some tasks should not run for ninety minutes. We cap the number of tool calls, and beyond the cap the agent produces a partial result with what it has done and what remains, which a person picks up.
That cap is more valuable than the compression. An agent that has made sixty calls without finishing is usually not close to finishing, and the compression work made long runs survivable rather than productive, which is a distinction worth being honest about.
What We Log
The uncompressed trajectory, separately, always. The agent works from a compressed view and our traces keep everything, because a failure that only manifests after fifty calls is impossible to diagnose from the compressed history the agent saw.
Storage is cheap and these trajectories are large, so we keep them for thirty days rather than indefinitely. Every diagnosis we have needed has been within a week of the run.
What We Do Not Claim
We do not claim our three categories are the right decomposition in general. They are the ones that mattered for a task with tools that can be re-called cheaply, and an agent whose observations are expensive or irreproducible would need a different rule.
We also do not claim compression is preferable to a bigger window. Where the whole trajectory fits, we send the whole trajectory, and the compression exists because some tasks exceed any window we can afford rather than because selective memory is a virtue.