CCAR-F · module 5 of 5 · 15% of the exam

Context management and reliability

Weight: 15 percent of the exam. Tests whether you can keep an agent's context relevant as work grows, hand information across boundaries without losing it, and design failure behaviour that degrades honestly instead of guessing.

What the exam expects

This is the smallest domain by weight and the one candidates most often underestimate, because its scenarios look like operational problems. They are architecture problems. An agent that forgets a decision it made forty turns ago, a subagent that contradicts a constraint the coordinator settled, an extraction service that invents a VAT number, a loop that retries the same doomed call one hundred and thirty times: all four are design defects with named fixes.

Two ideas run through everything here. Capacity and relevance are different problems: a larger context window gives you room, not the right content in that room, so most answers reaching for a bigger window are distractors. And reliability means being honest about failure: a system that cannot answer should say so and route to a human, because a plausible guess is worse than a loud failure when nobody downstream can tell the difference.

Budgeting the context window

Before optimizing, measure. A live breakdown by category tells you whether the cost is the system prompt, project instruction files, tool schemas, retrieved documents, or conversation history. A scenario saying "the team is not sure what is consuming the budget" is asking for measurement first, and an option that jumps straight to a fix is guessing even when the guess is reasonable.

The main levers:

• Defer tool schemas. Only tool names and server instructions load at startup and full schemas enter context on demand, so adding servers stays nearly free.
• Progressive disclosure for instructions. Keep always relevant rules in the project instruction file and move situational procedures (deployment runbooks, migration steps, onboarding guides) into skills whose short description sits in context and whose full body loads only when a task calls for it.
• Read narrowly. Search for a symbol and read the matching region rather than six whole files. Tokens never admitted cost nothing; tokens admitted and then summarized cost twice.
• Delegate bulky work. A subagent does its reads and searches in its own window and returns only its result.
• Clear between unrelated tasks. Old conversation both costs tokens on every message and actively pulls the agent toward the previous task.

Extended context windows of one million tokens exist on current models, and compaction works the same way at the larger limit. Treat the larger window as headroom, not as a substitute for the architecture.

Compaction and context editing

Two server side mechanisms manage a conversation that outgrows its window, and the exam expects you to choose between them.

Compaction specifics worth memorizing: the trigger is expressed in input tokens only, the default is 150,000 and the minimum supported value is 50,000. Custom instructions replace the default summarization prompt rather than supplementing it, which is the lever for saying "preserve order identifiers, commitments made, and stated deadlines." Because compaction adds a sampling iteration, total token consumption is the sum across iterations, not the top level figure.

Tool result clearing specifics: trigger (input tokens or tool uses), keep (how many recent tool use and result pairs survive), clear_at_least (a minimum per pass, which helps justify the cache invalidation cost), exclude_tools (results that must never be cleared), and clear_tool_inputs. exclude_tools is the answer whenever one result must stay resident, for example an authoritative schema fetched once at the start, while everything else is disposable. Raising keep does not protect the oldest result, since the oldest is exactly what gets cleared first.

Clearing pairs naturally with the memory tool: the model is warned before results are cleared, so it can write essential findings to persistent storage first and read them back later. That is the designed answer to "findings established early vanish from the final report."

Preserving information across handoffs

A subagent starts with a fresh, isolated context window. It does not see the parent conversation, the files already read, or the decisions already made. It works from the delegation message, and only its final result comes back. Everything else follows from those two facts, so a delegation message must:

• Restate settled constraints and decisions explicitly rather than referring to them. "Continue the analysis as discussed" refers to a discussion the subagent never had.
• Assign explicit, non overlapping scopes when subagents run in parallel, because isolated agents given vague instructions all converge on the most obvious starting point and duplicate each other.
• Specify the shape of the result. Since the result is the entire handoff, a defined structure (claim, evidence, source, confidence, open questions) lets the coordinator merge comparable records instead of reconciling inconsistent prose and silently dropping findings only one agent reported.

