Multi-Agent Orchestration Patterns for CCAR-P: Architect Guide [2026]

Domain 1 (Solution Design & Architecture, 17%) and Domain 3 (Integration, 19%) together supply more than a third of the Claude Certified Architect - Professional (CCAR-P) exam, and the questions at their intersection ask a version of the same thing: how many model calls does this problem deserve, how should those calls be arranged, and what does the arrangement cost in tokens, latency, and operational risk? This guide covers the orchestration patterns the blueprint expects you to recognize on sight (the single augmented call, workflows, orchestrator-worker on a hub-and-spoke topology, parallel fan-out and fan-in, evaluator-optimizer loops, and agent-to-agent delegation versus MCP tool sharing), the context-isolation, failure-isolation, and observability consequences of each, and three worked scenarios that end with the exam-correct choice and the reasoning behind it.

Why the exam starts with "do you need an agent at all?"

Orchestration is the arrangement of model calls, tools, and control logic that turns one business request into one finished result. Before any multi-agent pattern is on the table, the blueprint expects you to rule out two cheaper arrangements.

The first is the augmented LLM: a single model call enriched with retrieval (fetching relevant documents into the prompt), tools (functions the model can invoke), or memory (state carried across calls), with no autonomous looping. Anthropic's guidance in Building effective agents is direct about how often this is enough: for many applications, optimizing a single call with retrieval and in-context examples is sufficient, and agentic systems trade latency and cost for better task performance. That sentence is the seed of a large share of Domain 1 distractors.

The second is the workflow: several model calls in a sequence the developer fixes in advance, with programmatic checks between steps. Prompt chaining (each call consumes the previous output) and routing (a classifier sends the input to a specialized downstream prompt) are the two workflow shapes the exam names most often. Workflows are predictable and cheap to trace, and a compliance reviewer can enumerate every path through them.

Only when neither fits do you reach the agentic pattern, where the model decides its own next step and tool call inside a loop that runs until a stop condition is met. The justification has to be in the stem: the number of steps cannot be known in advance, the task requires exploring an environment and reacting to what comes back, or the inputs are too open for a fixed pipeline. When a scenario describes well-defined, repeatable steps and then offers an agentic option, the agentic option is the trap.

Signals in the stem that settle the pattern

• One bounded input, one output, and a clear acceptance test point to a single augmented call.
• Known steps, an audit or predictability requirement, or programmatic gates between steps point to a workflow.
• Unknown step count, exploration, or decisions that depend on intermediate results point to an agent.
• Independent subtasks that can run at the same time, or a task too large for one context window (the maximum text a model can attend to in one call), point to multi-agent decomposition.

Find the dominant constraint (latency ceiling, cost pressure, auditability, accuracy floor) before reading the options; the CCAR-P cheat sheet collects the trigger phrases per pattern.

The pattern catalog at architect altitude

The names come from Anthropic's published taxonomy and the CCAR-P and CCA-F blueprints. The exam tests what each pattern buys and what it costs, so each entry covers both.

Orchestrator-worker on a hub-and-spoke topology

A central model (the orchestrator, or hub) reads the task, decides how to decompose it, delegates each piece to a worker (a spoke), and synthesizes what comes back. Hub-and-spoke is the topology: every spoke talks only to the hub and never to another spoke, so coordination lives outside any single specialist and the communication graph stays a star. Anthropic's multi-agent research system is the canonical example: a lead agent plans, spawns subagents that search in parallel with their own context windows, and condenses their findings.

The pattern fits when subtasks cannot be predicted before the run starts (which is what separates it from a fixed workflow), when the work is breadth-first and parallelizable, and when a single context would overflow. Two details matter on the exam. Delegation quality drives everything: Anthropic reported that vague task descriptions caused subagents to run the same searches as each other, so the hub must state objective, output format, tool guidance, and boundaries for each worker. And model tiering is a design lever: the hub carries the hardest reasoning and can justify the most capable model, while bounded worker tasks often run on a cheaper, faster tier.

Parallel fan-out and fan-in

