Multi-Agent Orchestration with Coordinator-Subagent Patterns

The Multi-Agent Orchestration with Coordinator-Subagent Patterns topic sits at the center of CCA-F Domain 1 (Agentic Architecture & Orchestration, 27% exam weight) and is the single most tested design pattern on the Claude Certified Architect Foundations exam. Task statement 1.2 — "Orchestrate multi-agent systems with coordinator-subagent patterns" — shows up directly in the Multi-Agent Research System scenario cluster, and its concepts bleed into every other scenario where a workflow has more than one logical step. If you misread how a coordinator delegates, how context flows (or fails to flow) between a coordinator and its subagents, or how parallel Task invocations combine, you will miss the specific answer the exam wants on at least three questions per sitting.

This study note covers the full surface a CCA-F candidate is expected to reason about: the hub-and-spoke architectural shape, the isolated subagent context guarantee, the coordinator's responsibilities for decomposition and synthesis, the Task tool and AgentDefinition scopes, parallel versus sequential dispatch, iterative refinement loops, and the high-frequency failure mode where a coordinator decomposes too narrowly and loses the cross-cutting signal. Every section maps to the Multi-Agent Research System scenario and its most-tested exam traps.

What Is Multi-Agent Orchestration in Claude

Multi-Agent Orchestration with Coordinator-Subagent Patterns refers to the architectural approach of splitting a complex task across two or more Claude agent instances — one coordinator that owns the top-level goal and one or more subagents that each own a narrower responsibility. The coordinator does not do the subagents' work itself. It plans, dispatches, and synthesizes. The subagents execute. This split exists because a single Claude context window has finite capacity, and a single linear conversation cannot usefully parallelize or isolate divergent lines of exploration.

On the exam, multi-agent orchestration is never tested as an abstract architecture diagram. It is always tested through a concrete scenario — most commonly the Multi-Agent Research System scenario — where a coordinator must answer a compound research question by dispatching several subagents to investigate different sub-questions in isolation, then folding the results into one synthesized answer. The exam rewards candidates who understand the mechanics of the delegation: how subagents are spawned, what context they do and do not inherit, how their results return, and what the coordinator is obligated to do with those results.

Why Multi-Agent and Not Just One Big Prompt?

Candidates who have only built single-session agents often ask why you would introduce coordination overhead when you could just prompt one Claude instance to do everything. Four structural reasons drive multi-agent design, all of which surface in exam scenarios.

• Context isolation. A subagent that explores a dead-end search path does not pollute the coordinator's context with irrelevant tool results.
• Parallelism. Independent sub-tasks can be dispatched simultaneously, reducing wall-clock latency.
• Specialization. A subagent can be given a narrower allowedTools list and a more focused system prompt than a generalist coordinator could wear.
• Scale. Research tasks that would exceed a single context window become tractable when each subagent consumes only the slice relevant to its sub-question.

The Multi-Agent Research System scenario exercises all four reasons in a single compound question, so internalizing them pays off quickly.

Hub-and-Spoke: The Canonical Coordinator-Subagent Shape

The hub-and-spoke pattern is the architectural shape the CCA-F exam assumes by default. Understanding its geometry and its constraints is the prerequisite for every other concept in this topic.

The Hub

The hub is the coordinator agent. It holds the full original user request, the plan it derived from that request, the list of outstanding and completed sub-tasks, and the aggregated results so far. The hub's context window contains the authoritative version of the task state. Only the hub talks to the end user.

The Spokes

Each spoke is a subagent invocation. A spoke receives a narrowly scoped task description, runs its own agentic loop (tool use, thinking, tool results, more tool use) until it reaches a terminal stop_reason, and returns its final message as a structured result to the hub. A spoke does not talk to another spoke. A spoke does not see another spoke's context. A spoke does not see the hub's context beyond the explicit task brief it was given.

Why Hub-and-Spoke and Not a Mesh?

The CCA-F exam consistently prefers hub-and-spoke over peer-to-peer or mesh designs because mesh topologies compound three failure modes:

