AnthropicClaude Certified Architect – Professional2026-101.4 Design multi-agent systems and orchestration strategies
Choose who controls the agent graph
Completed by the knowledge check
Learning objective
Compare coordinator-subagent, sequential pipeline, hierarchical, and peer-messaging topologies for control, observability, and failure isolation.
Core idea
For an architect choosing an orchestration graph, the important difference is who can assign work, communicate findings, and accept completion. Coordinator-subagent execution centralizes those decisions. A pipeline orders them through stage gates. A hierarchy delegates some decisions to intermediate coordinators. Peer messaging permits lateral coordination while retaining an explicit owner of the overall result.
These are design patterns, not interchangeable product modes. Anthropic documents orchestrator-workers and prompt chaining, SDK nested subagents and messaging, and experimental Claude Code agent teams. Choose the control structure first, then verify that the runtime supports the particular communication and lifecycle you intend.
How it works
Centralize variable work in a coordinator
The coordinator-subagent pattern suits requests whose necessary branches vary with the input. Anthropic’s orchestrator-workers pattern places decomposition and synthesis in a central model. Central routing gives the architecture owner one place to check whether assignments cover the goal and whether returned evidence is sufficient.
The cost is an aggregation bottleneck. Every scope change or cross-worker dependency that you route centrally consumes coordinator attention and context. Keep large evidence in accessible artifacts with concise references, as Anthropic’s research system describes, while retaining central acceptance authority. Central control does not require every artifact byte to pass through the lead’s conversation.
For an SDK implementation, use the explicit capability contracts in 1.4.3 to prevent workers from delegating or messaging peers when the hub must be strict. Otherwise a nominal coordinator diagram can conceal a different runtime graph. Trace actual delegation relationships through parent_tool_use_id, rather than assuming that every specialist is a direct child of the root. In TypeScript SDK v0.3.292 or later, assistant and user messages inside a subagent also carry agent_id, matching its task events’ task_id; use that identity to connect branch activity to task outcomes.
Gate fixed dependencies in a pipeline
A sequential pipeline fits stable stages whose outputs define the next stage’s inputs. Anthropic’s prompt-chaining pattern allows programmatic checks between calls. An extraction stage, evidence check, and publication stage can each have a separate acceptance gate.
Control resides in the scheduler and those gates rather than discretionary worker selection. Observability follows stage input, accepted output, and rejection reason. Failure isolation means preserving accepted upstream output while withholding downstream work that depends on the rejected stage. Rerunning publication cannot repair extraction evidence that never passed its check.
This structure trades additional sequential latency for focused stages and inspectable transitions. A pipeline is a workflow; its stages do not each need an autonomous agent loop. Creating an agent per stage without a useful local investigation adds coordination while retaining the same serial dependency. Use a pipeline where the intermediate contract improves acceptance, rather than because the deliverable has several verbs in its description.
Delegate planning through a bounded hierarchy
A hierarchy lets an intermediate coordinator own a substantial branch and split it further. For example, a migration lead can delegate database analysis to a branch lead that commissions independent schema and workload investigations. The root receives a branch result without planning every leaf itself.
The Agent SDK supports nested subagents. Set CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH through env to bound the tree: the default is 3 layers below the main agent, 2 permits two layers, and 1 prevents worker-created children. The documented limit configuration applies to TypeScript SDK v0.3.219 and Python SDK v0.2.127 onward, bundling Claude Code v2.1.219 or later.
A hierarchy adds acceptance boundaries and opportunities to lose evidence during summarization. Record which branch lead accepted which leaf result and preserve unresolved leaf obligations in the branch report. A root that sees only “database ready” cannot distinguish a completed assessment from a missing workload investigation.
Do not assume a branch summary proves descendants have ended. Anthropic documents that in the Agent SDK and non-interactive mode, a launching subagent does not wait for its nested background subagents; a child finishing after its launcher ends reports to the main conversation instead. Interactive Claude Code waits for nested background results. Verify settlement at the intended branch boundary rather than importing interactive lifecycle assumptions into a service.
In the Agent SDK, a launching subagent can end before its nested background subagent, which then reports to the main conversation instead.
Permit lateral collaboration deliberately
Peer messaging fits sustained investigations where workers need to exchange evidence or challenge hypotheses. An SDK subagent with SendMessage can communicate with other named agents. A message is a communication path; it does not establish who accepts a deliverable or whether every required task has completed.
Claude Code agent teams provide a richer collaboration surface: teammates have separate contexts, direct messaging, and, when the session has the Task tools, a shared task list. Teams are experimental and disabled by default. Enable them with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1; teammate spawning requires an interactive session. Non-interactive -p and Agent SDK sessions do not spawn teammates, even with that variable enabled.
Peer control needs visibility into lateral exchanges as well as parent-child relationships. A teammate’s “done” message and a task’s completion status must agree with the deliverable. The teams documentation warns that task status can lag and that /resume and /rewind do not restore in-process teammates. It also prohibits nested teams. Evaluate those lifecycle constraints before relying on teams for unattended completion.
Key distinctions and trade-offs
The four patterns distribute responsibility differently:
| Topology | Control | Observability focus | Failure boundary |
|---|---|---|---|
| Coordinator-subagent | One owner assigns and accepts branches | Assignment-to-result links and root coverage | Retain independent branches; root chooses recovery |
| Sequential pipeline | Scheduler advances accepted stages | Stage gates and the inputs they accepted | Stop dependent stages; retain accepted upstream output |
| Hierarchical | Root delegates local planning to branch leads | Root-to-branch-to-leaf attribution and acceptance | Recover a leaf or branch without hiding descendant gaps |
| Peer messaging | Workers coordinate laterally; one owner accepts the whole | Message dependencies, task ownership, and completion evidence | Quarantine affected shared conclusions, not only one transcript |
Separate contexts isolate conversation content. They do not prevent file conflicts: the agent-teams documentation advises assigning distinct file ownership because same-file edits can overwrite work. The chosen communication topology must therefore agree with resource ownership and result acceptance.
Architecture / decision scenario
A technology company has six engineers and a two-week deadline to assess a service migration. Its unattended assessment service uses the Agent SDK, and the final recommendation must expose every unassessed dependency.
You choose a coordinator-subagent graph for independent service investigations because one owner can enforce coverage. A fixed pipeline then checks evidence and produces the recommendation only after those gates pass. You reject a wholly sequential research schedule because the service assessments do not require one another’s findings.
Database assessment may justify a two-layer hierarchy if its branch lead preserves schema and workload evidence and descendant settlement. If that contract adds little beyond two direct assignments, keep the graph shallow. Instrument parent relationships and branch acceptance so a missing leaf cannot disappear into a successful branch summary.
Engineers also want peers to debate competing failure hypotheses. Use a separately supervised interactive team experiment if its collaboration benefit warrants the experimental lifecycle. Do not assume enabling teams changes the unattended SDK service into that mode. If the service permits SDK SendMessage, retain explicit final acceptance and record the lateral dependencies that make a result stale after a peer fails.
Common exam traps
- Recording only parent-child links while peer-message dependencies remain invisible.
- Treating a sequential workflow as proof that every stage needs an autonomous agent.
- Accepting a branch summary without accounting for still-running descendants.
- Assuming SDK peer messaging and interactive agent teams have the same lifecycle.
- Treating agent teams as generally available or supported in unattended SDK sessions.
- Confusing conversation isolation with independent file ownership.
What to remember
Choose a graph whose decision authority matches the work’s dependencies. Centralize variable coverage, gate fixed stages, bound local hierarchies, and permit peer exchanges only with visible ownership and completion rules. Verify the actual runtime graph and its lifecycle before defending the design.
Knowledge check
An unattended migration-assessment service runs on the Agent SDK. The team sets CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 in the service’s environment so that peers can debate failure hypotheses through a shared task list. What happens when the service’s lead agent tries to bring peers into the debate?
In an Agent SDK service, a database branch lead launches background subagents for schema and workload analysis, which the assessment requires, and then returns the summary “database ready” to the root. What must the root do before accepting the branch?
1 before rerunning the branch lead1 would prevent it from commissioning the required analyses.A publication pipeline has three stages, each with its own acceptance gate: source retrieval, claim extraction and publication. Retrieval passes its gate, but the extraction gate rejects the output because two claims lack supporting evidence. What should the scheduler do?
In a supervised interactive agent-team experiment, two teammates are both assigned changes that touch the same configuration file. Each teammate works in its own context window. What prevents one teammate’s edits from overwriting the other’s?
References
- Anthropic, Building effective agents
- Anthropic, How we built our multi-agent research system
- Anthropic, Subagents in the SDK
- Anthropic, Create custom subagents
- Anthropic, Orchestrate teams of Claude Code sessions