Context compaction needs a recovery test
Compaction can keep a long-running agent inside its context budget while changing what it remembers. Verify recovery of critical state, not just the smaller token count.
A long-running agent can survive a full context window and still forget the one identifier that makes its next action safe. Context compaction solves a capacity problem by replacing history with a smaller representation; it does not prove that the resulting state is complete.
My rule is to treat every compaction as a recovery boundary. The acceptance test is not “did the token count fall?” It is “can a fresh run reconstruct the commitments that still govern this job from versioned artifacts and the compacted state?” This is editorial judgment—I did not run OpenAI or Anthropic compaction against a Trigent or client workflow.
OpenAI's compaction object is a state handoff
OpenAI's current Responses API reference exposes POST /responses/compact and returns an opaque encrypted compaction item. Its GPT-5.5 guidance tells long-running agents to preserve completed actions, active assumptions, identifiers, tool outcomes, unresolved blockers and the next goal.
That list is more than prompt advice. It is a useful state schema. If a production run cannot show where those fields survived the handoff, continuity is being inferred from fluent behaviour.
The distinction matters because the compressed representation becomes an input to later decisions. A missing paragraph in an ordinary summary is an editorial defect. A missing approval ID, rejected migration path or failed security check can change what an agent does next.
A smaller context can retain different facts on a rerun
A May 2026 context-compaction paper tested four model backbones from 8B to 120B parameters on HotpotQA and LoCoMo. The authors describe sequential compaction that removes 90–99% of input tokens. They also report that identical conversation snapshots and prompts can produce summaries whose length shifts by hundreds of tokens and whose semantic content changes between runs.
Those are author-reported results; I did not reproduce the experiments. The benchmarks and tested designs do not establish the failure rate of every production agent. They do support a narrower correction: deterministic triggering does not make the retained state deterministic.
I would therefore keep the pre-compaction event record and the compacted item under separate identities. A run receipt should name the source checkpoint, compaction model and configuration, resulting checkpoint, and verification result. Without that lineage, a later failure leaves the team comparing two narratives instead of two state transitions.
Durable artifacts should carry exact commitments
Anthropic's current long-horizon guidance recommends structured state such as test files, free-form progress notes and git checkpoints. It even suggests that a fresh context can be preferable to compaction when the model can rediscover state from the filesystem.
That is the operational pattern I would steal. Put exact commitments in artifacts designed for exactness: test status in structured data, code state in version control, external actions in an event ledger, and unresolved decisions in a progress record. Let the narrative summary orient the model; do not ask it to be the only database for the job.
The recovery drill is simple. Capture the six fields before compaction, continue from the compacted state, then have a clean reviewer compare what the agent believes with the durable record. A field that disappeared, changed status or lost its source fails the handoff even when the agent completes an impressive next step.
This extends an earlier AndyMental distinction: deleting a distilled memory does not remove its source transcript. Compaction is the opposite direction. The raw history may still exist, but the acting agent now sees only the derivative. Provenance is what lets it return to the source when the derivative is insufficient.
What's in it for you
- Make completed actions, assumptions, IDs, tool outcomes, blockers and next goal explicit before the context limit forces the issue.
- Preserve the source checkpoint separately from the compacted state, with the model and configuration that created the handoff.
- Run one clean-context recovery test before trusting an agent to continue consequential work across compactions.
Compaction is successful only when the agent can recover the job's governing state—not merely continue talking.
