The six production scenarios

What you will be able to do

• Describe each of the six production scenarios in the CCAR-F blueprint
• Map a scenario to the domains it most heavily draws on
• Read a scenario item as a diagnosis problem rather than a recall problem
• Recognise a proportionate fix and reject a technically correct but oversized one

A CCAR-F sitting draws four scenarios from a bank of six. Each scenario is a system that already exists and already works well enough to be in production, and each item inside it hands you a symptom: the agent escalates too often, the reviewer comments are noisy, the extraction pipeline fails on a document type nobody anticipated.

That is the whole reason to study the scenarios in advance. The skill being tested is diagnosis, followed by choosing a fix in proportion to the fault. Naming a feature that would help is not enough, because the distractors are usually features that would also help, applied one layer away from the actual cause.

The published blueprint lists primary domains for every scenario, so this mapping is not guesswork. It tells you which domains a given setting is most likely to test.

Two things are worth noticing in that table. Context management appears in four of the six rows despite being the smallest domain by weight, which is a fair reflection of how often a context mistake is the actual cause of a symptom the scenario describes. And prompt engineering appears in only two, both of them settings where the output feeds a machine rather than a person.

Customer support resolution agent#

An Agent SDK agent handles high-ambiguity customer requests: returns, billing disputes, account issues. It reaches the backend through custom MCP tools rather than talking to services directly. The business measures it on first-contact resolution, and it has to know when a case belongs with a human.

The tension in this setting is autonomy against safety. Every item is really asking where the line sits: which actions the agent may take alone, which need confirmation, what a tool should return when it cannot complete a request, and how the agent recognises that a customer's account state makes the request unanswerable rather than merely difficult. Escalation is a design decision here, not a fallback.

Code generation with Claude Code#

A team uses Claude Code for generation, refactoring and documentation inside a shared repository. The workspace carries custom slash commands and CLAUDE.md configuration, and the team has to decide per task whether to use plan mode or go straight to execution.

Items here are about configuration reaching the right work at the right time. A convention that lives in one engineer's head is not configuration; a convention loaded for every file in the repository when it applies to one directory is configuration in the wrong scope. The plan mode question recurs because it is genuinely a judgement call: plan mode buys review before change, which is worth its latency on a wide refactor and wasted on a well-specified single-file edit.

Multi-agent research system#

A coordinator delegates to specialised subagents for search, document analysis, synthesis and report generation, and the system produces reports with citations.

This is the densest agentic-architecture setting in the bank, and the hardest to reason about casually, because faults propagate. What the coordinator passes to a subagent determines what the subagent can do; what the subagent returns determines what synthesis can support; whether source identity survives both hops determines whether the citations in the final report mean anything. Expect items where the visible symptom (an uncited claim in a report) is several steps from its cause (a subagent that summarised its findings and dropped the source references).

Developer productivity with Claude#

Agent SDK tooling that explores unfamiliar codebases, makes sense of legacy systems and automates repetitive tasks, using built-in tools alongside MCP servers.

The recurring problem is context: a large repository does not fit, so the question is always which subset the agent reads and how it decides. Items in this setting tend to contrast a built-in tool with a custom MCP tool and ask which belongs where, or to present an agent that reads too much and ask what would narrow it. A useful instinct is that exploration should be progressive, moving from cheap structural signals to expensive full reads, rather than starting with a broad ingest and hoping the model sorts it out.

Claude Code for continuous integration#

Claude Code runs inside a pipeline doing automated review, test generation and pull request feedback. Prompts are tuned for actionable output and a low false-positive rate.

The distinguishing constraint is that no human is in the loop at the moment of judgement, so the prompt has to carry the standard. This is where explicit criteria earn their keep: "flag anything suspicious" produces a review nobody reads by the second week, while a stated bar for what counts as worth reporting produces comments engineers act on. Expect items about noisy output, and note that the fix is usually sharper criteria rather than a larger model or another pass.

Structured data extraction#

Extraction from unstructured documents into a validated JSON schema, with high accuracy requirements, graceful handling of edge cases and a downstream system that consumes the output.

This setting is the most mechanically checkable of the six, which is why it carries the sharpest items. Schema enforcement, validation, retry with feedback and batch strategy all have defensible right answers. The interesting judgement is about failure: what the pipeline should do with a document it cannot parse confidently, and how that document reaches a human without stalling the batch. An extraction system that silently emits a low-confidence value is worse than one that refuses, because the downstream consumer cannot tell the difference.

How to use this in the exam#

Read the setting before the symptom. Three of the six scenarios are Agent SDK settings and two are Claude Code settings, and knowing which one you are in already narrows the plausible fixes: a scenario about a CI pipeline is unlikely to be answered by a change to subagent context passing.

Then read the symptom literally. The most common error under time pressure is answering the problem you expected rather than the one described, which is exactly what the distractor built from a neighbouring failure is there to catch.

The next lesson turns this into a preparation plan, which comes down to building four things rather than reading about six.