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.

Hub vs Spokes

The hub (coordinator) holds the full user request, the plan, the list of outstanding/completed sub-tasks, and the aggregated results. Only the hub talks to the end user. Each spoke receives a narrow brief, runs its own agentic loop, and returns a structured result. Spokes never talk to each other and never see the hub's broader context.

Why Hub-and-Spoke and Not a Mesh?

The exam consistently prefers hub-and-spoke because mesh topologies compound three failure modes — context bleed (peers inherit each other's dead ends), coordination ambiguity (who synthesises the final answer?), and error attribution (untraceable when one peer contaminates another). Hub-and-spoke keeps synthesis in one place and keeps every failure mode local to its 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 — no original user message, no coordinator system prompt, no other subagents' briefs, no prior coordinator tool calls or turns. The subagent sees exactly two things: its AgentDefinition (system prompt, tools, model) and the task description in the Task call.

Why Isolation Is a Feature

Isolation is what makes multi-agent orchestration scale. If every subagent inherited the coordinator's full history, each subagent would start its context nearly full. Isolation also prevents a noisy coordinator from biasing subagent reasoning, and lets the coordinator dispatch many subagents in parallel without context collisions.

The Trap: Assuming Context Flows Down

The highest-frequency CCA-F trap is assuming a subagent "knows what the coordinator knows." A coordinator learns a fact in turn 3, dispatches a subagent in turn 5, but doesn't restate the fact in the brief. The subagent has no access to turn-3 knowledge and will either hallucinate or ask a question the user cannot answer.

Correct pattern: 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 every dispatch.

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.

Mechanics

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

Task Tool Arguments

• subagent_type — the AgentDefinition to run as (selects system prompt + allowed tools + model).
• description — short label for logging / task-list tracking.
• prompt — the full task brief, written as if it were a first user turn.

The most common mistake is under-specifying prompt. Briefs like "research open-source licensing for Redis" leave the subagent guessing which years, which aspects, which output format. Restate everything the subagent needs.

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 the coordinator does before any subagent is dispatched. Good decomposition is the single biggest predictor of multi-agent success, exercised heavily by task statement 1.6.

Criteria for a Good Sub-Task

A well-formed sub-task is independent (not waiting on another in-flight one), scoped (clear definition of done), self-contained (brief carries all required context), non-overlapping (no two sub-tasks produce the same fact), and verifiable (the coordinator can check it without re-running).

Decomposition Patterns

Three patterns cover almost every multi-agent scenario:

• By entity — one subagent per distinct entity (the licensing-comparison example).
• By aspect — one subagent per dimension of analysis (a security review: one for authn, one for authz, one for input validation).
• By stage — one subagent per pipeline stage, dispatched sequentially (gather → extract → cross-reference).

By-entity and by-aspect parallelise naturally; by-stage is inherently sequential.

The Over-Narrow Failure Mode

The exam's favourite trap: a coordinator splits "compare three projects' licensing strategies" into twelve sub-tasks (per project per year) instead of three (per project). Each per-year subagent returns sensible facts, but none ever sees enough context to notice Project A's licensing changed in response to Project B's earlier move. The pattern is invisible at per-year grain and only emerges at 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; iterative refinement is the temporal side — how the coordinator uses subagent results across turns to improve the final answer.

Parallel Dispatch Mechanics

In one assistant turn the coordinator can emit multiple Task calls. The runtime fans them out, and when every parallel subagent reaches a terminal stop_reason, returns all results together as parallel tool_result blocks in the next user turn. Parallel dispatch collapses to sequential when sub-tasks have dependencies — the coordinator must wait for one result before writing the next brief.

The Iterative Refinement Loop

The first round of subagent results is rarely final. The loop: Plan → Dispatch → Aggregate → Evaluate → Refine → Synthesize, repeating Dispatch-through-Refine until the coordinator judges coverage adequate. Each iteration produces more targeted briefs because the coordinator now knows what earlier rounds missed. Tested under task statement 3.5; 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 ExamLab 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.