• Context bleed. Peer agents passing context directly risk inheriting each other's dead ends.
• Coordination ambiguity. Who is responsible for synthesizing the final answer when every agent can talk to every other agent?
• Error attribution. When a subagent returns a wrong answer in a mesh, tracing which upstream peer contaminated it is intractable.

Hub-and-spoke keeps the synthesis authority in one place (the coordinator) and keeps every subagent's failure mode local to its own spoke.

Hub-and-Spoke in the Multi-Agent Research System Scenario

A concrete scenario the exam exercises: a user asks a research coordinator to "compare the open-source licensing strategies of Kubernetes, Terraform, and Redis over the last decade, and summarize the implications for vendor-sustainability risk." A single Claude instance would exhaust its context exploring all three projects and fail to produce a coherent comparison. The coordinator instead:

1. Decomposes into three sub-questions — one per project — plus a fourth "cross-project synthesis" sub-task.
2. Dispatches three subagents in parallel, each with the narrow brief for one project.
3. Waits for all three subagent results to return.
4. Runs a fourth subagent (or does the work itself) to synthesize cross-cutting patterns.
5. Returns one cohesive answer to the user.

The exam tests this exact shape and rewards candidates who can identify the coordinator's responsibilities at each step.

Coordinator Responsibilities

The coordinator is not "the smart one" and the subagents "the dumb ones." They all run the same Claude model class. The coordinator's role is structural, not cognitive. It has seven explicit responsibilities.

Responsibility 1: Decomposition

The coordinator converts the original user request into a plan — a list of sub-tasks specific enough that each can be executed by a single subagent without needing to clarify intent mid-stream. Good decomposition produces sub-tasks that are independent (the result of one does not block the execution of another), scoped (each sub-task has a clear definition of done), and non-overlapping (no two sub-tasks return the same fact).

Responsibility 2: Brief Writing

For every sub-task, the coordinator writes a subagent brief — the equivalent of the user turn that initializes the subagent's conversation. The brief must be self-contained because the subagent will not see the coordinator's context. Brief writing is the single highest-leverage activity the coordinator performs, and it is the skill the exam most aggressively tests under task statement 1.3 (Configure subagent invocation, context passing, and spawning).

Responsibility 3: Dispatch

The coordinator invokes the Task tool (or the SDK equivalent) once per subagent, in parallel when sub-tasks are independent and sequentially when a downstream sub-task depends on an upstream result. Dispatch is not "call and forget" — the coordinator holds a mental map of which spokes are in-flight and which have returned.

Responsibility 4: Aggregation

As subagent results return, the coordinator aggregates them. Aggregation is not synthesis. Aggregation is collecting the structured outputs into the coordinator's context in a way that preserves which subagent produced which claim. The exam tests this under Domain 5.6 (information provenance) — a coordinator that loses track of which subagent said what cannot reason about conflicting claims.

Responsibility 5: Synthesis

Once all required subagent results are in, the coordinator synthesizes them into a single answer that addresses the original user request. Synthesis may require cross-referencing results ("Subagent A says X, Subagent B says Y — are these consistent?"), resolving conflicts, or identifying gaps that require a follow-up dispatch.

Responsibility 6: Error Handling and Retry

When a subagent returns a structured error or an ambiguous partial result, the coordinator decides whether to retry with a refined brief, dispatch a new subagent with a different approach, or escalate back to the user. This is the iterative refinement loop covered in its own section below.

Responsibility 7: Final Response

The coordinator is the sole author of the final message to the end user. Subagents never talk to the user directly. This constraint is why subagent context isolation is survivable in the first place — the coordinator has the full story even when individual subagents do not.

Isolated Subagent Context: The Single Most Tested Mechanic

Isolated subagent context is the CCA-F concept most frequently missed by candidates who studied only single-agent tool use. The exam hammers this point because the correct mental model is counterintuitive to anyone who has built multi-turn assistants where context naturally accumulates.

What "Isolated" Actually Means