Two mechanics are easy to confuse. A fork inherits the whole conversation instead of starting fresh, which is right when a named subagent would need too much background to be useful. And a subagent's context window is sized by its own model, not the parent's, so routing work to a cheaper, smaller model also shrinks the room that work has to run in.

Escalation to a human is a handoff too, and needs the same contents: the goal, what was verified and ruled out with evidence, what was attempted and the outcome, and the reason for the transfer. Dumping the raw transcript is not a handoff, it delegates the summarization to the person receiving it, which in practice means they start over.

Retry, fail, and degrade

Retry decisions turn on one question: is this failure transient or deterministic?

Two refinements matter. A retry only helps if the next attempt has new information: resending an identical request is a blind resample, whereas returning the validator's specific errors gives the model something to correct. And any retried operation with outward side effects must be idempotent, through an idempotency key on a mutating tool or by keying a CI artifact to a stable identifier such as a commit SHA, or retries create duplicate refunds, orders, and pull requests.

Every agent loop needs a failure budget: a bounded number of attempts or a time limit, and a defined exit when it is exhausted, normally escalation carrying the accumulated context. Without one, a persistent failure becomes an unbounded hang, and monitoring alerts detect that rather than prevent it.

Graceful degradation means losing the capability that depended on the failed component while keeping everything else, and saying so plainly. When a policy knowledge base is down, tell the user that lookup is unavailable and route those questions to a human while continuing to serve unaffected requests. The three wrong shapes: answering from model memory (confidently stale), silently omitting what the failed tool would have contributed (indistinguishable from a complete answer), and taking the whole system offline (a partial outage turned total).

Hallucination prevention in extraction

This is the domain's sharpest single idea, and it appears in almost every sitting that includes the extraction scenario.

A required, non nullable field makes absence unrepresentable. If a schema demands a string for buyer_vat_number and the document has no VAT number, the model has no valid way to report that, so it produces a well formed, entirely invented value. The schema caused it. The fix is to make genuinely optional fields nullable ({"type": ["string", "null"]}) and to state in the prompt that null means the document does not contain the value.

Structured outputs guarantee shape, not truth. Constrained decoding guarantees valid JSON, correct types, and the presence of every required field, so parse errors and schema violations stop being a failure mode. It guarantees nothing about whether the value is right. A date read from the wrong column, a total transposed, a supplier name taken from an attachment's letterhead: all schema conformant and completely wrong. Business validation and human review of high risk fields survive the introduction of structured outputs.

Practical reliability measures for extraction:

• Capture the source span or location each value came from, so any extraction can be audited against the original document.
• Ask for a per field confidence assessment and route low confidence values to a human review queue.
• Narrow the input. Accuracy on fields buried late in a four hundred page filing is materially worse than near the front, so retrieve or chunk to the relevant sections and extract from targeted excerpts.
• Bound the validation retry loop and give it a human exit. Never auto adjust failing values to satisfy a validator, which manufactures clean looking wrong records.

How to think through the question

Step 1: classify the symptom. Domain 5 scenarios fall into five buckets, and naming the bucket eliminates most options immediately.

Step 2: ask what the question is really requesting. "What should they do FIRST" usually wants measurement or root cause identification, not the eventual remedy. "What is the root cause" wants the mechanism named, so a good fix in root cause clothing is wrong. "Which change most improves it" wants the single highest leverage action, so a genuinely useful but partial option can be a distractor.

Step 3: separate capacity from relevance. If an option adds room (bigger window, higher limit, more retained history) but the complaint is that the wrong content is present, that option is a distractor.

Step 4: prefer honest failure over plausible output. Between an option that produces an answer and one that declares the limitation and routes to a human, the exam favours the honest one whenever correctness is not assured.

