Multi-agent orchestration & coordinator–subagent patterns
Orchestrate multi-agent systems with coordinator-subagent patterns.
This subtopic (1.2) sits in Agentic Architecture & Orchestration (D1) on Anthropic's Claude Certified Architect — Foundations (CCA-F) exam. The bank holds 24 practice questions here — 6 easy, 11 medium, and 7 hard — with 5 free to try, answers and explanations included. 3 of the free questions are below; the rest are in the practice stream.
What the exam tests here
- risks of overly narrow task decomposition — incomplete topic coverage
- subagents operate with isolated context — do not inherit coordinator history
- hub-and-spoke architecture — coordinator manages all inter-subagent communication
- coordinator role — task decomposition, delegation, result aggregation
Free practice questions: Multi-agent orchestration & coordinator–subagent patterns
A coordinator decomposes every support request into separate subagents for returns, billing, and account issues. After launch, escalate_to_human fires frequently for mixed-topic requests. What is the most likely cause?
Show answer & explanation
Correct answer: B. Each subagent handles only its assigned topic, leaving cross-topic requests unresolved.
Overly narrow task decomposition means no subagent owns mixed-topic requests, so none resolves them and escalation fills the gap. 'escalate_to_human tool has an incorrect threshold' targets configuration, not decomposition design. 'missing access to lookup_order' is a tool-permission issue unrelated to topic coverage. 'coordinator system prompt does not mention billing' is a prompt-content issue, not a decomposition gap.
Your support system uses a hub-and-spoke coordinator that routes requests to specialized subagents. A billing subagent needs data from a returns subagent before calling process_refund. How should this inter-subagent dependency be handled?
Show answer & explanation
Correct answer: A. Have the coordinator request returns data first, then pass it to the billing subagent for the process_refund call.
In hub-and-spoke, the coordinator owns all inter-subagent communication — subagents never call each other directly. 'Allow the billing subagent to call the returns subagent directly' breaks the hub-and-spoke contract, creating peer coupling. 'Configure process_refund to internally fetch' conflates tool responsibility with orchestration logic. 'Shared memory store' introduces coordination state outside the coordinator, bypassing centralized control.
The coordinator agent must aggregate results from get_customer and lookup_order before deciding whether to call process_refund or escalate_to_human. Which decomposition strategy best preserves this dependency while minimizing latency?
Show answer & explanation
Correct answer: C. Run get_customer and lookup_order in parallel, then branch on combined results to call the appropriate downstream tool.
get_customer and lookup_order have no dependency on each other, so parallel execution satisfies both inputs while reducing round-trip latency before the coordinator branches. 'Run get_customer and lookup_order sequentially' adds unnecessary wait time when the calls are independent. 'Delegate the full resolution flow' collapses coordinator control, losing the ability to apply branching logic at the aggregation point. 'Call process_refund optimistically' risks irreversible financial side effects before identity is confirmed.
2 more free questions on this subtopic in the practice stream, plus 19 in the full bank. Keep practicing →