When the context window fills, the system summarizes earlier messages. “$127.50 refund for order #ORD-2024-0312 with 48-hour deadline” becomes “customer requested a refund with quick resolution.” The agent now lacks the amount, the order ID, and the deadline. It processes $50, ignores the order number, and promises “within a week.”
This is not a model error. It is summarization doing exactly what summarization does: compressing specific details into general descriptions.
What Summarization Loses
Fact retention across 100 customer support conversations requiring summarization:
| Information type | Retention rate |
|---|---|
| Sentiment/intent (“customer is frustrated”) | 94% |
| Categorical facts (“product: electronics”) | 87% |
| Specific numerical values (“$127.50”) | 31% |
| Exact dates and IDs (“order #ORD-2024-0312”) | 23% |
Sentiment survives because it generalizes without losing meaning — “frustrated customer” is accurate whether summarized or not. Numbers, dates, and IDs are destroyed because summarization replaces them with categories: “$127.50” becomes “refund amount,” “March 15” becomes “upcoming deadline.”
The values the agent needs most for correct action — amounts, dates, IDs — are the most vulnerable to loss.
The Fix: Structured Case Facts
Extract critical values into a structured case_facts object that persists alongside the summarized narrative. The narrative compresses; the facts do not.
{
"case_facts": {
"refund_amount": 127.50,
"order_id": "ORD-2024-0312",
"resolution_deadline": "2026-03-31",
"customer_tier": "premium"
},
"summary": "Premium customer requesting refund due to defective product. Expressed frustration with initial response time."
}The summary handles conversation flow. The case_facts handle precision. Both survive summarization because the facts are extracted before the narrative is compressed.
The Data
500 cases compared:
| Approach | Incorrect values after summarization |
|---|---|
| Standard summarization | 27% |
| Structured case facts + summarization | 3% |
89% reduction. Same conversations, same model, same summarization trigger. The only difference: extracting amounts, dates, and IDs to a structured object before each summarization.
Why Better Summarization Prompts Do Not Work
“Keep all critical details during summarization” is itself a vague instruction. The model may still generalize “NullPointerException at line 42” into “null error in the auth module.” Prompt instructions for summarization face the same interpretation ambiguity as any other vague directive.
Structured extraction is deterministic: identify the data types that must survive (amounts, dates, IDs, version numbers), extract them to named fields before summarization occurs. The extraction is explicit, not dependent on summarization quality.
The First Step
Before implementing any preservation strategy: identify which data types must survive summarization. Not everything needs extraction — sentiment and categories survive naturally. Numbers, dates, IDs, and configuration values need explicit persistence.
Once identified, extract them to persistent storage (scratchpad, case_facts object, deployment_state) before each summarization cycle.
Dual-Constraint Design
Long sessions need both narrative context (for natural interaction flow) and precise parameters (for correct action). Separate them:
- Narrative → summarizable. Compresses naturally. Provides conversation flow.
- Parameters → persistent. Version numbers, config values, timestamps, rollback points. Never generalized.
Summarization handles the narrative. Structured storage handles the parameters. Both constraints satisfied.
One-liner: Extract specific values (amounts, dates, IDs) into structured case_facts before summarization — narrative compression is fine, but precise values that survive at only 23-31% need explicit persistence to prevent the 27% error rate.