Validate Compression
Treat every summary as a risky rewrite. Validate compressed context against the next task before you trust it.
The Problem This Solves
Compression is usually treated as cleanup. The agent summarizes a long conversation, drops the raw history, and keeps working from the shorter version.
That is convenient, but unsafe. A summary can preserve facts and still lose the intent, uncertainty, ordering, or constraint that matters for the next step. It can also introduce a false claim that becomes stable context for the rest of the task.
The failure is hard to spot because the summary looks coherent. Coherence is not preservation.
How It Works
Validate compressed context before it replaces the source. The validation target is not whether the summary reads well. The target is whether the next step still has the facts, decisions, constraints, and open questions it needs.
A practical validation pass checks the candidate summary against the live task state:
| Check | Question |
|---|---|
| Facts | Are the task-critical facts still present and specific? |
| Decisions | Are prior decisions preserved with their rationale? |
| Constraints | Are hard limits, exclusions, and style rules still visible? |
| Uncertainty | Are unresolved questions still marked as unresolved? |
| Next action | Can the agent continue without rereading the source? |
Slipstream makes this pattern concrete. It generates compaction candidates asynchronously while the original agent keeps working, then validates those candidates against the agent’s actual continued trajectory. The summary is judged against future work, with a tidy recap treated as secondary.
Example
An agent is working on a migration. The raw conversation contains three important facts:
- The new column must be nullable for the first deploy
- Backfill runs after the release window
- The API must keep accepting the old field for two weeks
A weak summary says:
Add the new column, backfill existing records, and update the API to use the new field.
It sounds correct, but it removed the deploy ordering and compatibility constraint.
A validated compression keeps the operative details:
Add the new nullable column first. Do not require it during the first deploy. Keep accepting the old API field for two weeks. Run the backfill after the release window, then tighten validation in a later change.
The second version is longer, but safer, because compression is only useful when it preserves what the next action depends on.
When to Use
- Long-running agent tasks that periodically summarize their state
- Handoffs between agents, sessions, or context windows
- Summaries that will replace source material instead of sitting beside it
- Work where ordering, constraints, or unresolved decisions matter
When Not to Use
- Disposable summaries used only for human orientation
- Small contexts where the source can stay in the window
- Cases where compression is only indexing, and the original evidence remains one click away
Related Patterns
- Compress & Restart explains when to cut a long context down
- Context Handoff is where compression failures often become task failures
- Select, Don’t Dump still applies; validation is not permission to keep everything
- Context Poisoning covers the risk of false compressed state becoming trusted context