Progressive Summarization Risks

Long-running agents can't keep every turn in the context window. A common fix is progressive summarization: periodically compress earlier messages into a shorter recap so the conversation keeps fitting.

It works for narrative flow. But it has a sharp failure mode for the Context Management & Reliability domain: when prose gets compressed, numbers, percentages and dates go vague. "$1,284.50 refunded on 2026-03-14" quietly becomes "a refund was issued recently."

Summarization optimizes for gist, not precision. The model keeps the storyline and drops the exact tokens that carry transactional meaning.

• Amounts: "$4,999.00" → "a large charge"
• Percentages: "a 17.5% discount" → "a discount"
• Dates: "order placed 2026-01-09" → "earlier this year"
• IDs: "order #A-88231" → "the order"

These are exactly the facts downstream tools and policy checks depend on.

In Claude Code, /compact compresses the running context to free up room — the same mechanism, the same risk. After a compaction, a stack trace's line numbers, a failing test's exact assertion, or a config value can come back fuzzy.

The fix isn't to avoid compaction; it's to make sure the precise facts you'll need later don't live only inside the part that gets compressed.

The exam-grade fix is simple: pull transactional facts into a separate "case facts" block kept verbatim, outside the summary.

Summarize the conversational narrative freely — but maintain a structured, append-only block of exact values that is never passed through the summarizer. The summary keeps context cheap; the case-facts block keeps the numbers exact.

Keep the block machine-readable and verbatim. Each entry preserves the original value exactly as stated, with enough labeling to reuse it later.

This block is re-injected into the system prompt on every turn — remember the API keeps no server-side state, so you resend it as part of the full message history each request.

Split your context-management routine in two. When you compress, run the summarizer only over the dialogue, and leave the case-facts block untouched.

Order matters too: facts go near the top, the lossy summary lower down. The model attends to the start and end of context more than the middle (lost-in-the-middle), so authoritative numbers belong where attention is strongest.

Don't try to recover exact numbers after they've been summarized away — by then the source is gone. Capture them the moment they appear, straight from tool results.

Trim verbose tool output to the relevant fields before it enters history, but route the precise values you'll need into the case-facts block first. Use structured output (a tool call with a JSON Schema) so extraction is reliable, not a regex guess.

A tempting reflex: if a later answer cites the wrong amount, just retry with feedback. But retry-with-feedback only fixes format, structural or arithmetic errors — you resend the original doc, the wrong output, and the exact validation error.

Once a number has been summarized out of the context entirely, the information is simply absent from the source. Retry does not help when info is absent. Prevention (the facts block) is the only reliable fix.

When a number gates a consequential action — say a refund threshold — never let a summarized, fuzzy amount drive the decision. Enforce it deterministically.

A PostToolUse or outgoing-call hook reads the verbatim case-facts value and blocks policy violations 100% of the time. Prompts are ~90% probabilistic; hooks are deterministic. Use hooks when failure has financial, legal or safety consequences.

For research and extraction work, a verbatim fact is more trustworthy with its provenance: the source URL or doc name, the exact quote, and the publication date.

Dates frequently resolve apparent contradictions between conflicting stats — "revenue was $2.1M" vs "$2.4M" often just reflects different quarters. Annotate conflicting numbers with their sources rather than letting a summary silently pick one and blur the rest.

When a long session has been compacted many times, a resumed thread may carry a degraded summary — and resumed tool results can be stale if the codebase changed. Sometimes a fresh session seeded with a structured summary (your clean case-facts block) beats --resume.

The structured block is the carrier: it lets you start clean without losing the exact numbers and dates the work depends on.

A customer-support agent runs for many turns and periodically summarizes earlier messages to stay within the context window. QA finds it now quotes refund amounts and order dates that are slightly off or vague. Which fix is exam-correct?

Key takeaways for the Context Management & Reliability domain:

• Progressive summarization (and /compact) makes numbers, percentages and dates vague — the gist survives, the precision doesn't.
• Fix: maintain a separate case-facts block, verbatim, outside the summary; summarize only the narrative.
• Capture facts at the source from tool results; never try to recover them after they're gone — retry can't restore absent info.
• Place facts near the start of context (beat lost-in-the-middle); keep provenance + dates for research.
• Gate consequential thresholds with deterministic hooks reading verbatim values, and prefer a fresh session with a structured summary over a degraded resume.