Fan-out splits a task into independent branches that run concurrently; fan-in aggregates the results. Anthropic describes two flavors: sectioning, where each branch handles a different piece, and voting, where several branches attempt the same task and the aggregator picks or reconciles. Wall-clock latency drops to roughly the slowest branch while token cost is the sum of all branches, so the pattern buys speed and coverage with money. Prefer programmatic aggregation (merge, majority, threshold) for structured outputs and reserve a model-based synthesis step for prose. Avoid fan-out when branches depend on each other's intermediate results or share evolving state; that dependency turns concurrency into a coordination problem.

Evaluator-optimizer

One model generates a candidate; a second (or a second call with a different prompt) scores it against explicit criteria and returns feedback; the generator revises; the loop ends when the criteria pass or an iteration cap is hit. The pattern earns its cost only when the criteria are clear enough for the evaluator to judge reliably and iteration demonstrably improves the output. Translation, code that must pass a test suite, and long drafts against a rubric qualify; fuzzy criteria or a task a single well-instructed call already handles do not, and each loop multiplies tokens and latency by the iteration count. Keep the evaluator separate from the generator when unbiased judgment matters; a model grading its own answer inherits its own blind spots.

The autonomous single agent

A single agent with tools and a loop remains the right answer for open-ended work that fits one context: debugging a failing build, working a customer case that needs a few lookups and one action, or interactive coding. Bound it with a maximum turn count, a spend budget, and clear stop conditions, and expose a human check-in wherever an action is irreversible. Multi-agent decomposition on top of a task like this adds coordination cost without a parallelism dividend; Anthropic notes that most coding tasks contain fewer truly parallelizable pieces than research does.

Agent-to-agent delegation vs MCP tool sharing

Domain 3 asks you to choose an integration mechanism, and the pair that confuses candidates most is agent-to-agent delegation versus tool sharing through the Model Context Protocol (MCP, an open standard for exposing tools, data sources, and prompts to any compliant AI application through a common client-server interface).

The distinction is who does the thinking. When an agent calls an MCP tool, the calling agent keeps all of the reasoning; the tool runs a bounded function (query this database, create this ticket) and returns a result. MCP is the answer when the same capability must be reused across many surfaces and teams: build the server once, expose it to Claude Code, desktop clients, and API agents alike, and manage its permissions in one place. When one agent delegates to another, it hands over a whole subproblem to a system that reasons with its own context, tools, policies, and failure handling, and receives a summary back. Delegation is the answer when the callee owns a distinct domain of responsibility, applies judgment the caller should not replicate (approval logic, regulated decisions, domain expertise), and must be able to operate and fail independently.

Inside one application, subagents are the local form of delegation. In Claude Code and the Claude Agent SDK, a subagent runs in its own context window with its own system prompt, an allowlist of tools, and independent permissions; only its final message returns to the parent. Two anti-patterns recur in stems. The first is wrapping every team's agent as a "tool" inside one mega-agent, which produces capability bloat (more tools than the task needs, degrading tool selection and widening the security blast radius) and confused-deputy risk (the aggregate agent exercising permissions its user should not hold). The second is exposing an owning team's raw tools over MCP when the consumer actually needs that team's judgment; the caller then reimplements the approval logic badly, and two systems own one policy.

Context isolation: what each pattern shares and what it hides

Context isolation means a delegated worker starts with a fresh context containing only what it was explicitly given, and returns only a final result. In Claude Code and the Agent SDK, a subagent receives its own system prompt plus the delegation prompt (and project configuration), and does not receive the parent's conversation history, tool results, or previously read files. The parent sees the final message and none of the intermediate tool calls.

Isolation is what makes multi-agent systems scale. Each worker can read dozens of documents without those tokens accumulating in the orchestrator, several workers can explore different trajectories at once, and the orchestrator receives condensed findings in place of raw material. Anthropic describes this as compression: workers distill a large corpus and hand up the important tokens.

