Manage Conversation Context Across Long Interactions
This module is about keeping critical facts reliable when a conversation, agent workflow, or tool-use loop gets long.
The exam’s core idea:
Do not rely on vague summaries or raw accumulated history for critical facts.
Extract critical facts into structured, persistent context layers.
Trim irrelevant tool outputs before they consume context.
Put important summaries where the model is most likely to use them.
Anthropic’s Messages API is stateless: for multi-turn conversations, you send the full conversation history on each request, rather than assuming the server remembers prior turns automatically. That means the application is responsible for deciding what history, summaries, tool results, and structured facts are passed forward. (Claude Platform)
1. Core mental model
Treat context as having layers:
Layer 1: Stable instructions
Layer 2: Persistent case facts
Layer 3: Structured issue data
Layer 4: Relevant recent conversation
Layer 5: Trimmed tool results
Layer 6: Detailed source excerpts only when needed
The exam shortcut:
Critical facts should be structured and repeated.
Verbose details should be trimmed.
Raw history alone is not reliable context management.
2. Progressive summarization risks
Progressive summarization means repeatedly condensing earlier conversation into shorter summaries.
It is useful, but risky.
Bad summary:
What got lost?
Order ID: ORD-73821
Refund requested: $129.47
Promised delivery: June 12, 2026
Actual delivery: June 18, 2026
Customer-stated expectation: full refund if delivery was more than 5 days late
Current order status: delivered
Prior agent commitment: escalation if refund denied
The exam point:
Summaries often preserve the gist but lose transactional precision.
This is especially dangerous for:
amounts, percentages, dates, deadlines, order IDs, ticket IDs, statuses, customer commitments, policy thresholds, eligibility criteria
2.1 Better pattern: keep a persistent Case Facts block
<case_facts>
- customer_name: Priya Sharma
- customer_id: CUST-44391
- order_id: ORD-73821
- order_total: 129.47 USD
- promised_delivery_date: 2026-06-12
- actual_delivery_date: 2026-06-18
- delay_days: 6
- current_status: delivered
- customer_request: full refund
- customer_stated_expectation: "Full refund if delivery was more than 5 days late"
- policy_threshold_mentioned: 5 days
- prior_agent_commitment: escalate if refund is denied
</case_facts>
This block should be included in each prompt outside the summarized history.
3. Case facts vs conversation summary
Do not make the summary carry all important facts.
Use both:
3.1 Example
Conversation summary:
<conversation_summary>
The customer contacted support about a delayed delivery and requested a refund. The agent checked the order and discussed refund eligibility.
</conversation_summary>
Case facts:
<case_facts>
- order_id: ORD-73821
- order_total: 129.47 USD
- promised_delivery_date: 2026-06-12
- actual_delivery_date: 2026-06-18
- delay_days: 6
- requested_resolution: full_refund
- refund_policy_relevant_threshold: 5_days_late
</case_facts>
Why this matters:
4. Multi-issue sessions need structured issue data
Long support sessions often contain multiple issues.
Bad summary:
Better structured issue layer:
{
"issues": [
{
"issue_id": "issue_1",
"type": "delayed_delivery",
"order_id": "ORD-73821",
"amount": 129.47,
"currency": "USD",
"status": "delivered",
"customer_request": "full_refund",
"critical_dates": {
"promised_delivery": "2026-06-12",
"actual_delivery": "2026-06-18"
},
"open_questions": [
"Does delay policy apply after delivery?"
]
},
{
"issue_id": "issue_2",
"type": "missing_item",
"order_id": "ORD-81904",
"amount": 42.99,
"currency": "USD",
"status": "partially_delivered",
"customer_request": "replacement",
"open_questions": [
"Which item SKU is missing?"
]
}
]
}
Exam point:
In multi-issue sessions, persist each issue separately so order IDs, amounts, statuses, and customer expectations do not get merged or confused.
5. “Lost in the middle” effect
The “lost in the middle” effect means models may use information less reliably when it appears in the middle of a long input. The original TACL paper found that performance is often strongest when relevant information is at the beginning or end of the context and can degrade when relevant information is placed in the middle, even for long-context models. (ACL Anthology)
5.1 Bad aggregated input
[100 pages of search results]
[important finding buried on page 54]
[more tool logs]
Question: What are the key risks?
Risk:
5.2 Better aggregated input
<key_findings_summary>
1. Payment retry logic changed from idempotent to non-idempotent.
2. Order ORD-73821 has a 6-day delivery delay and a $129.47 refund request.
3. API response now includes status "requires_review", but frontend handling is missing.
</key_findings_summary>
<details>
<section id="payment_retry">
...
</section>
<section id="support_order_ORD-73821">
...
</section>
<section id="frontend_status_handling">
...
</section>
</details>
Exam answer pattern:
Put key findings at the beginning.
Use explicit section headers.
Keep detailed evidence organized below.
Repeat critical facts near the final task when appropriate.
6. Tool results can bloat context
Anthropic’s docs state that tool definitions and accumulated tool_result blocks consume the context window, and long-running agents with many tools or many turns can exhaust available context before the task is finished. Old tool_result blocks are a common context-bloat source, so trim or clear stale results once they have served their purpose. (Claude Platform)
6.1 Bad pattern: append full tool output
An order lookup returns 40+ fields:
{
"order_id": "ORD-73821",
"customer_id": "CUST-44391",
"status": "delivered",
"payment_status": "captured",
"shipping_status": "delivered",
"promised_delivery_date": "2026-06-12",
"actual_delivery_date": "2026-06-18",
"warehouse_id": "WH-92",
"carrier_internal_code": "CR-777",
"routing_zone": "Z-17",
"fraud_score": 0.12,
"coupon_campaign_id": "SUMMER26",
"internal_notes": "...",
"debug_fields": "...",
"many_more_fields": "..."
}
But the current task is refund eligibility.
6.2 Better: trim before adding to context
{
"order_id": "ORD-73821",
"order_total": 129.47,
"currency": "USD",
"status": "delivered",
"promised_delivery_date": "2026-06-12",
"actual_delivery_date": "2026-06-18",
"delay_days": 6,
"payment_status": "captured",
"refund_status": "not_requested"
}
Exam point:
Do not let verbose raw tool results accumulate when only a few fields are relevant.
7. Tool result trimming pattern
Use a relevance filter between tool output and conversation context.
def trim_order_for_refund_context(order: dict) -> dict:
return {
"order_id": order.get("order_id"),
"customer_id": order.get("customer_id"),
"order_total": order.get("total_amount"),
"currency": order.get("currency"),
"status": order.get("status"),
"payment_status": order.get("payment_status"),
"refund_status": order.get("refund_status"),
"promised_delivery_date": order.get("promised_delivery_date"),
"actual_delivery_date": order.get("actual_delivery_date"),
"delay_days": order.get("delay_days"),
"return_window_end": order.get("return_window_end")
}
Then pass:
<tool_result_summary tool="lookup_order" relevance="refund_eligibility">
{
"order_id": "ORD-73821",
"order_total": 129.47,
"currency": "USD",
"status": "delivered",
"delay_days": 6,
"payment_status": "captured",
"refund_status": "not_requested"
}
</tool_result_summary>
Do not pass:
all debug fields
internal routing fields
warehouse metadata
unrelated fulfillment details
large unfiltered JSON blobs
8. Complete conversation history still matters
You should not drop earlier turns blindly. The Messages API example in Anthropic’s docs shows multi-turn conversations by sending the earlier user and assistant messages in the messages array, and states that the full conversational history should be sent because the API is stateless. (Claude Platform)
The correct design is not:
That causes loss of conversational coherence.
The correct design is:
Send complete relevant conversation state:
- recent turns
- stable summary
- persistent case facts
- structured issue data
- trimmed relevant tool results
8.1 Bad API request
Problem:
Claude does not know which customer, order, amount, policy threshold, or prior commitment this refers to.
8.2 Better API request
{
"messages": [
{
"role": "user",
"content": "<case_facts>...</case_facts>\n<recent_history>...</recent_history>\nCustomer: Can you process the refund now?"
}
]
}
9. Context architecture for long support conversations
A robust prompt can look like this:
<system_task>
You are a support resolution agent. Use case facts as authoritative unless contradicted by newer verified tool results.
</system_task>
<case_facts>
- customer_id: CUST-44391
- verified_identity: true
- primary_order_id: ORD-73821
- primary_order_total: 129.47 USD
- promised_delivery_date: 2026-06-12
- actual_delivery_date: 2026-06-18
- delay_days: 6
- customer_request: full_refund
- customer_expectation: "Full refund if delivery was more than 5 days late"
</case_facts>
<open_issues>
[
{
"issue_id": "issue_1",
"order_id": "ORD-73821",
"type": "delayed_delivery_refund",
"status": "awaiting_policy_check"
}
]
</open_issues>
<recent_conversation_summary>
The customer asked for a full refund due to late delivery. The agent verified identity and looked up the order.
</recent_conversation_summary>
<trimmed_tool_results>
...
</trimmed_tool_results>
<current_user_message>
Can you process the refund now?
</current_user_message>
This avoids relying on a vague summary for exact values.
10. Organizing aggregated inputs
When aggregating many findings from subagents or tools, use a two-level structure:
<executive_summary>
Critical facts and findings first.
</executive_summary>
<finding_index>
- F1: Payment retry idempotency issue, severity important, source billing/retry.ts
- F2: Frontend missing status handling, severity important, source web/OrderStatus.tsx
- F3: Missing branch test, severity nit, source tests/orderStatus.test.tsx
</finding_index>
<detailed_findings>
<section id="F1">
...
</section>
<section id="F2">
...
</section>
<section id="F3">
...
</section>
</detailed_findings>
This mitigates position effects because the model sees the most important findings at the top while still having detailed evidence below.
11. Subagents should return metadata, not just prose
Subagents help with context management because they work in their own context and return a summary instead of flooding the main conversation with search results, logs, or file contents. Anthropic’s Claude Code docs say subagents run in their own context window and return results to the main agent, which is useful when a side task would otherwise flood the main conversation. (Claude)
But the summary must contain enough metadata for downstream synthesis.
11.1 Weak subagent output
Problems:
No file path.
No date/version.
No source location.
No method.
No confidence.
No relevance score.
No exact fact.
11.2 Strong subagent output
{
"finding_id": "F1",
"claim": "Payment retry changed from idempotent to non-idempotent.",
"severity": "important",
"source_locations": [
{
"file": "src/billing/retryPayment.ts",
"line_start": 42,
"line_end": 58
}
],
"method": "Compared old retry guard with new retry loop in current diff.",
"evidence": "New retry loop calls capturePayment() without idempotency key reuse.",
"relevance_score": 0.94,
"confidence": "high",
"date_observed": "2026-06-29"
}
Exam point:
Subagents should return structured facts with metadata, not verbose reasoning chains.
12. Upstream agents should optimize for downstream context budgets
If downstream synthesis has limited context, upstream agents should not return raw logs, full files, or long reasoning traces.
Bad upstream output:
Better upstream output:
{
"key_facts": [
{
"fact": "Order ORD-73821 was delivered 6 days after promised date.",
"source": "lookup_order",
"fields_used": [
"promised_delivery_date",
"actual_delivery_date"
],
"relevance_score": 0.98
}
],
"citations": [
{
"source_id": "lookup_order:ORD-73821",
"field": "actual_delivery_date",
"value": "2026-06-18"
}
],
"open_questions": [
"Does late-delivery refund policy apply after completed delivery?"
]
}
Claude Code workflow docs make a similar architectural distinction: when Claude orchestrates agents directly, every result lands in a context window; scripted workflows can keep branching and intermediate results in script variables so Claude’s context holds only the final answer. (Claude)
13. Progressive summarization done safely
Use summaries, but do not let them replace structured facts.
13.1 Unsafe compaction
13.2 Safe compaction
<summary>
Customer contacted support about order ORD-73821, which was delivered late. They requested a full refund and referenced a 5-day lateness expectation.
</summary>
<preserved_facts>
- order_id: ORD-73821
- order_total: 129.47 USD
- promised_delivery_date: 2026-06-12
- actual_delivery_date: 2026-06-18
- delay_days: 6
- requested_resolution: full_refund
- customer_stated_threshold: more_than_5_days_late
</preserved_facts>
Exam phrasing:
Summarize narrative history, but extract exact transactional facts into a persistent structured block.
14. Compaction
Compaction means summarizing older context so a long conversation can continue: when the history grows large, earlier turns are replaced with a condensed summary, freeing space while preserving the gist. It is the in-scope strategy for long-running sessions that would otherwise exhaust the context window before the task finishes.
Compaction does not replace disciplined context design: preserve critical facts separately (in a case_facts block or structured issue layer) so summarization does not lose exact numbers, dates, IDs, and user commitments.
For interactive Claude Code sessions, the /compact command applies this idea to extended codebase-exploration sessions — see D5.4.
15. Decision table
| Scenario | Best context strategy |
|---|---|
| Customer gives refund amount and deadline | Add to persistent case_facts |
| Multiple orders discussed | Add structured issues[] layer |
| Tool returns 40 fields but only 5 matter | Trim tool result before adding to context |
| Aggregating 30 subagent findings | Put key findings summary at top, details below |
| Important fact buried in middle of long input | Repeat in top summary and relevant section |
| Subagent returns vague prose | Require structured metadata: source, date, method, relevance |
| Long conversation nearing context limit | Summarize narrative, preserve exact facts separately |
| API follow-up loses context | Ensure full relevant history/state is sent each request |
| Downstream synthesis has limited context | Upstream agents return key facts/citations, not logs |
16. Common exam traps
Trap 1: Vague summaries for exact facts
Wrong:
Right:
Trap 2: Dropping earlier history entirely
Wrong:
Right:
Trap 3: Raw tool output accumulation
Wrong:
Right:
Trap 4: Important information buried in the middle
Wrong:
Right:
Trap 5: Subagents return prose only
Wrong:
Right:
Return structured finding with source locations, dates, method, evidence, confidence, and relevance score.
Trap 6: Upstream agents return reasoning chains
Wrong:
Right:
17. Scenario-based practice questions
Question 1
A support agent summarizes a long conversation as:
Later, it forgets the exact order amount and promised delivery date.
What is the best fix?
A) Make the summary longer but still prose-only.
B) Extract exact transactional facts into a persistent case_facts block included in each prompt.
C) Drop older conversation turns.
D) Ask the model to remember better.
Answer
B. Critical facts like amounts, dates, order IDs, and customer expectations should be preserved in structured form outside vague summaries.
Question 2
A customer discusses three separate orders. The agent later confuses which order had the missing item and which had the delayed delivery.
What should the system maintain?
A) One prose paragraph summarizing all issues.
B) A structured issues[] layer with order IDs, issue types, amounts, statuses, and open questions.
C) Only the latest user message.
D) Full raw tool output for every order.
Answer
B. Multi-issue sessions need structured issue data so facts from different issues do not merge.
Question 3
An order lookup tool returns 40 fields, but the current task only needs refund eligibility.
What should the agent do before appending the tool result to context?
A) Append all 40 fields.
B) Trim the tool result to refund-relevant fields.
C) Drop the tool result entirely.
D) Convert the result into a vague summary.
Answer
B. Verbose tool outputs consume context disproportionately. Keep only task-relevant fields.
Question 4
A synthesis prompt contains 50 pages of detailed findings. The most important finding is buried in the middle and omitted from the final answer.
What would best mitigate this?
A) Put key findings at the beginning and organize details under explicit section headers.
B) Add more raw logs.
C) Remove section headers.
D) Put all findings in random order.
Answer
A. Placing key findings early and using clear sections reduces position-related omission risk.
Question 5
Which statement best describes the “lost in the middle” effect?
A) Models cannot process long contexts at all.
B) Models may use information less reliably when it appears in the middle of long inputs than at the beginning or end.
C) Models only read the final sentence.
D) Models ignore all summaries.
Answer
B. Research found that relevant information placed in the middle of long contexts can be used less reliably than information at the beginning or end. (ACL Anthology)
Question 6
A developer sends only the latest user message in each API call and expects Claude to remember earlier turns.
What is wrong?
A) Nothing; the API stores all prior state automatically.
B) The Messages API is stateless, so the application must send the full relevant conversational history/state.
C) Claude cannot do multi-turn conversations.
D) Tool use is impossible.
Answer
B. The application must provide the conversation history or equivalent context because the Messages API is stateless. (Claude Platform)
Question 7
A subagent returns:
Downstream synthesis cannot verify the claim.
What should the subagent return instead?
A) More vague prose.
B) Structured metadata: affected files, source locations, evidence, method, confidence, and relevance score.
C) Only its reasoning chain.
D) No output.
Answer
B. Downstream agents need structured, source-grounded facts, not vague claims.
Question 8
A long-running agent accumulates many old file search results and tool outputs that are no longer relevant.
What is the best strategy?
A) Keep all old tool outputs forever.
B) Remove or trim stale tool results while preserving critical extracted facts.
C) Delete all case facts.
D) Stop sending any history.
Answer
B. Old tool results can consume context after they have served their purpose; preserve critical facts separately and remove stale bulk content where appropriate. (Claude Platform)
Question 9
An upstream research agent has a limited downstream context budget. What should it return?
A) Full raw logs and every file it read.
B) Key facts, citations/source locations, relevance scores, confidence, and open questions.
C) Only “done.”
D) All intermediate reasoning.
Answer
B. Upstream agents should optimize for downstream synthesis by returning compact, structured, source-grounded data.
Question 10
A progressive summary says:
The original message said:
What went wrong?
A) The summary preserved all critical information.
B) The summary collapsed a percentage, condition, and date into vague language.
C) The model cannot summarize.
D) The user should not mention dates.
Answer
B. Progressive summarization can lose numerical values, thresholds, conditions, and dates unless they are preserved separately.
19. Final D5.1 checklist
Memorize this:
1. Do not rely on vague summaries for transactional facts.
2. Preserve amounts, dates, percentages, IDs, statuses, and expectations exactly.
3. Use a persistent case_facts block.
4. Use structured issue data for multi-issue sessions.
5. Trim verbose tool outputs before they accumulate.
6. Keep only task-relevant tool fields.
7. The Messages API is stateless; send full relevant history/state each request.
8. Lost-in-the-middle means middle-positioned information may be missed.
9. Put key findings summaries at the beginning of long aggregated inputs.
10. Use explicit section headers for detailed evidence.
11. Subagents should return metadata, not vague prose.
12. Require source locations, dates, method, evidence, confidence, and relevance scores.
13. Upstream agents should return key facts and citations, not raw reasoning chains.
14. Summarize narrative history, but preserve exact facts separately.
15. Remove stale bulk context only after extracting durable facts.
D5.1 mental model
Summaries preserve story.
Case facts preserve truth.
Structured issues prevent mixing.
Trimmed tool results preserve context budget.
Front-loaded findings fight position effects.
Metadata-rich subagent outputs support downstream synthesis.
The exam’s favorite distinction is:
Do not summarize away exact values. Extract critical facts into persistent structured context, trim irrelevant tool output, and organize long inputs so key findings are visible early.