An agent that has worked for an hour reaches the end of its context window. The tool stops it, asks the model to write a summary of everything so far, and restarts from that summary. Many coding agents do this on a command or automatically, and other agent stacks have their own version.
Afterward something is off. The agent re-reads files it already processed. It retries a call that failed for a reason it no longer remembers. It asks a question you answered, or breaks a rule you gave it at the start. The summary usually reads fine. It names the goal and the main steps, and what went missing is one small, specific thing.
This post goes through every reason a compacted agent forgets, what you can do about each, the one underneath them, and the small part an engine can fix.
Every cause, and what to do about it
1. The summary is written before anyone knows what will matter. Whoever writes it has to guess what the next hour needs, and guesses once. The authors of Slipstream put it as a gap in validation: the compactor must condense context but is unaware of what the agent will need later. They also say errors then propagate silently, as coherent but incorrect behavior. The case Tian Pan describes is concrete. An agent hits a permission error writing a file and switches approach. The summary says it has been writing output files and leaves out the error. Afterward the agent tries the same write again.
2. Exact figures and identifiers get smoothed. A summary is prose. Order numbers, amounts, dates and IDs are the details a paraphrase is most likely to blur or drop. In our own test on very long histories with Gemma 4 31B, 30 of the 43 questions a summarizing loop got wrong were answered with some version of "the detail isn't in my notes". The post on summarizing old context has the method and the limits of that test.
3. Completion records go first. Tian Pan's post also describes summaries that keep the goal and lose the records of what already finished, so the agent redoes finished work. That is how a compacted agent ends up repeating an action.
4. Each compaction starts from the last summary. A detail dropped once has no source left that the model can see. After several compactions the loss can be permanent, and the agent may have no way to tell that something is missing.
5. The model believes its own summary. One paper, Compaction as Epistemic Failure, documents a coding-agent session where partial output from a killed process was written into the summary as completed results, and a later session accepted them. It is one author's report, with one main case and four similar ones, and the author says the compaction mechanism isn't documented in enough detail to tell whether the behavior is intended.
6. The trigger is a size, not a moment. Compaction usually fires when the window fills, not when a task finishes. If it lands in the middle of a step, a tool call that is half done can be summarized before its result is written down.
What you can do without us
- Keep hard constraints, IDs and open commitments in a file the agent re-reads each session, not in the conversation.
- Compact by hand, earlier than the automatic trigger, at a point between tasks, and say what to keep.
- Have the agent append each finished step and its result to a log on disk, and check the log before it repeats anything.
Each of these takes something out of the model-written summary and puts it somewhere the model can't rewrite. Causes 1 to 5 get smaller with every one you adopt. Cause 6 gets smaller if you pick the moment.
The cause underneath
A model decides what the record says. The same model that is running out of room, and that doesn't know what comes next, writes the version of events that every later step will treat as the truth. A better summary prompt makes the guess better. It stays a guess, and it stays the only copy.
What an engine can fix
That is the part we build. In the Argentic engine, every step is recorded and each prompt is rebuilt from that record. The facts, open plans and what already happened are put into the prompt by code, so no model-written summary has to carry them across a rebuild. It does not fix cause 1 in the general case: the engine still chooses what fits in a bounded prompt, and it can choose badly. We build the engine, so weigh this accordingly.
What we measured
Our own scenario is a 900-event shift at a small online shop, one event at a time, on Claude Haiku 5.5. We ran it twice on the hosted engine (release 0.51.0), once with the engine carrying state and once with the older setup where the model writes a report at each rebuild.
- Questions about running stock counts: 22 of 28 right with the engine carrying state, 4 of 28 with the older setup.
- Recalling facts stated earlier in the shift: 91 of 91 vs 86 of 91.
Six of the 28 stock answers are still wrong with the engine carrying state. The graded rows are downloadable.
What we haven't shown
- One run per setup, on a scenario we generated, with one model. Haiku isn't deterministic, so 22 against 4 is a strong signal and not an effect size.
- Our engine against its own older setup. We have not compared it with any other compaction setup, and a well-tuned one could close much of the gap.
- The engine has changed since release 0.51.0, and we haven't rerun this on later builds.
- The October long-history numbers are from older engine builds, and we have not rerun them.
Sources and method: 11 hours 59 minutes on shift: what the agent remembered.