When a coordinator dispatches a subagent through the Task tool, the subagent starts with a fresh conversation. The subagent does not see:

• The original user message that initiated the coordinator's conversation.
• The coordinator's system prompt (unless the subagent inherits or is given one of its own).
• Any other subagent's brief or result.
• Any tool calls the coordinator has already made.
• Any prior turns in the coordinator's conversation.

The subagent sees exactly two things: the AgentDefinition (system prompt, tools, model) configured for its agent type, and the task description the coordinator passed in the Task tool call.

Why Isolation Is a Feature, Not a Bug

Isolation is what makes multi-agent orchestration scale. If every subagent inherited the coordinator's full history, each subagent's context window would start nearly full and leave no room to actually do work. Isolation also prevents a noisy coordinator context from biasing a subagent's reasoning. And isolation is what allows the coordinator to dispatch many subagents in parallel without their contexts colliding.

The Trap: Assuming Context Flows Down

The highest-frequency CCA-F trap is assuming a subagent "knows what the coordinator knows." Candidates build scenarios where the coordinator learned something in turn 3 and then dispatch a subagent in turn 5 without re-passing the turn-3 information in the subagent brief. The subagent, operating with an isolated context, has no way to access turn-3 knowledge and will either hallucinate around the gap or ask a question the user cannot answer.

The correct pattern is that everything the subagent needs must be in the brief. If the coordinator learned a critical fact from an earlier tool call, that fact must be restated in the subagent's task description. The brief is the full, authoritative input.

Contrast with fork_session

The Agent SDK does expose a fork_session capability, but it is a separate mechanism with different semantics. A forked session clones a full conversation, including its history, so that a branch of the conversation can explore an alternative path without committing. Forking is not the same as subagent spawning. A spawned subagent is isolated; a forked session is a copy. The exam tests this distinction explicitly and punishes candidates who conflate the two.

The Task Tool: Mechanics of Dispatch

The Task tool is the primary interface by which a coordinator spawns a subagent. Understanding its arguments and its return shape is required for every scenario in this topic.

What the Task Tool Does

When the coordinator calls Task, the Claude Code runtime (or Agent SDK) spins up a new subagent session, runs that subagent through its own agentic loop until it reaches a terminal stop_reason, and returns the subagent's final assistant message back to the coordinator as a tool result. From the coordinator's point of view, Task is a single tool call that happens to take a long time and returns a rich structured result.

Task Tool Arguments

The common arguments the exam expects you to recognize:

• subagent_type (or agent_type) — the name of the AgentDefinition the subagent should run as. This selects the system prompt, the allowed tools, and the model.
• description — a short label for the task, used for logging and task-list tracking.
• prompt — the full task brief, written as if it were the user's first turn in a new conversation.

The most common mistake is under-specifying the prompt. Candidates write briefs like "research open-source licensing for Redis" and expect the subagent to know which years, which aspects, and which output format to use. The correct brief includes all of that context explicitly because the subagent cannot infer it.

Parallel Dispatch: Multiple Task Calls in One Turn

A coordinator can emit multiple Task tool calls in a single assistant turn. When it does, the runtime executes all of them in parallel and returns their results together in the next user turn. This is the mechanism by which the Multi-Agent Research System scenario achieves its wall-clock latency reduction.

Parallel dispatch requires that the sub-tasks be truly independent. If Subagent B needs Subagent A's result to write its brief, the coordinator must dispatch A first, wait for A's return, then dispatch B — two sequential turns, not one parallel turn.

AgentDefinition and allowedTools

Each subagent runs under an AgentDefinition — a configuration object that specifies the subagent's system prompt, its allowedTools list, and optionally the model. The allowedTools list is a deliberate constraint: a research subagent may be given WebSearch, WebFetch, and Read but not Write or Bash. Narrowing the tool surface reduces the subagent's attack surface, focuses its attention, and prevents accidental side effects from propagating outside its spoke.

