1.4 · Lesson 4 of 6
Design multi-agent systems and orchestration strategies
What You Need to Know
Multi-agent orchestration is an accountability design, not a fashion choice. A coordinator owns decomposition, routing, aggregation, and visibility. Specialists stay narrowly scoped — ideally with non-overlapping tools — and receive only the context they need through explicit handoffs. Subagents do not inherit the parent conversation; assuming shared memory is a common failure mode that looks like "the model forgot" when the architecture never passed the fact.
Prefer hub-and-spoke over peer meshes. When specialists message each other directly, the coordinator loses the audit trail and cannot synthesize reliably. Multi-agent pays for itself when you need role isolation (different authZ or blast radius) or parallel specialization — not when a single progressive agent would finish the same job with less moving parts.
Coordinator vs specialist
- Coordinator: plan, route, aggregate, expose status, own user-facing synthesis
- Specialists: narrow goals, narrow tools, structured outputs, no peer side-channels
- Handoffs: typed contracts — goal, constraints, allowed sources, response schema
- Visibility: every inter-agent message is observable at the hub
Decision rules
- Coordinator owns decomposition, routing, aggregation, and visibility.
- Specialists stay narrowly scoped; prefer non-overlapping tool sets.
- Pass context as explicit handoff contracts — never assume inherited memory.
- Hub-and-spoke beats peer-to-peer chatter for audit and synthesis.
- Choose multi-agent only when role isolation or parallel specialization justifies the cost.
Why orchestration failures look like model failures
When specialists chat off-hub or share a global transcript, wrong facts enter synthesis without provenance. Teams then raise temperature, add tools, or lengthen prompts. The professional fix is architectural: restore the hub, shrink scopes, and make handoffs complete enough that a specialist can succeed without secret history.
Design checklist
- Can you name who owns aggregation and the final answer?
- Is every specialist edge a typed request/response?
- Would a peer mesh hide which agent saw which fact?
- Does multi-agent buy isolation or parallelism you cannot get with one agent?
- If you removed peer channels tomorrow, what workflows would break?
Exam stems that show lost visibility after specialists talk directly key on restoring coordinator-mediated handoffs. Distractors include shared memory, peer meshes, dumping more tools onto specialists, and multi-agent-by-default.
Exam application
Prefer answers that keep the coordinator in the path with explicit context contracts. Reject inherited global memory, peer-to-peer meshes, and "add tools" as substitutes for orchestration. Multi-agent must be justified, not assumed.
Exam traps
Shared global conversation memory across specialists
Subagents do not inherit history by design. Assumed shared memory hides provenance and makes wrong context look like model failure.
Peer-to-peer specialist mesh without a hub
Hub-and-spoke keeps decomposition, routing, and aggregation observable. Peer chatter loses accountability on exam stems.
Multi-agent by default for every workflow
Multi-agent is justified by role isolation or parallel specialization — not by fashion. A single well-scoped agent often wins.
Adding tools instead of fixing orchestration
When visibility or synthesis fails, the fix is handoff contracts and coordinator ownership — not a larger toolkit.
Practice scenario
A research platform uses a coordinator plus three specialists. Traces show specialists messaging each other directly to "save a hop," and the coordinator can no longer reconstruct which facts each specialist saw. Tool-call success is fine, but audit and synthesis quality are falling. What should the architect do first?
Build exercise
Design coordinator + two specialists for a research platform
40 minutes
What you'll learn
- Separate coordinator ownership from specialist scope
- Write explicit handoff contracts (no inherited memory)
- Enforce hub-and-spoke messaging for visibility
- Justify multi-agent with isolation or parallelism
Step 1
Define coordinator responsibilities and specialist scopes
Write what the coordinator owns (decompose, route, aggregate, expose status) and what each specialist is allowed to do. Keep specialist tool sets narrow and non-overlapping where possible.
Why: Exam items reward role isolation. Vague "helpers" recreate a mega-agent under another name.
You should see: A one-page role map: coordinator duties plus two specialists with explicit in/out of scope.
Step 2
Design explicit handoff contracts
Specify the payload each specialist receives and returns: goal, constraints, allowed sources, output schema, and what must not be assumed from prior turns.
Why: Context is a contract, not inheritance. Missing fields are the root cause of silent wrong synthesis.
You should see: JSON (or typed) handoff schemas for request and response on each specialist edge.
Step 3
Enforce hub-and-spoke messaging
Require specialists to talk only to the coordinator. Log every handoff. Forbid direct specialist-to-specialist channels in the design.
Why: Hub-and-spoke restores audit trails and keeps aggregation owned by one place.
You should see: A sequence diagram with only coordinator↔specialist edges and a handoff log sample.
Step 4
Justify multi-agent with a go/no-go checklist
Document why role isolation or parallel specialization is required. If neither applies, collapse to one agent and re-measure.
Why: Architects must defend multi-agent cost and complexity. Default single-agent is often correct.
You should see: A written go/no-go with pillars (isolation, parallelism) and a rejected single-agent alternative.
Sources
- Tool use overview — docs.anthropic.com — scoped tools per role
- Agent Skills overview — docs.anthropic.com — modular capability packaging
- Context windows — docs.anthropic.com — why handoffs must be explicit