The cost is that nothing is shared implicitly. Every file path, constraint, prior decision, and output format the worker needs must travel in the delegation prompt, and workers cannot see one another's partial results unless the hub relays them. Three stem patterns map to this directly. Overlapping worker output signals a delegation prompt that is too vague. A main conversation whose quality degrades as it grows signals verbose exploration that belongs in subagents. A task where the worker needs the entire prior conversation signals that a fresh subagent is the wrong tool; keep it in the main agent, or fork the conversation so the child inherits it, and accept the token cost.

Failure isolation and recovery per pattern

Every additional call is another place to fail, and the exam wants failures contained at the smallest unit that can absorb them.

• Workflow: programmatic checks between steps catch a bad intermediate output before it propagates; retry the step, route to a fallback prompt, or stop and surface the failure. The audit trail is linear, which is why regulated processes prefer this shape.
• Fan-out and fan-in: define the aggregation policy for partial failure up front (proceed with the branches that succeeded, retry the failed branch, or fail the request) and write it into the design document.
• Orchestrator-worker: a failing worker should never take the run down with it. The hub retries, reassigns, or degrades gracefully, and long-running systems resume from a checkpoint in preference to restarting. Anthropic's production lesson combines model adaptability (tell the agent a tool is failing and let it change approach) with deterministic safeguards such as retry logic.
• Evaluator-optimizer: cap iterations and record the score trajectory, so a loop that never converges terminates with a best-effort result and a flag before it burns the budget.
• Agent-to-agent across systems: treat the callee like any remote dependency, with timeouts, idempotent requests (safe to retry without duplicating side effects), circuit breakers, and correlation identifiers that stitch one request across the logs of two systems.

Bound the blast radius structurally as well. Restrict tools per worker (a reviewer that can Read and Grep but never Write cannot damage anything), and use the runtime's caps on turns, spend, subagent nesting depth, and concurrency so a delegation tree cannot grow past the budget. The governance and guardrails guide covers where human approval gates sit inside these loops.

Observability per pattern

Observability is the ability to reconstruct what a system did and why from the telemetry it emitted. Multi-step systems fail in ways where the symptom appears several steps downstream of the cause, so tracing (recording each step with links to its parent) is a design requirement, and each pattern needs a different trace shape.

Two points carry into exam answers. The trace tree for orchestrator-worker needs parent-child linkage (the Agent SDK marks messages that originate inside a subagent with a parent identifier), so a bad synthesis can be traced back to the worker that fed it. And high-level monitoring of decision patterns (which workers were spawned, how many tool calls, which routes fired) is often enough for operations while avoiding storage of conversation contents, which matters when the payload is regulated data.

Cost implications the stem will hint at

Multi-agent systems consume tokens at a multiple of a single conversation. Anthropic's published figures for its own research system are that agents use roughly 4 times the tokens of a chat interaction and multi-agent systems roughly 15 times, and the performance gain has to justify that spend. A stem that stresses cost pressure or a per-transaction budget is steering you away from multi-agent answers unless the task genuinely cannot be done any other way.

The levers you should be able to name: keep the orchestrator on the capable tier and push bounded worker tasks to a cheaper one; use prompt caching (reusing a stable prompt prefix so repeated tokens are processed at reduced cost) for worker system prompts and shared reference material that repeat across delegations; prefer fan-out when latency is the constraint and sequential execution when cost is; cap evaluator iterations; and remember that agent-to-agent delegation loads context twice, once in each system. Anthropic's effort-scaling guidance is a useful sanity check: simple fact-finding is one agent with 3 to 10 tool calls, a direct comparison might justify 2 to 4 subagents with 10 to 15 calls each, and only complex research warrants more than 10 subagents. The cost and latency optimization guide goes deeper on caching and batching.

Pattern selection at a glance

Three worked scenarios

Each scenario is written the way a CCAR-P stem is written: an enterprise context, a dominant constraint, and options that are all real techniques. Work each one before reading the resolution.

Scenario 1: claims intake with a sponsor who wants an agent swarm

An insurer receives claim submissions as PDFs and emails. Every claim goes through the same four steps: extract structured fields, validate them against policy data, classify severity, and route to a queue. Compliance requires that every routing decision be reproducible on audit, and volume is high enough that per-claim cost is a stated pillar. The sponsor has read about multi-agent systems and asks for one.

