Compaction is the act of summarizing older context into a smaller representation while preserving the goal-relevant facts. It is how a long-running session keeps going once the context window fills up.

What triggers compaction

A few common triggers:

  • Window threshold. The platform watches the total token count. When it crosses a defined threshold (commonly 70–80% of the model's limit), compaction fires.
  • Turn count. Some platforms compact on a fixed cadence — every N turns, regardless of size.
  • Explicit request. An operator or a tool can force a compaction to bound the next turn's cost.
  • Tool-result overflow. A single tool returned so much output that the rest of the conversation no longer fits; the agent must compress.

Naive vs smart compaction

A naive compactor trims the oldest turns first. It is cheap, fast, and consistently wrong: the model loses the parts of the transcript where the goal was clarified, decisions were made, and tool contracts were negotiated.

A smarter compactor does three things differently:

1. It identifies what matters. Goals, decisions, file paths, tool state, named entities, the current task, and unresolved questions are marked as preservable. Casual back-and-forth, restated instructions, and completed tool outputs are marked as compressible. 2. It preserves the trajectory. The shape of the work — what was tried, what failed, what got re-tried — is preserved at the level of a summary, not the level of the transcript. The agent can pick up the thread without re-reading the transcript. 3. It preserves exact strings only when they matter. Names, paths, identifiers, error messages, and code snippets stay verbatim. The rest gets rewritten.

What's lost and what's preserved

Lost during compaction:

  • Exact wording of early user requests.
  • Verbose tool output that has already been acted on.
  • Quoted passages the model will not need to cite again.
  • Redundant restatements of the same instruction.

Preserved during compaction:

  • The current goal and its sub-goals.
  • Decisions made and the reason each decision was made.
  • File paths, identifiers, and tool-state values the agent still needs.
  • Open questions and unresolved errors.
  • Anything the user explicitly asked the agent to remember.

The pattern that works in practice: preserve the trajectory, summarize the transcript. The transcript is reconstruction; the trajectory is what keeps the next turn pointed in the same direction.

See also

  • Context vs Memory — context is what the model sees in the current call; memory is what survives.
  • Session — compaction runs inside a session and shapes its lifecycle.
  • Agent Memory — compaction is not memory; it is a local compression of the current transcript.

Compaction's role in the agent's long-running work

Compaction is the mechanism by which the agent's long-running work stays manageable. The agent that runs for hours produces megabytes of state; the agent that runs for days produces gigabytes of state. Without compaction, the agent's state grows without bound, and the agent's context window becomes unmanageable.

The compaction step is the right place to start when an operator is debugging an agent that is losing context. The agent that is losing context is the agent whose compaction step is failing. The agent that is hallucinating is the agent whose compaction step is over-compressing. The agent that is slow is the agent whose compaction step is too expensive. The compaction step is the operator's interface to the agent's long-term memory.