5.1 Context Window Management

What You Need to Know

Context window management is the foundation of reliable Claude-based systems. Every multi-turn conversation, every multi-agent pipeline, every long-document extraction task depends on what you let into the context window. Get it wrong and the failures are concrete: your support agent forgets refund amounts, your research pipeline drops citations, your extraction system loses precision on the fields that matter most.

The Progressive Summarisation Trap

When conversations grow long, a common strategy is to summarise earlier turns to free up token budget. This is a trap. Progressive summarisation systematically destroys the most critical information in customer-facing and data-processing systems: numerical values, dates, percentages, and customer-stated expectations.

Here is how it plays out. A customer contacts support about a refund:

Turn 3: "I'd like a refund of $247.83 for order #8891 placed on March 3rd"

After summarisation, this becomes:

Summary: "Customer wants a refund for a recent order"

The amount, order number, and date — the three facts the agent needs to process the refund — are gone. And that is not a fringe case. It is what summarisation does to transactional data by default.

The fix: persistent case facts blocks. Extract transactional facts (amounts, dates, order numbers, statuses) into a structured block that is included in every prompt, outside the summarised history. This block is never summarised. It persists across every turn regardless of what happens to the conversation history.

{
  "caseFactsBlock": {
    "customerId": "C-4421",
    "issues": [
      {
        "orderId": "#8891",
        "orderDate": "2024-03-03",
        "refundAmount": "$247.83",
        "status": "pending_refund",
        "itemDescription": "Wireless headphones — defective"
      }
    ]
  }
}

For multi-issue sessions where a customer raises several problems in one conversation, extract and persist structured issue data into a separate context layer. Each issue gets its own entry with order IDs, amounts, and statuses. This prevents cross-contamination between issues during summarisation.

The “Lost in the Middle” Effect

Models process information at the beginning and end of long inputs reliably. Findings buried in the middle of a long context may be missed or given less weight. This is a well-documented phenomenon in large language models and it directly affects how you structure aggregated inputs.

The fix is structural, not prompt-based. Place key findings summaries at the beginning of aggregated inputs. Organise detailed results with explicit section headers throughout. If you are feeding a synthesis agent the output of three research subagents, start with a “Key Findings Summary” section, then provide the detailed outputs with clear section boundaries.

## 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 are a silent context budget killer. An order lookup might return 40+ fields: internal audit timestamps, warehouse codes, shipping carrier IDs, fulfilment centre identifiers, and dozens of other fields irrelevant to the customer’s refund request. You need 5 fields. Those other 35 fields consume tokens in every subsequent turn as the conversation history grows.

Trim verbose tool outputs to only relevant fields before they accumulate in context. Skip it and multi-turn systems slowly drown in stale tool output. It is not a nice-to-have.

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}

This trimming should happen 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. Each request must include the complete conversation history. Omit earlier messages and the model loses conversational coherence. There’s no session state on the server side, so every turn has to carry everything the model needs to follow the conversation.

This creates a tension with context limits: you need the full history for coherence, but the history grows with every turn. The persistent case facts block resolves this by separating critical facts from summarisable narrative, letting you summarise the conversation flow while preserving 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. When a research subagent sends its full thought process to a synthesis agent with a limited context budget, the synthesis agent wastes tokens on reasoning it cannot use.

Modify upstream agents to return structured data — key facts, citations, relevance scores — instead of verbose content and reasoning chains. Require subagents to include metadata (dates, source locations, methodological context) in structured outputs to support accurate downstream synthesis.

{
  "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"
    }
  ]
}

Tokens aren’t the only win here. Structured outputs from upstream agents let downstream agents process findings without re-parsing verbose prose.

Prompt Caching

Prompt caching is the other half of context economics. Instead of trimming what the model sees, you avoid paying to reprocess the parts that don’t change. Mark a stable prefix with a cache_control breakpoint and the API stores that processed prefix, then reuses it on the next request, charging a fraction of the input cost for the cached tokens.

Caching matches from the start of the prompt, prefix by prefix, so layout decides whether you get a hit. Put the content that stays constant first: system instructions, tool definitions, long reference documents. Place the cache_control breakpoint at the end of that static block. Put the volatile content, the user’s latest message and anything that changes per request, after the breakpoint.

The static block belongs in the top-level system parameter, not in messages. There is no "system" role for input messages in the Messages API — messages takes "user" and "assistant" turns only.

response = client.messages.create(
    model="claude-sonnet-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},
    ],
)

Get the order wrong and you lose the benefit entirely. If dynamic content sits before the static block, the prefix changes on every request, nothing matches, and every call pays full price. An ephemeral breakpoint lasts about five minutes since last use; a {"type": "ephemeral", "ttl": "1h"} breakpoint lasts an hour at a higher write cost. A request may carry at most four breakpoints.

Exam Traps

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. What is the most effective fix?

A. Increase the context window size so the full conversation history fits and summarisation never needs to run
B. Store the full conversation history in an external database and retrieve the relevant turns on demand whenever the agent needs to recall an earlier detail
C. Instruct the model to preserve all numerical values verbatim whenever it summarises the conversation history
D. Extract transactional facts (amounts, dates, order numbers) into a persistent case facts block included in every prompt, outside summarised history

