CCAR-F · module 1 of 5 · 27% of the exam

Agentic architecture and orchestration

Weight: 27 percent of the exam. Tests whether you can choose the right amount of autonomy for a problem, decompose work across a coordinator and subagents without over-engineering it, and design agent systems that fail and escalate gracefully.

What the exam expects

This is the largest domain on CCAR-F, and it is the one where the scenario format bites hardest. Each sitting draws 4 of the 6 published scenario contexts (customer support resolution agent, Claude Code team adoption, multi-agent research system, developer productivity tooling, Claude Code in CI/CD, structured data extraction), and Domain 1 questions attach to all of them. The same underlying judgment gets tested repeatedly in different clothing: given this situation, how much autonomy is warranted, where should the boundaries between agents sit, and what happens when something goes wrong.

You are expected to be fluent in five things:

1. The workflow versus agent distinction, and the fact that most problems are better served by less autonomy than the scenario's author seems to want.
2. Coordinator and subagent design: what a subagent inherits, what it does not, and what actually returns to the parent.
3. Task decomposition: when splitting work helps and when it multiplies cost for nothing.
4. Graceful failure and escalation: stopping conditions, human checkpoints, and defined terminal outcomes.
5. Session management: continue, resume, and fork, and which one fits a given continuity requirement.

The exam rewards restraint. A large share of wrong answers are wrong because they add autonomy, agents, or model capability that the scenario never justified.

Autonomy tiers: single call, workflow, agent

Anthropic draws the line by asking who controls the sequence of actions. Workflows are systems where models and tools are orchestrated through predefined code paths. Agents are systems where the model dynamically directs its own process and tool usage, deciding what to do next based on what it finds.

Named workflow patterns you should recognize by description alone:

• Prompt chaining: sequential steps where each call processes the previous output, often with a programmatic validation gate between steps.
• Routing: classify the input, then dispatch to a specialized prompt, schema, or model.
• Parallelization: two variants. Sectioning splits a task into independent subtasks run at once. Voting runs the same task repeatedly for diverse outputs.
• Orchestrator-workers: a central model dynamically decomposes the task, delegates to workers, and synthesizes their results. The dynamic decomposition is what separates it from a fixed fan-out.
• Evaluator-optimizer: one call generates, another critiques and scores, and the loop repeats until the output passes.

Note that orchestrator-workers is the pattern behind most multi-agent scenarios on this exam, and that evaluator-optimizer is a loop, which means it needs a bound.

Coordinator and subagent design

Subagents exist for four reasons: context isolation, parallelization, specialized instructions, and tool restriction. If a proposed subagent does not deliver at least one of those, it is over-decomposition.

What a non-fork subagent receives at startup:

