What You Need to Know
The context window is everything Claude reads on one request: instructions, the conversation so far, tool results and documents. Context window management means choosing what to put in the context window. Multi-turn conversations, multi-agent pipelines and long-document extraction all depend on context window management. Any reliable Claude-based system also depends on it. When context window management fails, support agents forget refund amounts, research pipelines drop citations, and extraction systems lose precision on the fields that matter most.
This lesson uses one made-up example throughout: a travel agency that runs its booking assistant on Claude. Over a long session, a customer gives a deposit amount, departure dates, a booking reference and the hotel's promise of a sea view. Three research subagents check flights, hotels and transfers for a synthesis agent, which combines their results.
The Progressive Summarisation Trap
Progressive summarisation is a common strategy in long conversations. It replaces earlier turns with a shorter summary to free token budget. Progressive summarisation systematically destroys the most critical information in customer-facing and data-processing systems: numerical values, dates, percentages and customer-stated expectations. By default, a summary of transactional data keeps the general meaning and drops the specific details.
Consider turn 3 of a refund conversation.
Turn 3: "I'd like a refund of $247.83 for order #8891 placed on March 3rd"
After summarisation, the turn becomes this summary.
Summary: "Customer wants a refund for a recent order"
The summary has lost the amount, the order number and the date. The agent needs all three to process the refund. A summary of the agency's session would also lose the deposit, dates, reference and sea view.
The fix is a persistent case facts block. Extract transactional facts (amounts, dates, order numbers, statuses) into a structured block included in every prompt, outside the summarised history. The block is never summarised, so it persists across every turn whatever happens to the history. For the agency, the block would hold the deposit, dates, reference and status. This example shows the structure of the block.
{
"caseFactsBlock": {
"customerId": "C-4421",
"issues": [
{
"orderId": "#8891",
"orderDate": "2024-03-03",
"refundAmount": "$247.83",
"status": "pending_refund",
"itemDescription": "Wireless headphones — defective"
}
]
}
}When a customer raises several problems in one session, extract and persist structured issue data into a separate context layer, a part of the prompt kept apart from the summarised history. Each issue gets its own entry with order IDs, amounts and statuses. Separate entries prevent the data of one issue from mixing with the data of another issue during summarisation. A second agency booking with a misspelt name gets its own entry.
The "Lost in the Middle" Effect
Models process information at the beginning and end of long inputs reliably. A model may miss findings in the middle of a long context, or may give them less weight. This effect is well documented in large language models. It guides how you structure aggregated inputs, which combine results from several sources.
The fix is a change to the structure of the input, not an instruction in the prompt. Put a summary of the main findings at the start of the aggregated input. Put the detailed results under explicit section headers. A reminder to read everything leaves each finding in the same position. The agency's synthesis agent should get a "Key Findings Summary" first, then each supplier report under its own header. This layout shows the pattern.
## Key Findings Summary - Source A: 12% market growth in renewable sector (2023) - Source B: Patent filings increased 34% year-on-year - Source C: Regulatory framework delayed until Q3 2025 ## Detailed Findings ### Source A: Market Analysis Report [Full details here...] ### Source B: Patent Database Analysis [Full details here...] ### Source C: Regulatory Review [Full details here...]
Tool Result Trimming
Tool results use context budget unnoticed. An order lookup might return 40+ fields, such as internal audit timestamps, warehouse codes, shipping carrier IDs and fulfilment centre identifiers. Most of these fields are irrelevant to a refund request. You need 5. The other 35 consume tokens in every subsequent turn as the history grows. The agency's booking lookup has the same problem.
Trim verbose tool outputs to only the relevant fields before they accumulate in context. Trimming is required. Otherwise, output that is no longer needed accumulates turn after turn. This function keeps the relevant fields for a refund workflow.
def trim_order_result(raw_result, relevant_fields=None):
if relevant_fields is None:
relevant_fields = [
"order_id", "order_date", "total_amount",
"return_eligible", "item_description"
]
return {k: v for k, v in raw_result.items() if k in relevant_fields}Trim the result in a PostToolUse hook or in the tool implementation itself, before the result enters the conversation history. Once verbose data is in the context, it stays there for every subsequent turn.
Full Conversation History
The Claude API is stateless. There is no server-side session state, so each request must include the complete conversation history. When you omit earlier messages, the model loses conversational coherence. The agency's assistant resends the whole planning session each time.
This need for the full history conflicts with context limits. Coherence needs the full history, and the history grows every turn. The persistent case facts block resolves this conflict. It separates critical facts from the rest of the conversation, which can be summarised. So the agency can summarise the planning and keep every transactional detail.
Upstream Agent Optimisation
In multi-agent systems, upstream agents often return verbose reasoning chains and raw content that downstream agents do not need. Suppose a synthesis agent with a limited context budget receives the full thought process of a research subagent. The synthesis agent then wastes tokens on reasoning that it cannot use.
Modify upstream agents to return structured data (main facts, citations, relevance scores) instead. Require metadata such as dates, source locations and methodological context in those outputs, to support accurate downstream synthesis. The agency's hotel subagent returns findings with source and date, without its search steps.
{
"findings": [
{
"claim": "Renewable energy investment grew 12% in 2023",
"source": "IEA World Energy Report 2024",
"sourceUrl": "https://example.com/report",
"relevanceScore": 0.92,
"publicationDate": "2024-01-15"
}
]
}Structured outputs also let downstream agents process findings without re-parsing verbose prose.
Key Concept
The persistent case facts block is the single most important pattern in context window management. Its transactional facts appear in every prompt and are never summarised. It stops progressive summarisation from losing these facts and supports reliable multi-turn systems.
Prompt Caching
Prompt caching is the other way to control the cost of context. Trimming changes what the model sees. Caching instead lets you avoid paying to reprocess the parts that do not change. Mark a stable prefix (the start of the prompt that does not change) with a cache_control breakpoint. The API stores the processed prefix and reuses it on the next request. For cached tokens, the API charges a fraction of the input cost.
The cache matches the prompt from its start, prefix by prefix. So the layout of the prompt decides whether you get a cache hit, which is a match with a stored prefix. Put constant content first: system instructions, tool definitions, long reference documents. Place the cache_control breakpoint at the end of that static block. Put volatile content after it: the user's latest message and anything that changes per request. The agency puts instructions, tools and booking terms first and the customer's newest message last.
Put the static block in the top-level system parameter, not in messages. The cache reads the prompt in the order tools, system, messages. So the instructions in system are ahead of every turn that changes.
response = client.messages.create(
model="claude-sonnet-5-5",
max_tokens=4096,
system=[
{"type": "text", "text": LONG_STATIC_INSTRUCTIONS},
{"type": "text", "text": REFERENCE_DOC,
"cache_control": {"type": "ephemeral"}},
],
messages=[
{"role": "user", "content": dynamic_user_message},
],
)If dynamic content is before the static block, the prefix changes on every request. Nothing matches, and you pay full price for every call. An ephemeral breakpoint lasts about five minutes from its last use. A {"type": "ephemeral", "ttl": "1h"} breakpoint lasts an hour, and its write cost (the price of storing the prefix in the cache) is higher. A request may contain at most four breakpoints.
In the exam
A typical exam question describes an agent that loses amounts or dates after summarisation. The right fix is the persistent case facts block. Traps include telling the model to attend to everything and keeping full tool results as a precaution. Selective truncation is another trap, because the stateless API needs the whole history.
Scope
The guide's out-of-scope list excludes "prompt caching implementation details (beyond knowing it exists)", so nothing beyond the existence and purpose of caching is tested. The mechanics above are for real work.
Exam Traps
Thinking progressive summarisation is safe for transactional data
Summarisation systematically destroys numerical values, dates, and specific identifiers. A persistent case facts block must hold these outside summarised history.
Assuming the 'lost in the middle' effect is solved by telling the model to pay attention to everything
The fix is structural: place key findings at the beginning of inputs and use explicit section headers. Prompt-based reminders are unreliable for effects caused by where information sits in the input.
Keeping full tool results in context because 'the model might need them later'
Untrimmed tool results from 40+ field lookups exhaust the token budget across turns. Trim to relevant fields before results enter the conversation history.
Selectively truncating conversation history on the assumption that nothing is lost
The API is stateless, so the exam guide stresses passing complete conversation history in each request to keep coherence. Current docs (October 2026) add context editing, which clears chosen content deliberately. Dropping messages without a plan loses facts; use case facts blocks and summarisation.
Practice Scenario
A customer support agent handles a multi-issue session. After several turns, the agent refers to 'your recent refund request' instead of the specific $247.83 refund for order #8891. The conversation history is being summarised between turns to manage context length, and some sessions run longer than any context window could hold. The agent cannot tell in advance which earlier detail a turn will need. The summariser has already been told to keep every figure verbatim, yet the $247.83 was still lost. What is the most effective fix?
Build Exercise
Build a Persistent Case Facts Context Manager
What you'll learn
- Implement the persistent case facts block pattern to protect transactional data from summarisation
- Trim verbose tool results to relevant fields before they accumulate in context
- Recognise and mitigate how progressive summarisation loses numerical values, dates, and identifiers
- Apply the lost-in-the-middle mitigation by placing key findings at the beginning of aggregated inputs
- Understand that the Claude API is stateless and each request must include complete conversation history
- Create a case facts extractor that identifies transactional data (amounts, dates, order numbers, statuses) from tool results
Why: The persistent case facts block is the single most important pattern in context window management. Extracting transactional facts into a structured block that is never summarised prevents progressive summarisation from destroying critical numerical values and identifiers.
You should see: A function that takes raw tool output and returns a structured object containing only the transactional facts: customer ID, order numbers, amounts, dates, and statuses. Non-transactional narrative content should be excluded.
- Implement a persistent case facts block that is prepended to every prompt, outside summarised history
Why: The case facts block must persist across every turn regardless of what happens to the conversation history. It sits outside the summarised portion of the context, ensuring amounts, dates, and order numbers survive even when earlier conversation turns are compressed.
You should see: A prompt construction function that always includes the case facts block at the top of every message, followed by any summarised history, followed by the current turn. The case facts block should be clearly delimited with a section header.
- Build a tool result trimmer that filters order lookup responses from 40+ fields to only the 5 relevant return-related fields
Why: Untrimmed tool results consume the context budget without anyone noticing. An order lookup returning 40+ fields consumes tokens in every subsequent turn as conversation history grows. Trimming to relevant fields before results enter context is essential, not optional.
You should see: A trimming function that takes a raw tool result object and returns only the fields needed for the current task. The trimmed result should be 80-90% smaller than the original.
- Test with a multi-turn conversation where summarisation occurs and verify that transactional facts survive intact across all turns
Why: This validates that the persistent case facts pattern actually works. The exam tests whether you understand that progressive summarisation destroys specific amounts and dates, and the case facts block is the fix. You need to verify this empirically.
You should see: A 6-8 turn conversation where summarisation occurs after turn 4. After summarisation, the agent should still reference the exact refund amount ($247.83), order number (#8891), and date (March 3rd) from the case facts block. Without the block, these values would be lost to summarisation.
- Add key findings placement logic that positions summaries at the beginning of aggregated inputs to mitigate the lost-in-the-middle effect
Why: Models process information at the beginning and end of long inputs reliably, but findings buried in the middle may be missed. Placing key findings summaries at the start of aggregated inputs is a structural fix for this well-documented phenomenon.
You should see: An aggregation function that places a Key Findings Summary section at the top of combined inputs, followed by detailed results with explicit section headers. The key findings should be concise bullet points drawn from the detailed content.
Sources
- Claude Certified Architect Foundations Exam Guide — Domain 5, Task Statement 5.1 — Anthropic
- Anthropic API Documentation — Messages — Anthropic
- Prompt caching — Claude Docs, the prompt order the cache reads
- Anthropic Prompt Engineering — Long Context Tips — Anthropic
- CCAR-F Exam Guide v1.0: Task Statement 5.1 — Anthropic