What an Agent Forgets When Its Context Gets Compacted

Share
What an Agent Forgets When Its Context Gets Compacted. Abstract deep dive illustration in orange and dark grey on debugly.dev

The session transcript showed the degradation clearly in hindsight. For the first hour the agent was sharp: it remembered which hypotheses it had killed, which files it had read, which approach it had abandoned and why. Then, somewhere past the context limit, it began to loop, re reading a file it had already summarised, re proposing a fix it had already tested and rejected, asking for a credential it had already been given. Nothing had gone wrong in any single step. The session had simply exceeded its working memory, and the compaction that kept it running was lossy.

This is the mechanics of what an agent forgets when its context is compressed, and why long sessions degrade in ways that look like stupidity but are actually information loss with a specific structure.

This was a coding agent on a long investigation, and the pattern matches every long session I have since examined, including the drift documented in why your coding agent gets worse the longer the session runs.

The context window is working memory, not storage

The model attends to what is in the context. Everything the agent has learned this session, the dead ends, the file contents, the decisions, lives only in that window. There is no separate durable state unless the architecture writes one. So the context is working memory in the strict psychological sense: fast, limited, and the only place reasoning can look.

When the window fills, the system must make room, and the common mechanism is compaction: older turns are summarised and the raw detail is dropped. The summary is smaller than the detail by design, which means information is discarded, and the discard is not curated by the task. It is a compression, and compression keeps the statistically salient and drops the statistically quiet, which is precisely backwards for debugging, where the quiet detail is usually the bug.

What survives compression and what dies

The structure of the loss is not random, and naming it explains the observed failures.

What survives: the gist. The overall goal, the main entities, the broad conclusion of each phase. The summary keeps "we are fixing the cache bug" and "the database looked fine".

What dies: the negative knowledge. The hypotheses that were tested and rejected, with the reason. Summaries keep conclusions and drop the refutations, because a refutation reads like noise next to its conclusion. But the refutations are the agent's immunity to repeating itself, and losing them is exactly why the agent re proposes the rejected fix.

What dies: the exact values. File paths, line numbers, token strings, the specific constant that was wrong. Summaries keep "a config value" where the session had max_connections = 100, and the loss of the concrete turns a precise investigator into a vague one.

What dies: the ordering and the causality. Which observation came before which decision, and why. Compression flattens the narrative, and without the order the agent cannot tell what it already knows versus what it inferred later, so it re derives things it had already derived.

Why the degradation looks like looping

The loop is the agent re acquiring knowledge it already had, because the knowledge is no longer in the window. Re reading the file is cheap for the agent and invisible to it, so the transcript shows the same file read three times. Re proposing the rejected fix happens because the rejection is exactly the negative knowledge that compression dropped. The agent is not failing to reason. It is reasoning correctly over an amnesiac's notes.

This is also why the degradation is gradual and then sudden. While the raw recent turns still hold the detail, the agent seems fine. Once the relevant detail ages past the compaction horizon, it vanishes in one step, and the behaviour changes in one step, which reads as "it got dumb at hour two", when really the memory horizon crossed the relevant fact.

The fixes that work

Write state outside the window. The durable facts, the killed hypotheses with reasons, the files read, the decisions, belong in an external scratchpad the agent appends to and re reads, a todo list and a findings file, so the working memory is backed by storage. The agent that maintains a findings file degrades far slower, because the file does not compact.

Make negative knowledge explicit and durable. The scratchpad should record rejected approaches with the disconfirming evidence, because that is the first thing compression eats and the most valuable thing to keep. This is the falsification habit from every bug is a wrong assumption, externalised.

Restart with a brief instead of running forever. A fresh session handed a well written brief of the findings is sharper than an old session holding a compressed memory, because the brief is curated and the compaction is not. Long investigations should be a relay of short sessions with written handoffs, not one marathon.

Budget the context like a resource. Log the context utilisation per step, per the token bill is a performance metric, and treat approaching the horizon as a signal to summarise deliberately and write state, on the agent's schedule, not the system's emergency schedule.

The rule

An agent's context is working memory, and compaction is lossy compression that keeps the gist and eats the negative knowledge, the exact values and the causal order, which are precisely the things a long investigation needs. Back the window with an external scratchpad, record rejected hypotheses with their refutations, and hand off between short sessions with a written brief.

The agent did not get stupid. It got amnesiac, and the difference matters, because amnesia has a treatment, which is writing things down, and stupidity does not. The transcript that loops is not a bad model, it is a good model reading its own compressed notes, and the notes are the part you control.