19 — Context Condensation

Concept overview

Context condensation reduces a long interaction or execution history into a smaller representation for subsequent model calls. It is a lossy transformation and should be treated like one. A useful summary distinguishes verified facts, user preferences, completed actions, unresolved assumptions, and next steps rather than blending everything into fluent narrative.

Keep authoritative records outside the summary. Transaction identifiers, exact amounts, approvals, and source documents should remain recoverable through structured state and evidence references. Condensation reduces prompt load; it does not replace durable persistence or establish that the summarized facts were correct.

Why it matters in production

Proof of concept

A prototype can summarize old messages when a context threshold is reached. Compare later task performance against full-history runs before choosing a compression ratio.

Production

Production uses a summary schema, protected fields, provenance references, and versioned compaction boundaries. Preserve recent turns and exact tool outcomes needed for the next action.

Enterprise scale

At scale, hierarchical summaries and retrieval can manage long cases, but repeated summary-of-summary passes amplify omissions. Periodically rebuild from authoritative artifacts and measure factual retention rather than summary readability alone.

Architecture components

Context meter

Detects when prompt growth threatens reserved output or mandatory evidence capacity.

Condensation worker

Produces a structured summary under task-specific preservation requirements.

Protected-state store

Retains exact commitments, identifiers, approvals, and completed operations independently.

Evidence index

Maps summarized claims to original messages, documents, and tool artifacts.

Retention evaluator

Tests whether required facts and unresolved issues survive compression.

The architecture, mapped

flowchart LR
 H["Conversation and tool history"] --> B["Compaction boundary"]
 B --> S["Structured summary"]
 B --> P["Protected exact state"]
 H --> E["Original evidence archive"]
 S --> V["Retention validation"]
 P --> V
 V --> C["Next prompt assembly"]
 E --> R["Targeted evidence retrieval"]
 R --> C
 N["Recent turns"] --> C

Runtime flow

1. 1

   Choose boundary

   Identify stable older context that can be condensed while retaining recent active exchanges.

2. 2

   Extract protected facts

   Preserve exact identifiers, constraints, commitments, and unresolved operations outside free-form prose.

3. 3

   Generate summary

   Separate verified facts, assumptions, user preferences, completed work, and open questions.

4. 4

   Validate retention

   Compare mandatory facts and evidence references against the source material before accepting the summary.

5. 5

   Assemble next context

   Combine the summary, protected state, relevant retrieved evidence, and recent turns within budget.

6. 6

   Refresh responsibly

   Version the compaction and rebuild from originals when repeated condensation degrades fidelity.

Maintaining a multi-week incident investigation

Enterprise support · Illustrative enterprise scenario, not a reported customer outcome.

Business situation

A software vendor investigates an intermittent integration failure across many support exchanges and diagnostic sessions.

The problem

Appending every message makes prompts expensive and causes important customer constraints to disappear in a long context window.

Agent requirement

The assistant must remember verified diagnostics, prohibited changes, and outstanding questions while preserving source evidence.

Architecture

A structured summary holds the investigation state, and protected records retain ticket identifiers, tested versions, and approved maintenance windows.

Runtime

• After a stable investigation phase, older exchanges are condensed and checked against a required-facts list.
• A later engineer asks about a failed experiment; the assistant retrieves the original diagnostic artifact rather than trusting a compressed sentence alone.

Failure scenario

If condensation omits a customer restriction, validation rejects the summary and retains the previous context representation.

Operational impact

Track retained critical facts, retrieval frequency after compaction, prompt size, and repeated troubleshooting steps to quantify whether compression helps the investigation.

Architecture tradeoffs

Failure scenarios & recovery

Common architecture mistakes

Deleting original evidence after summarization

Retain recoverable sources under an explicit policy.

Summarizing exact financial values approximately

Store exact values in typed state.

Measuring only compression ratio

Evaluate downstream correctness and repeated-work rates.

When to choose this pattern

Choose it when

• Long interactions exceed practical prompt budgets.
• Critical facts can be enumerated and preserved separately.
• Original evidence remains available for targeted retrieval.

Avoid it when

• Exact full-text context is required for every decision.
• The history is already short and stable.
• No validation can detect loss of critical constraints.

Architecture checklist

• Define protected facts before compaction.
• Preserve uncertainty and unresolved questions.
• Keep source references in summaries.
• Retain recent active turns verbatim where needed.
• Version every compaction boundary.
• Test repeated summary-of-summary degradation.

Related concepts

• 12 — State Persistence
• 14 — Token-Aware Routing
• 70 — Dynamic Prompt Assembly
• 71 — Context Window Optimization
• 78 — Lost in the Middle Mitigation

Primary references

• LangGraph: persistence