Options on a typical stem: an orchestrator that spawns extraction, validation, and classification agents; a single autonomous agent holding the four tools; a four-step workflow with programmatic validation between steps and a fast model tier for extraction and classification; a fan-out of the three analysis steps with a synthesis agent at the end.

The exam-correct choice and why: the workflow. The steps are known and fixed, so an orchestrator's ability to decompose dynamically buys nothing. Reproducibility on audit favors an enumerable path over a loop that may take a different route each time. Cost pressure favors bounded calls on the cheapest adequate tier over the token multiple of a multi-agent run. Fan-out fails on the dependency, since validation needs the extraction output before it can start. Stakeholder handling belongs in the answer too: the architect shows that the sponsor's real goals (throughput and cost) are met by the simpler design and records the decision so it does not resurface at every review.

Scenario 2: breadth-first competitive research

A strategy team asks for a research assistant that, given a market question, surveys many sources, compares vendors across dozens of attributes, and produces a cited synthesis. Questions are open-ended, the number of sources varies per question, results are expected within minutes, and the team has budget for quality. Early single-agent prototypes ran out of context and produced shallow answers.

Options: a single agent with a larger context window and more retrieval; a fixed workflow of search, summarize, compare, write; an orchestrator on a capable tier that plans, fans out to parallel search workers with isolated context on a lower-cost tier, then synthesizes, with tracing across the tree and a spend cap; an evaluator-optimizer loop over one agent's draft.

The exam-correct choice and why: the orchestrator-worker design. The subtasks cannot be predicted per question, the work is breadth-first and independent (so parallel workers cut wall-clock time), the earlier single-context failure is exactly the overflow that context isolation solves, and the latency budget tolerates the coordination. Model tiering keeps the token multiple in check, the spend cap bounds runaway delegation, and the trace tree makes a bad synthesis debuggable. The workflow loses because the source count and comparison axes vary per question. The evaluator loop polishes a draft that was shallow for lack of coverage, and iteration cannot add coverage the draft never had.

Scenario 3: support resolution across three owning teams (Select TWO)

A support-resolution agent needs to read billing status and CRM history for a customer, and in a minority of cases issue a refund. Billing and CRM are owned by other teams and are already consumed by several internal applications. Refunds are owned by finance, which runs its own approval policy and its own agent for exceptions. The stem asks for the two integration decisions the architect should make.

Options: expose billing-status and CRM lookups as MCP tools shared across all consuming applications; give the support agent direct database credentials to billing and CRM for lower latency; delegate refund cases to the finance team's agent and consume its decision as a summary; expose the finance team's refund-execution tools over MCP so the support agent can apply the approval policy itself.

The exam-correct choices and why: the MCP lookups and the agent-to-agent refund delegation. The lookups are bounded capabilities reused by many surfaces, which is the MCP case, and a shared server centralizes permissions and observability. The refund is a distinct domain with judgment and policy that finance owns; delegating keeps one owner for the approval logic, isolates failure, and lets finance change the policy without touching the support agent. Direct credentials bypass shared authorization and duplicate integration work for every consumer. Exposing the refund tools would force the support agent to reimplement the approval logic of finance, splitting ownership of a regulated action across two systems.

Frequently asked questions

Key takeaways

Next steps

Turn the patterns into exam reflexes. Work the CCAR-P practice questions with explanations and note every miss in Domains 1 and 3, then reread the relevant section here. The exam domains breakdown shows how orchestration questions distribute across the blueprint. When you are ready for full-length timed runs, Preporato's CCAR-P practice tests are included in Preporato Pro (see pricing) alongside the 500-card flashcard deck, and the free sampler is open to everyone.

Sources:

• Anthropic Engineering: Building effective agents
• Anthropic Engineering: How we built our multi-agent research system
• Claude Code documentation: Subagents
• Claude Agent SDK documentation: Subagents in the SDK
• Model Context Protocol: What is MCP?