What you need to know
Three ways long interactions lose information
- Progressive summarisation. To save space, older turns are summarised. Summaries turn "$127.43 refund for order #889234, return window ends 14 March" into "the customer discussed a refund". Numbers, percentages, dates and what the customer was promised are exactly what gets lost.
- Lost in the middle. Models use the beginning and end of a long input reliably, and may under-use material in the middle. In an aggregated input of six subagents' findings, the third and fourth are most at risk.
- Tool result bloat. Every tool result stays in the conversation. An order lookup returning 40 fields, of which 5 matter for a return, spends tokens on 35 irrelevant ones every turn after.
Also remember the basics: the API is stateless, so each request must carry the complete conversation history you want Claude to use. Dropping turns silently breaks coherence.
A persistent case-facts block
Keep transactional facts outside the summarised history, in a structured block included in every prompt:
<case_facts>
customer: C-118204 (verified)
issue_1: order 55107, tent torn, refund $219.90 approved, status: processing
issue_2: order 54980, 340 loyalty points missing, status: credited
promised: refund confirmation email within 24 hours
</case_facts>The history around it can be summarised freely; the facts are never paraphrased. For multi-issue sessions, keep one entry per issue so order numbers and amounts never cross over.
Trim tool output early
Reduce each tool result to the fields that matter for the task before it is added to the conversation, for example in a PostToolUse hook (lesson 1.5). The trimmed result is what accumulates, not the 40-field original.
Arrange long inputs deliberately
- Put a summary of key findings at the beginning of an aggregated input.
- Organise detailed results under explicit section headers.
- Ask upstream agents for structured output (key facts, citations, relevance scores, dates, source locations), not full excerpts and reasoning chains, when the downstream agent has a limited context budget.
In the exam
Scenario 1 (long support chats with misquoted amounts) and Scenario 3 (aggregated subagent outputs with the middle under-represented) carry most of these.
Check your understanding
In long support chats the agent misquotes refund amounts and mixes up order numbers. Older turns are summarised. What should change?
Show answer
Answer: B. Summaries blur exact values. A structured facts block, outside the summarised history and in every prompt, keeps them exact.
Synthesis under-uses findings from the middle subagents of a long aggregated input. Which TWO changes help? Select TWO.
Show answer
Answer: A, C. Position effects are reduced by surfacing key findings first and giving the detail a clear structure to navigate.
Each order lookup returns 40 fields; returns need 5. Context fills quickly. What helps most?
Show answer
Answer: C. Trimming at the source stops irrelevant fields from accumulating in context turn after turn.
Apply it: Cedar Ridge's context layer
Cedar Ridge's long chats are where wrong amounts and mixed-up orders appear. Design the context layer.
- Design the case-facts block for a chat with two issues.
- Choose the six order fields that survive trimming for returns, and say where trimming happens.
- Write the rule for what may be summarised and what never is.
- Say how the block is updated when a tool result changes a fact.
Show model answer
1. Block
| Field | Example |
|---|---|
| customer | C-118204, verified by email and order number |
| issues[] | {order, problem, amount, status, promised} per issue |
| commitments | "Refund confirmation within 24 hours" |
2. Fields. order_id, order_date, delivery_date, items (name, price, quantity), payment_method, return_eligible. Trimming happens in the PostToolUse hook on lookup_order.
3. Rule. Conversation turns older than ten may be summarised. Amounts, order numbers, dates, statuses and anything promised to the customer are never summarised; they live in the block.
4. Updates. The harness updates the block from structured tool results (for example process_refund returning a status), not from Claude's prose. Each issue entry is updated in place, so the latest status replaces the old one.