Context Management

Context Management is 15% of the CCAR-F blueprint — roughly 9 of the 60 official-simulation questions — and the smallest single domain. It is tempting to under-prepare it for that reason. Do not. This is the domain that most directly determines whether a Claude-powered agent stays reliable past the first few minutes of use, and the exam writes its distractors accordingly: most of the wrong answers in this section are things that look efficient but quietly destroy state.

The domain covers the input budget (the context window), what prompt caching actually does, how to compress a long history without throwing away the parts you will later need, when a scratchpad or structured summary is the right answer, and — critically — what to do when the agent runs out of policy guidance mid-conversation. The last point is more reliability than context, but the exam blueprint groups them together because both are about an agent staying truthful and useful across long sessions.

If you only remember three things walking into the exam: the context window is the input budget and max_tokens is the output cap; structured summarisation beats truncation; and when policy is silent, escalate to a human rather than letting Claude infer. Most of the 9 questions in this domain reduce to one of those three rules.

What the exam actually tests

• Context window vs. max_tokens — input budget vs. output cap (commonly confused)
• Prompt caching: what gets cached, when it helps, when it doesn't
• Structured summarisation / scratchpad patterns for long conversations
• Token optimisation without losing early critical context
• When to escalate to a human because policy guidance is missing
• Reliability and behaviour drift across long agent sessions

Context window vs. max_tokens

These two parameters are confused in roughly half the wrong answers in this domain. The context window is the total input budget — the maximum number of tokens the model can read in a single request, including the system prompt, conversation history, tool definitions, tool results, and the current user message. max_tokens is a separate, much smaller cap on the model's output for that one response. Raising max_tokens does not extend the context window; it only lets Claude write a longer reply. If a conversation is bumping up against the input limit, max_tokens is irrelevant. The fix lives on the input side: prune, summarise, or extract structured state. Any exam option that proposes 'increase max_tokens to fit more history' is wrong by construction.

Prompt caching — what it actually does

Prompt caching reduces cost and latency by reusing previously computed prefix tokens. It is most effective when a large, stable prefix — a system prompt, a policy document, a tool schema, a long set of examples — is sent on every request and only the tail varies. It does not extend the context window, it does not summarise anything, and it does not help when the prefix changes every turn. A long, churning conversation history is exactly the case where caching does not save you. If the exam asks 'how do I handle a 200-turn customer-support session?', prompt caching is not the answer; structured summarisation is. Use caching to cheapen repeated stable prefixes, not to rescue a context-window problem.

Structured summarisation and the scratchpad pattern

The correct way to extend a long conversation is not to truncate the last N turns — that throws away the original problem statement, the customer's name, the decisions you have already committed to, and anything else that lives early in the history. The correct pattern is to extract the durable facts (who the customer is, what they want, what you have tried, what has been promised, what is still open) into a compact structured summary, and use that summary as the standing context for subsequent turns. This is often called a scratchpad: a small, authoritative state object that survives turn-by-turn pruning. It costs you a summarisation step but it preserves the early context that naive recency-based truncation destroys.

Escalation when policy guidance is missing

Reliability across long sessions is partly about token budgets and partly about the agent knowing the edge of its authority. When the agent hits a scenario the policy does not cover — a fraud-flagged account, an undefined refund category, a regulated decision — the correct behaviour is to escalate to a human and hand over the context it has already gathered. It is not to invent a policy, infer one from similar cases, lie about the system being down, or proceed on vibes. The exam tests this directly: any option that has Claude 'reason about what the policy probably is' for a sensitive decision is wrong. Escalation is the safe default whenever the agent cannot cite an authoritative rule.

Reliability across long sessions

Long agent sessions degrade in predictable ways: the model loses track of early instructions, contradicts itself, repeats already-completed tool calls, or hallucinates facts that were never in the input. Most of these failures trace back to context hygiene — a bloated history, a summary that dropped a key fact, a missing scratchpad, or no termination condition on a loop that keeps adding turns. The fix is upstream: a deliberate summarisation strategy, a structured state object the agent re-reads each turn, and explicit policy for what to do when the agent is uncertain (almost always: stop and escalate). Reliability is a context-management problem before it is a model-quality problem.

Where candidates go wrong

How to study this domain

Treat every Context Management question as either an input-budget question, a state-preservation question, or an escalation question. Read the scenario, decide which of the three it is, and then evaluate options against that lens. Input-budget questions: anything mentioning max_tokens as a fix for history length is wrong. State-preservation questions: anything that drops early turns is wrong; structured summary is the answer. Escalation questions: any option that has Claude invent or infer policy for a sensitive decision is wrong.

Memorise the exact distinction between context window (input budget, fixed by the model) and max_tokens (output cap, set per request). Memorise what prompt caching does (cheapens repeated stable prefixes) and what it does not do (extend the window, summarise history). Practice 15–20 questions in this domain; that is enough given the weight. Spend the time you save on Agentic Architecture, which carries nearly twice as many questions.

Common questions