The exam tests allowedTools under Domain 2 (Tool Design) and references it whenever a scenario involves dispatching a subagent for a sensitive task. A coordinator that gives every subagent the full tool palette is a common wrong-answer shape.

Task Decomposition Strategies

Task decomposition is the planning activity the coordinator performs before any subagents are dispatched. Good decomposition is the single biggest predictor of multi-agent success, and the CCA-F exam exercises it heavily under task statement 1.6 (Design task decomposition strategies for complex workflows).

Criteria for a Good Sub-Task

A well-formed sub-task meets five criteria:

• Independent. It does not require the output of another in-flight sub-task.
• Scoped. It has a clear definition of done, expressible in the brief.
• Self-contained. The brief can carry all required context without exceeding reasonable length.
• Non-overlapping. No other sub-task produces the same fact.
• Verifiable. The coordinator can check the returned result against the brief without re-running the sub-task.

Decomposition Patterns

Three decomposition patterns cover almost every multi-agent scenario on the exam.

• By entity. One subagent per distinct entity under investigation. The licensing-comparison scenario uses this — one subagent per project.
• By aspect. One subagent per dimension of analysis. A security review might dispatch one subagent for authentication, one for authorization, one for input validation.
• By stage. One subagent per pipeline stage, dispatched sequentially. A research pipeline might dispatch a "gather sources" subagent, then a "extract claims" subagent, then a "cross-reference claims" subagent.

By-entity and by-aspect decompositions parallelize naturally. By-stage decompositions are inherently sequential.

The Risk of Overly Narrow Decomposition

The most insidious decomposition failure is over-narrow decomposition: splitting the task into so many tiny sub-tasks that each individual subagent lacks the context needed to notice cross-cutting patterns. When every subagent returns a correct-looking answer about its narrow slice, but the synthesis step cannot recover the broader pattern the original question was actually asking about, the coordinator has decomposed too aggressively.

A common exam trap presents a scenario where the coordinator splits "compare three projects' licensing strategies" into twelve sub-tasks (one per year per project) instead of three (one per project). The per-year sub-tasks each return sensible facts, but no subagent ever sees enough context to notice that Project A's licensing changed in response to Project B's earlier change. The pattern is invisible at the per-year grain and only emerges at the per-project grain.

Decomposition vs Chaining

Task decomposition (multi-agent) is distinct from prompt chaining (single-agent). Prompt chaining threads one Claude session through multiple sequential prompts within a single context. Decomposition splits across multiple isolated Claude sessions. Chaining keeps context; decomposition discards it. The exam tests when to reach for each.

Parallel Task Calls and the Iterative Refinement Loop

Parallel dispatch is the mechanical side of multi-agent orchestration. Iterative refinement is the temporal side — how the coordinator uses subagent results across multiple turns to improve the final answer.

Parallel Dispatch Mechanics

In a single assistant turn, the coordinator can emit multiple Task tool calls. The runtime fans out the execution across all of them simultaneously. When every parallel subagent has reached its terminal stop_reason, the runtime returns all their results together as parallel tool-result blocks in the next user turn. The coordinator then reads all of them at once.

Parallel dispatch shines when sub-tasks are truly independent. It collapses to sequential when sub-tasks have dependencies, because the coordinator must wait for one result before it can write the next brief.

The Iterative Refinement Loop

In real research workflows, the first round of subagent results is rarely the final answer. The coordinator often needs to iterate:

1. Plan — decompose into initial sub-tasks.
2. Dispatch — fire off parallel Task calls.
3. Aggregate — collect results.
4. Evaluate — check whether the aggregated results answer the original question.
5. Refine — if gaps exist, dispatch follow-up subagents with refined briefs that explicitly reference the gaps discovered in step 4.
6. Synthesize — once the coordinator judges the evidence sufficient, write the final answer.

This loop can run multiple iterations. Each iteration produces more targeted briefs because the coordinator has more context about what the earlier rounds missed. The exam tests this loop under task statement 3.5 (Apply iterative refinement techniques for progressive improvement), and the Multi-Agent Research System scenario is the canonical vehicle.