• Its own system prompt (the agent definition's prompt or markdown body) plus environment details, not the parent's system prompt.
• The delegation prompt string that the parent writes when handing off. This is the only content passed from parent to subagent.
• The CLAUDE.md hierarchy and a git status snapshot, with one important exception: the built-in Explore and Plan subagents skip both, deliberately, to stay fast and cheap.
• Full content of any skill named in its skills field. Skills the parent already invoked are not inherited.

What it does not receive: the parent's conversation history, the parent's tool results, the parent's system prompt, or the parent's output style. A fork is the exception, because it inherits the parent conversation instead of starting fresh.

What returns to the parent: only the subagent's final message, delivered as the Agent tool result. Intermediate tool calls and results stay inside the subagent. That single fact is why fan-out does not blow up the coordinator's context, and it is also why a subagent's output format has to be specified in the delegation prompt.

Tool restriction is configured with tools (an allow list) and disallowedTools (a subtractive deny list). A tool left out of tools is not present in the subagent's session at all, so Claude simply plans without it: no permission prompt, no error, no wasted turn. That is meaningfully different from including a tool and denying it at permission time, where the agent can still attempt the call and must then handle the denial. Design-time absence beats runtime denial whenever the constraint is known in advance.

Other fields worth knowing by name: model (per-subagent override, which is how you run a strong coordinator with cheaper workers), maxTurns, permissionMode, memory, mcpServers, hooks, and background.

Task decomposition: when to split and when not to

The multi-agent research work Anthropic published is the source of most of the exam's judgment calls here. The findings that matter:

• Multi-agent systems consume roughly 15 times the tokens of a chat interaction, and single agents about 4 times. The pattern is only correct when the task's value justifies that multiplier.
• Multi-agent wins on breadth-first work where subtasks are genuinely independent and each benefits from its own context.
• It loses on work with heavy interdependencies and shared context. Coding is the named counterexample: far fewer truly parallelizable tasks than research, so isolated agents produce changes that do not compose.
• Effort must scale to query complexity. A fixed fan-out applied to every question over-spends on simple lookups and is a documented failure mode.
• Vague delegation causes duplicated work and coverage gaps. Each subagent needs an objective, an output format, tool guidance, and explicit task boundaries.

Two operational limits shape large designs. There is a concurrency limit on how many subagents can run at once in a session, and a separate nesting depth limit on how deep delegation can go. At the depth limit the Agent tool is withheld rather than the chain failing, so the deepest agent does the work itself and returns one summary. For fan-out far beyond the concurrency limit, the answer is wave-based dispatch or a workflow mechanism that orchestrates agents outside the conversation, not a retry loop.

Graceful failure and escalation

Every agent question about reliability reduces to one of three gaps.

No stopping condition. An open-ended loop with no maximum turn count and no definition of done will keep going. Symptoms in scenarios: sessions that never terminate, endless searching for information that does not exist, retries against a down dependency. The fix is an explicit bound (turns, budget, attempts), never a bigger model or a sterner prompt.

No human checkpoint on high cost-of-error actions. Irreversible actions such as refunds, deletions, or merges belong behind an approval gate, so the agent proposes and a human disposes. Prompt wording is a soft control and does not count.

No defined terminal outcome. When the agent cannot proceed, something specific must happen: escalate to a human with a structured record of findings, steps already tried, and the blocker; or fail the pipeline step with its findings. The anti-pattern is failing open, where "the review did not run" is reported as "the review passed."

Two behaviours worth memorizing because they show up as trick options. First, an API error that ends a subagent early is never delivered as its result: a foreground subagent cut off after producing text returns that partial output with a note that it did not finish, and one that produced nothing fails with a terminated-early error. Second, unattended environments (CI, batch) must not rely on a permission prompt, because there is nobody to answer it, and the job hangs until the runner times out.

Session management

Sessions persist the conversation, not the filesystem, and session files are local to the machine that created them. In ephemeral CI runners or serverless environments, the robust approach is to capture the results you need as application state and pass them into a fresh session's prompt rather than shipping transcript files between hosts.

How to think through the question

Domain 1 stems are long. Work them in this order.

1. Find the constraint. Scan for the sentence that fixes the answer: a latency budget, a cost complaint, "the steps never vary", "no human is present", "each item is independent", "every stage needs the previous stage's full context". One clause usually decides the question.
2. Identify what is actually being asked. First step, root cause, what is wrong with this design, or which change most improves it. A root-cause question wants the mechanism, not the remedy. A "most improves" question wants the change with the largest effect on the stated constraint, not the most changes.
3. Eliminate over-engineering. Cross out options that add agents, autonomy, subagents, or model capability the constraint does not require. On this domain that removes one or two distractors almost every time.
4. Eliminate options that ignore the stated constraint. An option that raises a timeout when nobody is there to answer, or that adds context window when the problem is turn count, is answering a different question.
5. Prefer the enforcement boundary over the instruction. When one option changes a prompt and another changes structure (a tool list, a checkpoint, a bound, a route), the structural one wins.

Worked example. A support agent can issue refunds through an MCP tool and occasionally refunds an unverified account because the customer sounded frustrated. Which change most improves this design?

Step 1, the constraint: refunds are money, so this is a high cost-of-error, irreversible action. Step 2, the ask: "most improves", so we want the change with the biggest effect on that constraint. Step 3, eliminate over-engineering and capability upgrades: a stronger model reduces frequency but leaves an unreviewed wrong decision executing, so the cost of error is unchanged. Step 4, eliminate options that miss the constraint: lowering temperature addresses output variability, not judgment, and a deterministic agent that is deterministically wrong still issues the refund. Step 5, structure over instruction: adding "be careful with refunds" to the system prompt is a soft control with no enforcement. What remains is the human checkpoint, where the agent proposes the refund and a person approves before the tool executes. That is the answer.

Exam traps

• Reaching for an agent when the steps are known. Tempting because the scenario says "automate", and automation sounds agentic. If the steps never vary, it is a workflow.
• Adding subagents to fix a quality problem. Tempting because more agents feels more capable. If the stages share context and run in sequence, isolation is a cost, not a benefit.
• Assuming subagents can see the parent's conversation. Tempting because they feel like part of the same session. They receive only the delegation prompt, which is why "the dependencies we discussed" resolves to nothing.
• Assuming the parent receives everything the subagent read. The opposite is true, and it is the whole point of delegation.
• Forgetting that Explore and Plan skip CLAUDE.md. Tempting because every other subagent loads it. A rule that must reach Explore has to be restated in the delegation prompt.
• Choosing continue in a multi-user system. Tempting because it is simpler. It grabs the most recent session in the directory, which with concurrent users is the wrong one.
• Treating fork as a recovery mechanism. Fork branches history to explore an alternative. Crash recovery is continue or resume.
• Fixing an unbounded loop with a better model or a stronger critic. Tempting because the loop's output is poor. Non-convergence is a missing stopping condition, and it needs a bound plus a defined terminal outcome.
• Failing open in automation. Tempting because a green pipeline looks like success. "Did not run" must never be reported as "passed".
• Assuming multi-agent is more token efficient because work is shared. It is roughly 15 times a chat interaction. Value has to justify it.

Quick reference

• Who controls the sequence? Code means workflow. Model means agent.
• Workflow patterns: chaining, routing, parallelization (sectioning and voting), orchestrator-workers, evaluator-optimizer.
• Subagents are for context isolation, parallelization, specialization, and tool restriction. Nothing else justifies one.
• Only the delegation prompt goes down; only the final message comes back.
• Omitting a tool removes it from the session. Denying it at runtime does not.
• Independent subtasks parallelize. Interdependent, context-sharing work does not.
• Scale delegated effort to query complexity. Fixed fan-out is a failure mode.
• Every loop needs a bound and a defined outcome when the bound is hit.
• High cost of error plus irreversible equals human checkpoint.
• continue for the latest session, resume for a specific one, fork to branch.
• Session files are per machine. For ephemeral hosts, pass results forward as application state.