The point of compaction is not to save tokens. The point is to preserve the working trajectory of the session.
Summary
Compaction is often described as a context-limit trick. That framing is too narrow. The deeper purpose of compaction is to preserve trajectory: the active objective, current truth, key decisions, unresolved errors, and next move. Long sessions fail when the agent loses that thread, not simply when the token count grows. Good compaction keeps the session pointed in the same direction while shedding stale detail. Bad compaction saves space but destroys momentum. The practical question is not “when do we hit the limit?” It is “when does the session stop carrying the right state forward?”
The Real Failure Mode
Long sessions do not usually collapse in one dramatic moment. They decay.
The agent starts strong. It explores the codebase, forms a plan, tests a path, refines the implementation, and accumulates evidence. Then the session gets noisy. Early experiments remain in context after they have been invalidated. Tool outputs pile up. Abandoned approaches retain equal weight with the final decision. By the time the agent is halfway through the task, it is carrying multiple versions of reality at once.
That is not just context bloat. It is trajectory loss.
Trajectory is the compact state that tells the agent:
- what it is trying to accomplish
- what the system currently looks like
- which decisions are settled
- which failures matter
- what should happen next
If that state becomes fuzzy, the agent starts drifting. It rereads files it already understands. It proposes paths that have already been rejected. It references deleted code. It answers the earlier version of the task instead of the current one.
Saving tokens is helpful. Preserving trajectory is the actual win.
Why Naive Summaries Fail
Most failed compaction comes from summarizing the wrong things.
A vague summary like “worked on auth system, fixed tests, next continue debugging” is smaller than the original history, but it throws away the state that makes continuation reliable.
Good compaction is selective. It should remove low-value history and preserve high-value state. That means:
- compressing old exploration
- keeping the latest working truth
- preserving unresolved errors
- preserving exact names of active files, artifacts, or interfaces
- carrying forward the next concrete step
This is why compaction should not be treated as a generic summarization problem. It is a state transfer problem.
The summary does not need to be elegant. It needs to let a fresh continuation pick up the task without recreating confusion.
Compaction Works Best at Boundaries
The biggest mistake is waiting until the context window is almost full.
By that point the session has already been carrying stale branches for too long. The agent has spent many turns reasoning over contaminated state.
Compaction works better at natural task boundaries:
After Exploration
Once the agent has gathered context and chosen a direction, compact the search phase into a short state snapshot. Keep the decision, discard most of the navigation trail.
After a Design Decision
If the task involved choosing between two approaches, capture the winning approach and the reason the loser was rejected. This prevents future backsliding.
After an Implementation Chunk
When one slice of work is complete, compact it into current truth plus remaining work. The implementation details can be revisited from files if needed. The session does not need every intermediate thought.
Before a Handoff or Mode Switch
If the session is about to move from exploration to writing, from writing to review, or from one model to another, compact first. A clean handoff packet is much more valuable than dragging the entire history forward.
In other words, compaction is not emergency cleanup. It is a control action at phase boundaries.
What a Good Compaction Packet Contains
A strong compaction packet is short, but it is not vague.
It should usually include:
Objective
- What the task is trying to achieve right now
Current Truth
- What is true in the repo, system, or draft at this point
Completed Decisions
- Which options were chosen
- Which options were rejected and why
Active Files or Artifacts
- Exact paths, outputs, or resources still in play
Errors to Preserve
- Unresolved failures
- Error messages or constraints that must not be repeated
Next Action
- The next concrete step, not a generic intention
That structure matters because it mirrors the agent’s working needs. The session does not need all prior words. It needs the state variables that determine the next good move.
What Must Stay Raw
Not everything should be compacted aggressively. Keep the most recent working turns raw enough to preserve interaction rhythm, and preserve important errors in recognizable form. If the compacted state forgets what failed, it will repeat the same mistake.
When to Reset Instead of Compact
Compaction is powerful, but it is not always enough.
You should prefer a clean reset when:
- the session has pursued the wrong objective for too long
- the current state is badly contaminated by obsolete assumptions
- the conversation contains too many contradictory architectures
- the next phase can be driven from files and artifacts alone
Resetting is more expensive than compacting because you have to rebuild context, but sometimes it is the only way to restore a clean trajectory.
The right mental model is:
- Compact when the trajectory is still good and the history is noisy.
- Reset when the trajectory itself is bad.
That distinction prevents both common mistakes: clinging to a poisoned session, and throwing away useful working state too early.
External State Makes Compaction Better
Compaction gets easier when important state lives outside the conversation. Plan files, specs, task lists, and generated artifacts reduce how much state must survive in chat memory. A changed file or draft on disk is a better memory primitive than a paragraph describing it.
The Practical Rule
Compaction should happen when meaning has stabilized, not when the token meter panics.
If the session has learned something important, chosen a path, or finished a subtask, compact it. Preserve the state that determines what happens next. Drop the rest.
That is what makes compaction a first-class context engineering tool. It is not garbage collection for old messages. It is the mechanism that keeps a long-running session aligned with its own best understanding of the task.
Related
- Context Rot & Auto-Compacting – Why long sessions decay without intervention
- Long-Running Agent Patterns – Compaction as a primitive for extended runs
- The RALPH Loop – When fresh context resets beat in-session continuation
- Prompts Are the Asset – Preserving process state, not just outputs