When to Stop Iterating

A coordinator that never stops iterating will exhaust its context window chasing diminishing returns. The coordinator must have a stopping criterion: either a coverage criterion ("every sub-question has been answered with at least one subagent result") or a budget criterion ("at most two refinement rounds"). Exam scenarios often test stopping criteria obliquely — an answer choice that proposes unbounded iteration is usually wrong.

Context Passing Between Coordinator and Subagent

Since isolated subagent context is the default, context passing is the mechanism by which the coordinator deliberately punches specific information through the isolation boundary. Context passing happens entirely through the Task tool's prompt argument — there is no implicit channel.

What to Pass

At minimum, every subagent brief should include:

• The sub-task goal. Phrased as a specific, verifiable outcome.
• The scope boundary. What the subagent should not expand into.
• The output format. Structured, schema-like expectations the coordinator can parse.
• Any relevant facts the subagent cannot independently rediscover. Facts the coordinator learned in earlier turns.
• The allowed tools and their expected use. If the subagent has a narrow tool list, the brief should hint at when each is appropriate.

What Not to Pass

The brief should not include:

• The full original user request (unless it is directly needed). Re-passing the whole user conversation defeats the purpose of decomposition.
• Other subagents' results (unless there is a real dependency). Cross-polluting subagents erodes the parallelism benefit.
• The coordinator's internal plan. Subagents should not second-guess the decomposition.

Output Format Discipline

The coordinator's aggregation step is easiest when every subagent returns results in a predictable shape. Briefs should specify the output format explicitly: "Return a JSON object with fields license_changes, timeline, and sustainability_signals." When subagents return free-form prose, the coordinator spends its context budget parsing the prose instead of synthesizing conclusions.

Error Propagation and Recovery

Subagents fail. The coordinator must handle those failures. CCA-F tests error handling in multi-agent systems under task statement 5.3.

Failure Modes

Three common subagent failure modes appear in exam scenarios.

• Tool-level error. A subagent's tool call fails (network timeout, permission denied, malformed response). The subagent should return a structured error describing what failed.
• Task-level failure. A subagent completes its loop but cannot produce the requested output (the information is not available, the request is ambiguous, the scope is ill-defined).
• Stop-reason mismatch. A subagent hits max_tokens or stop_sequences before completing, returning a partial result.

Structured Error Responses

When a subagent returns an error, it should return it in a structured shape that the coordinator can reason about — error category, retry-ability flag, human-readable detail. A coordinator that receives a generic error string has to guess whether to retry, escalate, or abort. A coordinator that receives { errorCategory: "transient", isRetryable: true, detail: "WebSearch timed out" } can retry deterministically. This ties into Domain 2.2 (structured error responses) and is exam-tested frequently.

Coordinator Recovery Strategies

Given a subagent failure, the coordinator has four options:

1. Retry with same brief — when the error is transient.
2. Retry with refined brief — when the error suggests the brief was ambiguous or under-specified.
3. Dispatch a different subagent — when the failure suggests the subagent type or allowed tools were wrong.
4. Partial synthesis with explicit gaps — when recovery is uneconomic and the user is better served by an honest partial answer.

Exam scenarios often test option 4 — candidates who always default to "keep retrying" miss that the correct answer sometimes involves accepting an incomplete result.

Plain-Language Explanation: Multi-Agent Orchestration

Multi-agent orchestration becomes intuitive when you anchor it to physical systems where coordination and isolation are already familiar.

Analogy 1: The Newsroom — Editor, Reporters, and the Isolated Beat

A newsroom has one editor-in-chief and many reporters. The editor receives a complex story assignment ("cover the election results across three swing states and explain what they mean for the Senate majority"). The editor does not go cover any state personally. Instead, the editor writes three briefs — one per swing state — and dispatches three reporters. Each reporter works on their assigned state in isolation: the Michigan reporter does not sit in on the Pennsylvania reporter's interviews, and vice versa. The reporters file their stories back to the editor. The editor reads all three, notices the cross-cutting pattern ("all three states broke the same way"), and writes the final front-page synthesis.