Answer & explanation

Correct: D

A — This postpones the problem but does not solve it — eventually the context will fill, and summarisation will still destroy specifics.
B — This adds infrastructure complexity without addressing the core issue of which facts must persist in every prompt.
C — Prompt-based instructions for summarisation are unreliable — the model will still compress details probabilistically.
D — This directly addresses the progressive summarisation trap by ensuring critical numerical and transactional data is never condensed.

Sources

Claude Certified Architect Foundations Exam Guide — Domain 5, Task Statement 5.1 — Anthropic
Anthropic API Documentation — Messages — Anthropic
Anthropic Prompt Engineering — Long Context Tips — Anthropic

Exam Simulator

Five exam-style multiple-choice questions on Context Window Management. Pick an answer, then open the explanation.

Question 1

A. Increase the context window size to avoid summarisation entirely
B. Instruct the model to preserve all numerical values during summarisation
C. Keep a case facts block outside the summarised history itself
D. Store the full conversation in an external database and retrieve relevant turns on demand

Answer & explanation

Correct: C

A is wrong: Increasing the context window postpones the problem. Eventually it fills, and summarisation still destroys specifics.
B is wrong: Prompt-based instructions for summarisation are unreliable. The model will still compress details probabilistically.
C is correct: The persistent case facts block directly addresses the progressive summarisation trap by ensuring critical numerical and transactional data is never condensed.
D is wrong: This adds infrastructure complexity without addressing the core issue of which facts must persist in every prompt.

Question 2

A research synthesis agent combines output from three subagents into a final report. Critical findings from the second subagent are consistently omitted from the synthesis. All three subagents produce high-quality outputs. Where should you look first?

A. The position of the second subagent’s output in the aggregated input — it may be buried in the middle
B. The synthesis agent’s context window — it may be running out of tokens
C. The second subagent’s prompt — it may not be formatting outputs correctly
D. The synthesis agent’s temperature setting — it may be too creative and ignoring details

Answer & explanation

Correct: A

A is correct: The lost-in-the-middle effect means models may miss findings buried in the middle of long inputs. Place key findings summaries at the beginning.
B is wrong: The issue is position-based attention, not context capacity.
C is wrong: The question states all three subagents produce high-quality outputs, so the formatting is not the issue.
D is wrong: Temperature affects randomness, not positional attention biases.

Question 3

An order lookup tool returns 42 fields per result. The support agent only needs 5 fields to process a refund. After 8 turns, the agent’s responses become slower and less accurate. What is the root cause?

A. The model is hitting its maximum output token limit
B. The model needs a higher temperature to maintain creativity in long conversations
C. The order lookup tool is returning stale data after multiple calls
D. Untrimmed tool results are consuming the whole context budget

Answer & explanation

Correct: D

A is wrong: Output token limits affect generation length, not comprehension. The issue is input context consumption.
B is wrong: Temperature does not address context budget consumption.
C is wrong: Data staleness would cause incorrect information, not slower and less accurate responses across all topics.
D is correct: Each untrimmed 42-field result stays in the conversation history. Over 8 turns, that is 336 fields (only 40 of which are relevant) consuming tokens.

Question 4

A developer builds a multi-turn support agent. They include only the last 3 messages in each API request to save tokens. Users report the agent ‘forgets’ context from earlier in the conversation. Why?

A. The model’s attention mechanism cannot handle conversations longer than 3 turns
B. The Claude API is stateless, so every request must carry the full history
C. The system prompt needs to instruct the model to remember earlier turns
D. The developer should use a different model with better long-term memory

Answer & explanation

Correct: B

A is wrong: The model can handle long conversations. The issue is that earlier messages are not being sent.
B is correct: The API is stateless. There is no server-side session state. Omitting earlier messages means the model literally does not have access to them.
C is wrong: The model cannot remember messages it was not given. Prompt instructions cannot recover missing context.
D is wrong: All API-based models are stateless. The issue is the developer’s truncation approach, not the model.

Question 5

A multi-agent research pipeline has upstream research agents feeding findings to a downstream synthesis agent. The synthesis agent produces vague summaries without specific figures or citations. The research agents produce detailed, accurate outputs. What should you change?

A. Have upstream agents return structured data instead of verbose reasoning chains
B. Reduce the number of upstream agents so the synthesis agent has less input to process
C. Give the synthesis agent a larger context window to accommodate all research output
D. Add a summarisation step between research and synthesis to compress the research output

Answer & explanation

Correct: A

A is correct: Upstream agent optimisation ensures downstream agents receive structured, relevant data instead of verbose reasoning chains that waste context budget.
B is wrong: Reducing agents reduces research coverage. The issue is output format, not volume.
C is wrong: More context space does not help if the input is verbose reasoning chains that bury the key facts.
D is wrong: Adding summarisation would likely destroy the specific figures and citations, making the problem worse.