Progressive Summarization & Its Risks

When a conversation outgrows the context window, you cannot keep every token. Progressive summarization (also called compaction) replaces older turns with a compressed summary so the agent can keep going. Claude Code's /compact is a concrete instance: it summarizes the session and continues from the summary. The technique is necessary — but it is lossy, and the exam tests whether you understand the failure modes.

How it works

1. The window approaches its limit (or a turn count / token threshold trips).
2. Older messages are sent to the model with an instruction to summarize them.
3. The summary replaces the original messages; recent turns and the system prompt are preserved verbatim.

The risks

Summarization is irreversible compression. Each pass can:

• Drop load-bearing detail. A summary like "investigated the auth bug" silently discards the specific file, line, and hypothesis the next step needed. The agent then re-derives it (wasting tokens) or, worse, hallucinates it.
• Compound errors across rounds. If round 1's summary contains a subtle mistake, round 2 summarizes the mistake, and it ossifies. This is error compounding — the summary becomes the new ground truth even though it is wrong.
• Lose provenance. "The API returned 1,200 records" loses which API, which filter, and whether 1,200 was complete or truncated. Decisions built on a lossy summary inherit its ambiguity.
• Summarize away the goal. Long sessions can drift; if the original task statement is paraphrased once too often, the agent optimizes a degraded objective.

Mitigations

Treat summaries as caches over durable state, not as the state itself:

• Persist critical facts to a scratchpad file (next module) — file paths, IDs, decisions, open TODOs. Summarize prose; never summarize the facts you must not lose. Write them to disk where they survive every compaction.
• Preserve raw anchors. Keep exact identifiers, error strings, and the verbatim task statement out of the summarizable region (e.g., re-inject them after compaction).
• Summarize early and lightly, not late and aggressively. Frequent small compactions lose less than one giant emergency compaction.
• Trim before you summarize. Often the window is full of removable tool output, not irreplaceable reasoning. Strip the noise first; you may not need to summarize at all.

When NOT to summarize

If you can fit the work by trimming or by delegating verbose discovery to a subagent, prefer that — those are lossless with respect to the parent's reasoning. Summarize only when genuinely over budget.

Exam focus

Progressive summarization is necessary but lossy. Expect questions contrasting it with trimming and subagent delegation. The right answer keeps durable facts on disk (scratchpad / JSON snapshot) and only summarizes prose, recognizes error compounding across repeated passes, and trims removable tool noise before compacting rather than relying on summarization to recover lost detail.