Every piece of the coordinator-subagent pattern has a newsroom analog:

• Coordinator = editor-in-chief.
• Subagent = assigned reporter.
• Hub-and-spoke = every reporter files to the editor, not to each other.
• Isolated subagent context = the Michigan reporter only sees the Michigan brief.
• Task brief = the assignment memo the editor hands each reporter.
• Parallel dispatch = all three reporters work at the same time.
• Iterative refinement = the editor reads the drafts, notices a missing angle, and sends a reporter back out for a follow-up.
• Over-narrow decomposition = breaking "cover the election" into twenty-seven assignments (one per county) so no single reporter ever sees the state-wide story.
• Synthesis = the editor's final piece.

Analogy 2: The Kitchen Brigade — Expediter, Stations, and No Cross-Talk Between Burners

A restaurant kitchen on a busy service runs a hub-and-spoke pattern under a different name. The expediter (or head chef) reads the ticket, breaks the dish into components, and calls out tasks to each station: the grill cook fires the steak, the sauce station spoons the jus, the garde-manger builds the salad. Each station works in isolation — the grill cook does not step over to the sauce station and interfere. The expediter plates the final dish from all the components that come back.

The analogy clarifies three mechanics:

• Station specialization = AgentDefinition and allowedTools. The grill cook has a grill, not a saucepan.
• Parallel execution = multiple Task calls in one turn. Steak, sauce, and salad all progress simultaneously.
• Plate timing = the expediter waits for all components before plating. A coordinator similarly waits for all parallel subagents before synthesizing.

A kitchen that violates the pattern — letting the grill cook also plate and call out to the sauce station — produces chaos. This is the mesh topology the CCA-F exam warns against.

Analogy 3: The Research Library — Head Librarian and Specialist Librarians

A patron asks the head librarian a compound question: "I'm writing a paper comparing three philosophers' views on free will. What should I read?" The head librarian cannot personally know every book in the library. Instead, the head librarian dispatches three specialist librarians — the ancient philosophy specialist, the early modern specialist, the contemporary specialist — each with a narrow brief. Each specialist searches only their section and returns a curated reading list. The head librarian then cross-references the three lists and hands the patron a synthesized bibliography.

The library analogy shines at explaining context passing. When the head librarian dispatches the contemporary specialist, the head librarian has to include the compound question's context in the brief — "the patron is comparing this thinker to two ancients" — because the contemporary specialist will not see the other specialists' work and cannot independently discover the cross-reference. This is exactly the "everything the subagent needs must be in the brief" rule.

Which Analogy to Use on Exam Day

• Questions about coordinator responsibilities and synthesis → newsroom analogy.
• Questions about parallel dispatch, tool isolation, and specialization → kitchen brigade analogy.
• Questions about context passing and decomposition grain → library analogy.

Agent Teams vs Subagents: Two Related but Distinct Concepts

A subtle but exam-tested distinction exists between Agent Teams (the feature shipped under CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS) and subagents (the general Claude Code and Agent SDK capability). Candidates who conflate them miss scenario nuances.

Subagents (the General Pattern)

Subagents are the general pattern described throughout this note: a coordinator spawns a subagent via the Task tool, the subagent runs in isolation, the subagent returns a result. Subagents have been available since the initial Agent SDK release and are defined via AgentDefinition configuration at the project, user, plugin, or CLI scope.

Agent Teams (the Claude Code Feature)

Agent Teams is a Claude Code feature that adds structured coordination primitives on top of the subagent mechanism — teammate spawning, task-list tracking, and specialized hooks (TeammateIdle, TaskCreated, TaskCompleted). Agent Teams is designed for long-running multi-session coordination inside Claude Code, not for single-turn dispatch inside an Agent SDK application.

Which One the Exam Is Testing

