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
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?"
]
}
]
}
Heuristic:
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. 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"
}
Heuristic:
Do not let verbose raw tool results accumulate when only a few fields are relevant.
Do not pass:
all debug fields
internal routing fields
warehouse metadata
unrelated fulfillment details
large unfiltered JSON blobs
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: