Compaction Is a Lossy Handoff

Every long agent run eventually forgets on purpose. The only real question is whether anyone decided, in advance, what it would forget.

That scheduled forgetting is compaction. Anthropic's context engineering guidance describes it as taking a conversation that is nearing the context window limit, summarizing its contents, and reinitiating a new window with the summary. In Claude Code, the summary keeps architectural decisions, unresolved bugs and implementation details while discarding redundant tool outputs, and the agent carries on with the compressed context plus the five most recently accessed files.

Read that example slowly, because the interesting part is the choosing. A summarizer looked at everything the run had seen and decided which of it the future deserved. The run that continues on the other side cannot ask what was cut. It cannot even know that something was cut. It has the summary, and from that moment the summary is the past.

That is why we treat compaction as a handoff rather than a compression setting. A handoff is a transfer to someone who was not there, and it fails in predictable ways: outcomes arrive without their reasons, exact figures get rounded into adjectives, and an open question comes back sounding settled. Compaction fails in exactly those ways, because underneath the mechanism it is the same act.

Write the keep list before you need it

You cannot brief the summarizer well at the moment the window fills. By then the context is crowded, the run is mid-task, and whatever instructions you bolt on are competing with the very material they are meant to sort. The keep list belongs in the design of the run, written while everyone is calm.

Ours is short. The goal, in the words it was given. Decisions, with the reason each one went the way it did. Open questions, still marked open. And exact values (case IDs, amounts, error strings, version numbers) copied character for character, because a summarizer paraphrasing an identifier produces a confident reference to something that does not exist.

Anthropic's tuning advice runs the same direction: start by maximizing recall, capturing everything that might be relevant, then iterate toward precision by cutting what proves superfluous. Err toward keeping too much on the first pass. You can measure and trim a summary that kept a useless paragraph. You cannot measure a fact that never made it across.

The provider machinery will not make these choices for you. Claude's server-side compaction fires when input tokens cross a trigger you set, 150,000 by default with a floor of 50,000. OpenAI's compaction works the same way server-side, and also offers a standalone endpoint that returns a compacted window you pass on as-is. Both answer the question of when. Neither knows what matters in your run.

Timing still deserves thought. Compact too late and the summarizer is working from a crowded, degraded history, summarizing the noise along with the signal. Compact too often and the losses stack, because the second compaction does not summarize your run. It summarizes a summary.

Keep the original within reach

A summary that replaces the only copy of the history is a single point of failure with a fluent writing style. Keep the full transcript and the run's artifacts outside the window, in a store the agent can read, and make the summary carry pointers: which tool result, which document version, which stretch of the log stands behind each kept claim. The pointer is what turns compaction from an act of faith into something auditable.

Start lighter than compaction where you can. Anthropic calls tool result clearing one of the lightest-touch forms of compaction: remove raw tool outputs once the agent has acted on them. A long test log that produced one failing test name rarely needs to survive verbatim. The failing name and a pointer to the log do. Plenty of runs can clear aggressively for a long time and compact rarely, which is the right order. Deleting what is provably dead is a safe operation. Summarizing what is still alive is a judgment call.

One summary, checked against the original

Here is the check we mean, on an example compacted summary from a contract review. The lines are the example summary's own. The notes are what a comparison against the original history found.

Notice which line does the damage. It is not a missing line. The summary kept the payment-terms check and dropped the fact that the agreement it was checked against had been superseded, so the surviving sentence is accurate and misleading at the same time. Fluent summaries prefer closure. An unresolved dispute tends to come back as a reviewed item, a superseded source as a source. If you sample only one thing after compaction, sample for false closure: open items that returned sounding finished.

Where compaction stops being the answer

Anthropic's work on long-running agent harnesses is blunt on the limit: compaction on its own is not sufficient, because it does not always pass perfectly clear instructions across to the next session. Their answer is to leave structured artifacts outside the window (a progress file, a feature list) that the next session reads directly. When a task's state can live in artifacts like that, a clean restart reading good artifacts can beat a summary trying to hold everything in prose.

Compaction also cannot rescue a run whose problem was never length. If the agent is looping, summarizing hands it a shorter version of the same wrong history to continue from. If the underlying data is bad, the summary preserves the badness more compactly. And some stretches of work should not be summarized mid-flight at all: where the exact wording is itself the evidence, end the run at a boundary, keep the record whole, and start the next run from artifacts.

So test it the way you would test anything else that can silently change behaviour. Replay finished runs, compact them at the threshold you plan to use, and diff what the summary claims against what the original shows. A compaction setting that has never been through that check is a hope with a token count attached.

The design question was never whether to compact. Long runs leave you no choice. It is what your run is allowed to forget, who wrote that list, and whether the original is still there on the day the summary turns out to be wrong.

Work with us

If your long-running agents come back from compaction missing the one detail the task turned on, the fix is rarely a bigger window. It is a keep list written in advance, pointers back to the original, and a check on what survived. Tell us about the run through Trida AI's intake.