When a scenario describes "a Claude Code session coordinating other Claude Code sessions over hours or days," it is testing Agent Teams. When a scenario describes "an Agent SDK application where a coordinator dispatches research tasks," it is testing general subagents. The hub-and-spoke and isolated-context mechanics apply to both.

Common Exam Traps for Multi-Agent Orchestration

Five recurring trap patterns show up in CCA-F scenarios tied to Multi-Agent Orchestration with Coordinator-Subagent Patterns.

Trap 1: Assuming Subagent Inherits Coordinator Context

The most frequent trap. Answer choices implicitly assume the subagent knows what the coordinator knows. The correct answer always requires explicit context passing through the brief. If an answer says "the subagent will automatically see the prior conversation," it is wrong.

Trap 2: Over-Narrow Decomposition

Covered earlier in its own callout. The scenario presents a many-small-tasks decomposition and asks why the synthesis is shallow. Wrong answers blame the coordinator's model; right answers identify the decomposition grain.

Trap 3: Mesh Topology as a Reasonable Default

Answer choices propose peer-to-peer subagent communication as a design. Hub-and-spoke is the Claude-recommended default; mesh is rarely the correct answer and should only win when the scenario explicitly requires peer coordination (which is essentially never in CCA-F scope).

Trap 4: Unbounded Iterative Refinement

Answer choices propose "keep dispatching follow-up subagents until the answer is perfect." Real workflows must have stopping criteria. An option that describes unbounded iteration is typically wrong.

Trap 5: Confusing fork_session with Subagent Dispatch

Answer choices use fork_session and Task interchangeably. They are different mechanisms — forking clones context, dispatch creates a fresh isolated context. If a scenario wants isolation, the answer is Task (spawn a subagent). If a scenario wants to explore an alternative branch of the current conversation, the answer is fork_session.

Practice Anchors: Multi-Agent Research System Scenario Question Templates

CCA-F practice questions tied to Multi-Agent Orchestration with Coordinator-Subagent Patterns cluster into five shapes. Each shape maps cleanly to the Multi-Agent Research System scenario.

Template A: Context Isolation Recognition

A coordinator agent learns in turn 3 that the user's company operates in the EU and has strict GDPR requirements. In turn 5, the coordinator dispatches a subagent to research available vendor APIs. The subagent returns a list of vendors, some of which are US-only. What is the most likely root cause? Correct answer: the coordinator did not pass the EU/GDPR constraint in the subagent brief, and the subagent's isolated context meant it could not independently know the constraint.

Template B: Decomposition Grain Selection

A research coordinator must compare three open-source projects over ten years. Which decomposition produces the best cross-project synthesis? Correct answer: three subagents, one per project. Wrong answers include thirty subagents (one per year per project — over-narrow) and a single monolithic subagent (under-decomposed, exhausts context).

Template C: Parallel vs Sequential Dispatch

Sub-task B requires the output of Sub-task A. How should the coordinator dispatch them? Correct answer: Task A in one turn, wait for the result, then Task B in a subsequent turn. An answer that dispatches both in parallel in a single turn is wrong because B's brief cannot contain A's result yet.

Template D: Recovery from Subagent Failure

A subagent returns { errorCategory: "transient", isRetryable: true }. What should the coordinator do? Correct answer: retry with the same brief. If the error were { errorCategory: "permission", isRetryable: false }, the correct answer would shift to dispatch a different subagent with adjusted allowedTools or escalate.

Template E: Task vs fork_session Selection

The coordinator wants to explore an alternative phrasing of the current research question while preserving the ability to return to the current state. Which mechanism applies? Correct answer: fork_session, because the goal is to branch the current conversation, not dispatch an isolated sub-task.

Key Numbers and Patterns to Memorize

Multi-Agent Orchestration Frequently Asked Questions (FAQ)

What is the difference between a coordinator and a subagent in Claude?

They run the same model. The difference is structural, not cognitive. The coordinator owns the original user request, performs decomposition, dispatches subagents via the Task tool, aggregates returned results, and writes the final answer. The subagent runs an isolated agentic loop against a narrower brief and returns one structured result to the coordinator. Subagents never talk to the end user and never talk to each other. The coordinator is the sole owner of end-to-end state and the sole author of the final response.

Does a subagent inherit the coordinator's conversation history?

No. This is the single most tested CCA-F mechanic. A subagent starts with a fresh conversation seeded only by its AgentDefinition (system prompt, tools, model) and the task description the coordinator passed in the Task tool call. The coordinator's prior turns, the original user message, and other subagents' results are invisible to the subagent. Everything the subagent needs must be restated explicitly in its brief. Candidates who assume context flows down the hub-and-spoke hierarchy design broken systems and miss exam questions.

When should I dispatch subagents in parallel versus sequentially?

Dispatch in parallel when sub-tasks are truly independent — neither sub-task's brief requires the other sub-task's output. Emit multiple Task tool calls in a single assistant turn and the runtime fans them out simultaneously. Dispatch sequentially when a downstream sub-task's brief depends on an upstream result — call the first Task in one turn, wait for its return, then call the second Task in a subsequent turn. Most Multi-Agent Research System scenarios use parallel dispatch for the initial decomposition and sequential dispatch for any refinement rounds.

What is the difference between the Task tool and fork_session?

Task creates a new, isolated subagent session with no history — the hub-and-spoke dispatch mechanism. fork_session clones the current session so a branch can explore an alternative path without committing, returning to the pre-fork state if needed. They are not interchangeable. Use Task when you want isolation and parallelism. Use fork_session when you want to explore a hypothetical on the current conversation and preserve the ability to backtrack. CCA-F exam scenarios test the distinction directly.

Why does the CCA-F exam prefer hub-and-spoke over mesh topologies?

Mesh topologies — peer-to-peer subagent communication — compound three failure modes: context bleed between peers, coordination ambiguity about who owns the final synthesis, and error attribution difficulty when something goes wrong. Hub-and-spoke keeps the synthesis authority in one place (the coordinator) and keeps every subagent's failure mode local to its own spoke. Claude's Agent SDK and Agent Teams documentation both recommend hub-and-spoke as the default. Answer choices proposing mesh topologies are almost always wrong on the exam.

What happens if I decompose a task too narrowly?

Over-narrow decomposition produces many small sub-tasks that each return correct-looking answers about their narrow slice, but no single subagent ever holds enough context to notice cross-cutting patterns. The coordinator's synthesis step then produces a shallow final answer because the evidence never captured the broader pattern. The fix is to coarsen the decomposition grain so each subagent holds enough context to see patterns within its slice. Over-narrow decomposition is a common CCA-F trap because candidates over-correct from monolithic prompts and end up in the opposite failure mode.

How many refinement rounds should the coordinator run?

A practical default is two rounds: Round 1 covers the initial decomposition, Round 2 addresses gaps identified during Round 1 synthesis. If Round 2 still leaves gaps, return a partial answer that honestly notes the remaining uncertainty rather than dispatching a Round 3. Unbounded refinement exhausts the coordinator's context window and often produces diminishing returns. CCA-F scenarios that offer "keep iterating until perfect" as an answer choice are testing whether you recognize that stopping criteria are required.

Further Reading

• Orchestrate teams of Claude Code sessions (Agent Teams): https://code.claude.com/docs/en/agent-teams
• Create custom subagents — Claude Code Docs: https://docs.anthropic.com/en/docs/claude-code/sub-agents
• Subagents in the Agent SDK: https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• Agent SDK overview: https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-overview
• Tool use with Claude — overview and agentic loop: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview
• Chain complex prompts for stronger performance: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/chain-prompts
• Writing tools for agents — Anthropic Engineering Blog: https://www.anthropic.com/engineering/writing-tools-for-agents

Related ExamHub topics: Agentic Loop and Autonomous Task Execution, Subagent Invocation and Context Passing, Task Decomposition Strategies, Session State, Resumption, and Forking, Error Propagation in Multi-Agent Systems.