Long agent runs rarely fail at a tool call. They fail at a compaction boundary, and almost nobody instruments it.
The failure
When the context window fills, something has to decide what to throw away. Every agent harness does this. Most do it by summarising.
If the goal statement is not preserved verbatim through that step, it gets summarised into vagueness. The model then reads back its own compacted notes, no longer knows precisely what it was doing, and quietly restarts the plan - frequently re-deriving work it already finished.
From outside this looks like "the model forgot my instructions." But they were not buried in the middle of a long context, which is the failure everyone knows about. They were compressed out.
Nothing errors. So it does not surface as a failure. It surfaces as a run that took three times as long and ended somewhere adjacent to what you asked for.
Why it is hard to see
Teams log tool calls, messages and decisions. Almost nobody logs the compaction event: the moment the window filled and something chose what to discard.
When you read the trace afterwards, every individual action looks locally reasonable. The agent made a series of defensible decisions. Nothing threw. You can explain every action and still not explain the run - which is precisely the thing traceability was supposed to buy you.
Three things that helped
Pin the goal verbatim. Not summarised, not paraphrased, not "the user wants X". The literal original text of the goal and the acceptance criteria, re-injected after every compaction. Single highest-leverage change I made.
Log the compaction event with what was dropped and what was kept. Then you can correlate a bad run with the exact point it lost the thread. Cheap to add, and it turns an unexplainable failure into an obvious one.
Denominate retry budgets in remaining context, not in attempts. Every failed retry consumes context, which pulls the next compaction forward. Two retries on a task that began at 60% context is a completely different risk from two retries on one that began at 5%. A loop that retries across a compaction boundary works from a worse specification each time - attempt 3 is dumber than attempt 1, which is the opposite of what a retry is for.
Multi-agent makes this worse, not better
The usual pitch for multi-agent is that decomposition solves context pressure: each agent holds less, so nobody fills their window. In my experience it relocates the problem rather than removing it, for two reasons.
Every handoff is a lossy compaction with extra steps. When agent A summarises its state for agent B, that is the same operation as a compaction - something decides what survives - except it now crosses an agent boundary, so B has no access to what A dropped and no way to know it is missing. A compaction at least leaves the raw history recoverable in principle. A handoff usually does not.
The boundaries do not line up. An agent's context can fill mid-subtask. So it compacts, loses fidelity on its own assignment, and then hands off a summary of a plan it had already partially forgotten. The orchestrator sees a completed handoff and a plausible summary. Nothing looks wrong at the supervision layer.
The net effect is that the group can be confidently, collectively wrong in a way a single agent with a full trace usually is not - because every participant's view is locally coherent.
If you take one thing
Compaction quality beats orchestration. Before adding another agent to the graph, check whether your existing one survives its own context boundary with the goal intact. Most do not, and that is a cheaper thing to fix.
Founder disclosure: I build Grunz, a coding agent on open-weight models, which is where all of this came from. Open models make it sharper because most hosted endpoints serve around 32K regardless of the advertised window, so compaction fires every few minutes instead of every few hours.
Top comments (0)