Step 5: check the option against the stated constraint. Regulated reporting rules out unaudited automation. Unpredictable session length rules out a fixed truncation policy. A stated minimum (compaction's 50,000 token floor) rules out a value below it.

Worked example. A support agent uses server side compaction on long conversations. After compaction, agents lose track of the exact order numbers discussed, which remedies were already offered and refused, and the customer's stated deadline. Which change best addresses this?

Step 1: the symptom is information lost through a summarization boundary, so this is the compaction bucket. Step 2: "best addresses" wants the highest leverage single change. Step 3: disabling compaction removes the mechanism keeping long conversations viable, trading detail loss for outright session failure; lowering the trigger compacts more often, and each pass re-summarizes an already summarized history, so specifics degrade faster; adding the facts to the system prompt is impossible in the direction stated, since they arise during the conversation. Supplying custom compaction instructions naming what must survive (identifiers, remedies offered and their outcomes, commitments, deadlines) uses the designed lever, because custom instructions replace the default summarization prompt. Step 5 confirms nothing forbids it. That is the answer.

Exam traps

• "Move to a one million token window." Tempting because it removes the immediate limit. Wrong when the problem is relevance, and it adds cost and latency while leaving irrelevant content in the reasoning context.
• "Compact more aggressively." Wrong when it means repeated lossy summarization of already summarized history, and wrong outright below the 50,000 token trigger minimum.
• "Increase how many recent tool results are kept." Tempting because it sounds like preserving more. Wrong when the result you need is the oldest one, which is cleared first regardless; the lever is exclude_tools.
• "Pass the subagent a pointer to the parent session." Wrong because a fresh subagent has no path back into the parent conversation, so the pointer resolves to nothing. Restate, or use a fork.
• "Give the subagent all the parent's context." Tempting because it guarantees nothing is lost. Wrong because it discards the context isolation that motivated delegation.
• "Retry until it passes." Wrong for deterministic failures, wrong without new information in the retry, and dangerous without idempotency on anything with side effects.
• "Structured outputs mean we can stop validating." Tempting because the guarantee is real and strong. Wrong because it covers structure, not accuracy, and a well typed wrong number is the most dangerous output in a regulated pipeline.
• "Make every field required so downstream never sees a missing value." Tempting because it simplifies consuming code. Wrong because it is the direct cause of invented values.
• "An empty string is a fine default for a missing value." Tempting because it is falsy. Wrong because it cannot be distinguished from a field that really was blank in the source.
• "Take the system offline when a dependency fails." Wrong because it converts a partial outage into a total one and abandons users whose requests were unaffected.
• "Add an alert when the loop runs long." Wrong when the question asked for reliability: an alert detects an unbounded loop, a failure budget ends one.

Quick reference

• Measure the context breakdown before optimizing it. Capacity is not relevance.
• Compaction: automatic summarization for long or unpredictable sessions. Trigger in input tokens only, default 150,000, minimum 50,000. Custom instructions replace the default prompt. Costs an extra sampling iteration.
• Context editing (tool result clearing): precise control, no extra sampling. Parameters: trigger, keep, clear_at_least, exclude_tools, clear_tool_inputs. Pair with the memory tool to persist findings before they are cleared.
• Subagents start fresh and return only their final result. Restate constraints, partition scopes explicitly, specify the return shape. A fork inherits the full conversation; a named subagent does not. A subagent's window is sized by its own model.
• Escalation is a handoff: goal, what is established with evidence, what was tried, and why you are escalating.
• Retry transient failures with backoff using the service's wait hint; do not retry deterministic ones. Retry only with new information. Make retried side effects idempotent. Every loop needs an attempt or time budget and a defined exit.
• Degrade gracefully: shed the affected capability, keep the rest, say so plainly, offer a path forward. Never answer from stale memory and never silently omit.
• Extraction: make legitimately optional fields nullable and define what null means; capture source spans; return per field confidence and route the uncertain to human review; narrow the input rather than stuffing whole documents.
• Structured outputs guarantee valid JSON, correct types, and required field presence. They do not guarantee the values are true.