An agent that refused to email a contract to an outside lawyer at hour one will send it at hour three, and nothing about the request has changed. You may have read our account of context decay; this article is about the step that does the deleting: summarisation. When a history is summarised, the agent gets a rewritten account rather than a known gap, so it cannot report what it lost. This article names what compaction discards, why that breaks a policy, and how to grade the loss.
What does context compaction actually throw away when an agent’s history gets summarised?
Context compaction is lossy compression of history under a token budget, performed by a summariser that does not know which sentence was load-bearing. It keeps the story and rewrites the details: a prohibition can read as work in progress, “do not deploy without sign-off” becomes “deployment discussed”, and exact identifiers, error strings and file paths get paraphrased. Hedges, exceptions and ordering constraints vanish first because they read as filler.
The reason behind a decision disappears before the decision does, so the agent keeps the conclusion and loses the justification. Models retain numerical keywords only 7.8% to 28.3% of the time: IDs, line numbers, error codes and commit SHAs are the first casualties. Approaches you already tried and abandoned are compressed to nothing, so the agent re-runs the thing you proved broken. Most damaging is the loss of the record of an external action: a pushed branch or started deployment happened outside the window, and the summariser can drop it.
Compaction is triggered by a token budget, so it fires most often when the run is longest and the accumulated constraints are most numerous. It fires before the window is full: agents compact against the effective context window, which is smaller than the advertised maximum. Compaction has been observed to trigger at as little as 5,000 to 20,000 tokens.
None of this is documented with the precision you would expect. Anthropic describes its compaction as preserving architectural decisions and unresolved bugs while discarding redundant tool output, but frames it as guidance rather than a versioned contract. OpenAI has described replacing repeated summarisation with notes plus searchable history in a recent release. Reported Claude Code thresholds have drifted from around 95% to about 83.5%; your team relying on a default is relying on an undocumented number.
The theory distinguishes compaction that selects a subset of the existing context from compaction that generates a new representation. Outside a paper it matters for one reason: a retained subset can be diffed against the original, while a generated summary is a new document with no record of what was excluded. Selection is auditable and generation is not.
Claude Code, Cursor and Codex differ less in whether they compact than in who decides. Claude Code ships auto-compaction by default and lets the operator move or disable the trigger; Cursor has recommended avoiding mid-task compaction; Codex runs compaction at a per-model threshold with no operator-facing toggle. Summarisation also invalidates the cached prefix and bills the next call at full rate. None of this yet explains the policy breach, which is the next question.
Why do agents break a policy after a long run even when the rule was in the original instructions?
Compaction edited your agent’s history. The rule lived in the system prompt, the summariser compressed the history including the reasoning that produced the rule, and the agent kept acting coherently against a now-silent policy. The breach arrives late in the run.
There is no error and no log line, so you debug the model instead of the harness. A crash is loud; this is silence. A controlled study measured: one compaction step took governance-constraint violations from 0% to a pooled 30%, up to 59% on the two most affected models, with model, request and tool layer unchanged. When the constraint survived the summary, violations stayed at zero; when it was dropped, they hit 38%.
Call the pattern Governance Decay: a rule obeyed while visible and violated after compaction removes it. It differs from context poisoning, distraction, confusion and clash, which describe content that is still there but misleads. Loss removes content outright, and only poisoning is detectable by reading the transcript. One caveat: the headline study is a single-author preprint nobody has replicated, so treat pinning as cheap insurance rather than a proven requirement.
What should we measure to know whether compaction is silently dropping constraints?
The summary text cannot be graded directly; grade what the agent still obeys after compaction. Three signals of ascending cost do the job: constraint survival, whether each pinned constraint is still present after every pass; constraint recovery, whether the agent still behaves after the pin is removed; and behavioural regression, whether a replayed known-good task still adheres to policy.
Constraint survival is the cheapest, and it is deterministic. Constraint recovery is the harder question: unpin the rule and see whether the agent can reconstruct what it had ruled out from what remains. That is the difference between a recoverable summary and an unrecoverable one, and it tells you whether your summariser is trustworthy for that class of item. Behavioural regression matters because sustained-interaction accuracy falls around 30% without showing up in single-turn tests.
You cannot grade a loss you never recorded. That is why pinning is an editorial job. Decide what to pin by consequence: pin what is cheap to keep and expensive to lose, hard prohibitions, identifiers, approval requirements, budget and scope limits, and let go of the exploratory reasoning that produced them. Pinning everything is the same as pinning nothing, because the pinned block then competes for the same budget. Once you know whether the constraint survived, the next question is what else was in there, the job of auditing what entered the window on a failed run.
The loss is now measurable: a set of binary checks and regression runs you can execute before the breach. Make the summariser the thing you instrument. For what this means for the wider stack, and for the cache invalidation bill that follows a summarisation, read on.
Frequently Asked Questions
Does compaction drop system prompt instructions, or only the conversation history?
Usually the rule itself survives, because many harnesses preserve the system prompt verbatim, which makes it the safest channel in the stack. What disappears is everything the conversation built around it: the reasoning that justified the rule, the case where it was applied, and the restatement that made it concrete for this task. A harness that reloads the prompt still hands back a history where the rule is an assertion with no supporting argument, which is often enough for the agent to reason its way around it.
Is context compaction the same thing as context rot?
Not the same, but they are easily confused, and the confusion changes what you fix. Context rot is a property of the model: reasoning quality declines as input length grows, even when nothing has been removed. Compaction is an action taken by the harness, which deletes and rewrites content under a token budget. A long run can suffer both at once, so the honest test is a replayed run with and without a compaction pass at identical length.
Why does a compacted agent sometimes behave worse than an agent that was never given the rule?
Because the summary does not leave a visible gap. It leaves a normalised task description with the rule quietly stripped out. An agent that never saw the policy has no reason to act against it, while a compacted agent has already committed to a plan shaped by the rule and then loses the constraint that justified the plan. Measured violation rates can therefore exceed the no-policy baseline: the harness kept the intent and deleted the boundary.
Does the loss compound across multiple compaction passes?
It does, and this is the part single-pass testing hides. Each pass summarises the output of the last one, so anything dropped in round one cannot be recovered in round three. Published measurements on production agent configurations show safety-rule retention falling from roughly half after a single round to about one in ten after five. A check that passes on your first compaction tells you almost nothing about the session’s tenth.
Can I tell what a compaction dropped by reading the summary?
Rarely, because a summary is a new document rather than a record of what was kept. It reads fluently and consistently, which is exactly the problem: nothing in it signals absence. That is the practical difference between selection and generation. Selection is auditable, since you can diff the retained subset against the original. Generation is not, since the summary has no provenance. This is also why the agent cannot report the loss for you.
Does a bigger context window solve this?
No, it moves the deadline. Compaction triggers against the effective context window rather than the advertised maximum, and reasoning quality degrades well before the hard limit, so a larger window buys a longer run and a later first compaction. Everything after that first pass is unchanged, and the constraints accumulated by then are more numerous. A million-token window is a longer runway, not a different failure mode.
Does pinning a constraint guarantee the agent will obey it?
No. Pinning guarantees the rule is present, which is a precondition for obedience rather than a substitute for it. The failure it does not close is an authoritative claim inside the token stream: content that reads like an operator update rescinding the pinned rule. An agent has no reliable way to tell a genuine operator instruction from text impersonating one, so closing that gap needs an approval channel outside the context.
How much overhead does constraint pinning add?
Very little, because pinned state is re-injected only when a compaction fires, so the cost is fixed per pass rather than growing with the run. Published measurements put a governance constraint at a few dozen tokens, a rounding error against the histories that trigger compaction in the first place. The real cost is editorial: someone has to decide what qualifies, and that decision has to be revised as the task changes.
Is summarising better than simply dropping the oldest turns?
Usually yes, but the two fail differently. Dropping the oldest turns is honest and cheap: the content is gone, and the agent cannot misread a paraphrase of it. Summarising preserves narrative continuity and invents plausible replacements. Recency eviction is the worst case for constraints, because a rule stated early is the first thing to leave. If you must choose, retain the head as well as the tail.
Does compaction actually reduce cost?
Not automatically. It cuts input tokens on every subsequent call, but it also invalidates the cached prefix, so the call immediately after a compaction bills at full rate. The saving only lands if the reclaimed tokens repay that, and if the agent does not spend the difference re-reading files or repeating an attempt it had already abandoned. Compression ratio on its own is a claim about the invoice line, not the run.
Why does the agent redo work it has already finished after a compaction?
Completing the work and recording that it was completed are two different pieces of history, and a summary often keeps only the first. Records of external actions are especially exposed: a push, a migration or a sent email happened outside the window, so if the identifier is lost the agent cannot know the action already succeeded. Re-running a non-idempotent step is the predictable result, so reconcile the summary against the live system before the agent resumes.
