Multi-Agent Orchestration

Multi-agent orchestration = coordinating multiple agentic loops so specialized agents can work on separate parts of a larger task, then combining their results into one coherent outcome.

Multi-agent orchestration means one agent coordinating with others to complete complex work, with agents able to run in parallel using isolated context. Anthropic’s research-system writeup frames the same idea: a planner agent decomposes a complex research query, then creates parallel agents that search simultaneously; this introduces coordination, evaluation, and reliability challenges.

1. What the exam is likely testing

For D1.2, expect questions about architecture choice, not syntax trivia.

You need to know when to choose:

Need	Likely answer
Simple task, few steps, low ambiguity	Single agent
Fixed business process with strict ordering	Deterministic workflow
Complex open-ended task with independent subtasks	Multi-agent orchestration
Need domain specialists with different tools/prompts	Specialized agents
Need broad exploration or research	Parallel fan-out + synthesis
Need quality control	Generator + evaluator / critic
Need strict compliance	Programmatic guardrails override agent autonomy
Need long-running stateful execution	Persistent harness with durable state

High-yield exam principle:

Do not use multi-agent orchestration just because it sounds cool. Use it when task complexity, context isolation, specialization, or parallelism justifies the cost and coordination overhead.

Anthropic’s “Building effective agents” guidance says successful implementations often use simple, composable patterns, and warns that extra framework layers can obscure prompts/responses and encourage unnecessary complexity.

2. Core definition

A multi-agent system consists of multiple Claude-powered agents working together. Each agent may have its own: objective, system prompt, tools, context, model, skills, memory or state, permissions, output contract

A typical architecture:

User request
   ↓
Coordinator / orchestrator agent
   ↓
Task decomposition
   ↓
Specialist agents run in parallel or sequence
   ↓
Each agent returns structured findings
   ↓
Coordinator synthesizes, resolves conflicts, verifies completeness
   ↓
Final answer / action / artifact

A coordinator delegates to a set of subagents. Each subagent has its own model, system prompt, tools, and context, while the coordinator controls delegation.

3. The coordinator agent

The coordinator must have Agent in allowedTools to spawn subagents.

Each subagent is defined by an AgentDefinition with:

Field	Exam meaning
Description	Helps coordinator decide when to use the subagent
System prompt	Defines subagent behaviour
Tool restrictions	Scopes subagent permissions to its role

The coordinator is the manager of the system. It should not blindly do all the work itself.

Its responsibilities:

Responsibility	Meaning
Understand the user goal	Convert vague request into concrete work plan
Decompose task	Break work into independent or sequential subtasks
Select agents	Choose the right specialist for each subtask
Assign constraints	Give each agent clear scope, output format, and success criteria
Monitor progress	Track which subtasks are complete, blocked, or conflicting
Synthesize results	Combine findings into a coherent final response
Verify completeness	Check whether the original user goal was satisfied
Escalate	Ask user/human/system for approval when needed

Coordinator responsibilities that should be memorized:

Responsibility	Exam meaning
Dynamic subagent selection	Do not route every query through the full pipeline. Choose only needed subagents.
Research scope partitioning	Assign distinct subtopics or source types to reduce duplication.
Iterative refinement loops	Evaluate coverage, identify gaps, re-delegate targeted work, then re-synthesize.
Centralized communication routing	All inter-subagent information goes through coordinator.

The part I most underemphasized is iterative refinement. The coordinator is not just a dispatcher. It must inspect the combined output and ask: “Is coverage sufficient?” If not, it sends targeted follow-up work to the appropriate subagents.

Exam trap:

The coordinator should not merely concatenate subagent outputs. It must synthesize, reconcile, and verify.

All communication flows through the coordinator. Subagents never communicate directly with one another.

The exam will treat direct subagent-to-subagent communication as a trap, even if it sounds efficient. The reason is that coordinator-mediated communication gives:

Benefit	Why exam cares
Observability	All messages can be logged and monitored centrally
Consistent error handling	One place applies recovery policies
Controlled information flow	Coordinator decides exactly what context each subagent receives

So the exam answer is not “let agents collaborate freely.” It is centralize routing through the coordinator.

3.1 The “narrow decomposition failure”

A research system is asked about a broad topic, such as renewable energy technologies, but the coordinator decomposes the task only into solar and wind. The search agents do excellent work. The synthesis agent accurately combines what it receives. But the final report misses geothermal, tidal, biomass, fusion, etc.

The root cause is not: - weak search - poor synthesis - insufficient number of subagents - lack of sources

The root cause is:

The coordinator decomposed the task too narrowly.

Exam rule:

If output is incomplete in scope, trace the failure back to coordinator decomposition.

4. Specialist agents

A specialist agent is useful when the task benefits from a different prompt, tool set, model, or context boundary.

Examples:

Specialist	Purpose
Research agent	Search, collect sources, summarize evidence
Code agent	Modify code, inspect files, run tests
Security agent	Threat model, review permissions, inspect risky changes
Documentation agent	Write user-facing docs or release notes
Test agent	Generate and execute tests
Critic/evaluator	Check quality, correctness, completeness
Compliance agent	Check policy or regulatory constraints

Specialization is a core pattern: route work to agents with domain-focused system prompts and tools instead of loading one agent with every capability.

5. Context isolation

Context isolation is one of the strongest reasons to use multiple agents.

A single agent has one context window. If it reads every file, source, policy, and intermediate result, the context becomes noisy. With multiple agents, each subagent can work with a narrower context and return only high-signal output.

Each subagent has its own isolated conversation history; the coordinator can follow up with an earlier subagent. Tools and context are not shared between subagents. If subagents do share a workspace (filesystem or credentials), that sharing can still create security and coordination risks even though their conversation context is isolated.

Subagents do not automatically inherit the coordinator’s conversation history.

They also do not automatically receive: - the coordinator’s system prompt - previous coordinator messages - results from other subagents - shared memory - global state - prior invocation history

If the coordinator calls the same web-search subagent twice, the second call has no knowledge of the first unless the coordinator explicitly passes that information.

This is a major exam trap. When a subagent produces incomplete output, the first diagnostic question is: Did the coordinator pass enough context?

Do not immediately blame the subagent.

6. Parallel fan-out / fan-in

The most common multi-agent pattern is fan-out / fan-in.

Coordinator
   ├── Agent A: analyze source 1
   ├── Agent B: analyze source 2
   ├── Agent C: analyze source 3
   └── Agent D: analyze source 4

All return structured findings
   ↓
Coordinator synthesizes final answer

Use fan-out when subtasks are:

independent
similar in shape
bounded
parallelizable
not dependent on each other’s intermediate results

Good examples:

analyze 10 documents independently
search different repositories
compare vendor options
review separate modules
generate test cases for separate components

Bad examples:

create database schema, then implement API depending on that schema
perform financial transaction then audit it
update shared files with no locking/merge strategy
tasks requiring strict sequential approval

Parallelization is a strong pattern: fan out independent subtasks and have the coordinator synthesize results.

7. Specialization pattern

Use specialization when different subtasks require different capabilities.

Example:

Coordinator: "Prepare migration plan"

Research agent:
  - reads product docs
  - gathers constraints

Architecture agent:
  - designs migration options

Security agent:
  - reviews auth/data risks

Cost agent:
  - estimates cost and operational burden

Coordinator:
  - compares trade-offs
  - produces recommendation

High-yield decision rule:

Specialize agents by capability boundary, not by arbitrary task fragments.

Good specialization: - security reviewer with no write access - documentation writer with docs repo access - database analyst with read-only query tool

Bad specialization: - Agent 1 handles first paragraph, Agent 2 handles second paragraph - Every API endpoint gets its own agent even though one agent can reason over all of them - All agents have all tools just in case

8. Escalation pattern

Escalation means delegating a hard or risky subtask to a stronger agent, different model, human, or deterministic system.

Examples:

Scenario	Escalation target
Cheap model cannot resolve ambiguity	More capable model
Agent wants to execute risky command	Human approval
Compliance policy is involved	Compliance checker / deterministic rule engine
Conflicting source evidence	Critic / evaluator agent
Security-sensitive code change	Security reviewer

Escalation is a valid multi-agent pattern: consult a more capable agent or model for a subset of complex subtasks.

When escalating to a human, the human agent does not have the full conversation transcript. Therefore, the handoff must be self-contained and include Conversation history, recommended action and other relevant data.

Exam trap:

Escalation is not the same as retrying. Escalation changes authority, capability, or review level.

9. Generator–evaluator pattern

This is a very important architecture pattern.

Planner agent:
  defines task and success criteria

Generator agent:
  creates artifact / code / answer

Evaluator agent:
  checks against criteria

Generator:
  revises

Coordinator:
  accepts final result

Anthropic’s harness-design writeup describes a planner, generator, and evaluator architecture for long-running application generation, using structured criteria and handoff artifacts to improve outcomes. (Anthropic)

Use this when quality matters and output can be evaluated:

code generation,
design generation,
data migration planning,
policy analysis,
test generation,
architecture review.

Exam trap:

An evaluator agent should use explicit criteria. “Ask another agent if it looks good” is weaker than “evaluate against acceptance criteria, tests, security requirements, and source evidence.”

10. Sequential handoff pattern

Sequential handoff is not the same as parallel fan-out.

Agent A: investigate
   ↓
Agent B: design
   ↓
Agent C: implement
   ↓
Agent D: test
   ↓
Coordinator: final synthesis

Use sequential handoff when each step depends on the previous result.

The handoff should be structured:

{
  "objective": "Implement OAuth callback validation",
  "completed_work": ["Reviewed auth flow", "Identified missing state validation"],
  "remaining_work": ["Add state token verification", "Add tests"],
  "files_changed": ["auth/callback.ts"],
  "risks": ["Backward compatibility with old sessions"],
  "evidence": ["test failure output", "source file references"],
  "next_agent_instructions": "Implement only the missing validation and tests."
}

Anthropic’s long-running harness work emphasizes structured artifacts, clean state, progress files, and incremental handoffs so later agents can understand the work quickly after context resets. (Anthropic)

11. Multi-agent vs deterministic workflow

This is a major exam distinction.

Architecture	Best for
Deterministic workflow	Known steps, strict order, compliance, repeatability
Single agent	Flexible reasoning but small enough for one context
Multi-agent	Flexible, complex, decomposable work
Hybrid	Agent proposes plan; deterministic system enforces policy

Examples:

Scenario	Best choice
“Always validate identity, then check balance, then issue refund under $50”	Deterministic workflow
“Research unknown causes of latency across services”	Multi-agent
“Summarize one support ticket”	Single agent
“Generate migration plan, then require human signoff before execution”	Hybrid
“Analyze 30 independent files”	Multi-agent fan-out
“Perform irreversible deletion”	Deterministic approval gate

Exam principle:

Multi-agent orchestration gives flexibility. Deterministic workflows give control. Use each where it belongs.

12. Tool and permission boundaries

A common exam distractor is giving every agent every tool. That is usually wrong. Better pattern:

Agent	Tools
Researcher	read-only search, document fetch
Coder	file edit, test runner
Security reviewer	read-only repo, static analysis
Deployer	deployment tool, but only after approval
Coordinator	delegation and synthesis, not necessarily all operational tools

Tools and MCP servers should be agent-scoped: declare only the tools and servers each agent needs in that agent’s definition.

Security principle:

Least privilege applies per agent, not just per application.

Anthropic’s containment guidance says agent systems need hard environmental boundaries such as sandboxes, filesystem boundaries, and egress controls, because model-level defenses alone cannot be the only protection. (Anthropic)

13. Shared workspace risks

Multi-agent systems can fail when agents step on each other.

Common risks:

Risk	Mitigation
Two agents edit same file	Locking, branch isolation, merge coordinator
Agents duplicate work	Coordinator task registry
Conflicting conclusions	Synthesizer reconciles evidence
Hidden subagent failure	Structured status and error reporting
Tool permission deadlock	Central permission handler
Context leakage	Scoped prompts and minimal context handoff
Cost explosion	Concurrency caps and task budgets
Infinite delegation	Max subtask count / max depth

Exam principle: cap fan-out breadth, depth, and concurrency to prevent runaway cost and uncontrolled delegation.

14. Synthesis is not summarization

Synthesis means:

combine findings
remove duplicates
identify disagreements
decide which evidence is stronger
fill gaps
map findings back to the original task
produce final answer with caveats

Bad coordinator output:

Agent A said...
Agent B said...
Agent C said...

Good coordinator output:

The strongest recommendation is Option B because Agents A and C independently found
lower migration risk, while Agent B's cost concern applies only to the legacy connector.
The unresolved risk is auth compatibility; next step is a targeted spike.

Exam trap:

If the answer says “combine all subagent outputs directly,” it is probably weaker than “synthesize, reconcile, and verify.”

15. Failure handling

Multi-agent systems add new failure modes.

Failure mode	Correct handling
One subagent fails	Retry, reassign, or continue with caveat depending on criticality
Conflicting outputs	Coordinator requests evidence or sends to evaluator
Agent exceeds scope	Enforce task contract and discard irrelevant output
Missing source/evidence	Ask subagent for evidence or rerun with stricter output schema
Tool permission required	Route permission event to user/human approval
Subagent loops	Cap iterations / terminate thread
Partial completion	Return partial result with known gaps or continue targeted work

Blocking permission events should be routed back to the correct subagent/thread that raised them, so the right context resumes once the decision is made.

16. Cost and latency

Multi-agent systems can be faster but are more expensive in total tokens.

Use multi-agent orchestration when the benefit outweighs:

extra prompts
extra context
duplicate reasoning
synthesis overhead
coordination overhead
harder debugging
larger blast radius

Anthropic’s orchestration-mode example explicitly warns that fan-out multiplies token usage and should be reserved for work that justifies the cost. (Claude Platform)

Exam heuristic:

Requirement	Good answer
Need fastest answer to simple question	Single agent
Need broad exploration across independent sources	Parallel agents
Need predictable low cost	Avoid broad fan-out
Need high confidence in complex output	Generator + evaluator
Need strict budget	Limit subtask count and concurrency

17. High-yield exam traps

Trap	Why wrong	Better answer
“Use multi-agent for every hard task”	Adds cost and coordination complexity	Use only when decomposable/specialized
“Give every agent all tools”	Violates least privilege	Scope tools per agent
“Parallelize dependent tasks”	Causes invalid assumptions	Use sequential handoff
“Concatenate subagent outputs”	No synthesis or conflict resolution	Coordinator synthesizes
“Use evaluator with no criteria”	Weak evaluation	Use explicit rubric/tests
“Use model judgment for compliance”	Probabilistic enforcement	Programmatic guardrails
“Ignore failed subagent”	Hidden quality risk	Retry, reassign, or report gap
“Let agents edit same files freely”	Merge conflicts and overwrites	Isolate, lock, or coordinate writes
“Fan out without cap”	Cost/runaway risk	Concurrency and subtask caps
“Share full context with all agents”	Noise and leakage	Minimal scoped context

18. D1.2 decision checklist

When you see a scenario, ask:

Is the task decomposable?
If not, prefer single agent.
Are subtasks independent?
If yes, fan-out. If no, sequential handoff.
Do subtasks need different expertise or tools?
If yes, specialist agents.
Is there a high-risk action?
Add deterministic approval or policy gate.
Is quality hard to verify?
Add evaluator/critic with explicit criteria.
Is context becoming noisy?
Use context-isolated subagents or structured handoffs.
Could cost explode?
Add max subtask count, max concurrency, and budget.
Could agents interfere with each other?
Add file/workspace isolation, locks, or coordinator-controlled writes.
Is a compliance-critical decision involved?
Enforce it with a deterministic guardrail, not model judgment.
Does the final answer require coherence?
Coordinator must synthesize, not concatenate.

19. Reference architecture examples

Example A: Multi-agent research assistant

Coordinator:
  - understands research question
  - creates 4 research angles

Researcher A:
  - public web evidence

Researcher B:
  - internal docs

Researcher C:
  - competitor/product evidence

Researcher D:
  - risks and counterarguments

Evaluator:
  - checks source quality and contradictions

Coordinator:
  - synthesizes final answer with confidence and gaps

Best for open-ended research where the path cannot be fully hard-coded.

Example B: Multi-agent coding workflow

Planner:
  - decomposes feature into tasks and acceptance criteria

Coder:
  - implements one task at a time

Test agent:
  - writes and runs tests

Reviewer:
  - reviews code quality and security

Coordinator:
  - decides whether to merge, revise, or escalate

Best for long-running development when you need incremental progress and verification.

Example C: Compliance-sensitive support agent

Support coordinator:
  - classifies request

Research agent:
  - retrieves customer/order details

Policy agent:
  - checks refund policy

Action executor:
  - can issue refund only after deterministic approval gate

Coordinator:
  - responds to user

Key exam point: the refund rule is enforced outside model judgment.

Scenario-Based Questions

Q1. Single vs multi-agent

A user asks Claude to summarize one short support ticket and suggest a response. The team proposes a coordinator, researcher, policy agent, tone agent, and reviewer. What is the best exam answer?

A. Use all five agents because specialization always improves quality
B. Use a single agent unless there is evidence the task needs decomposition
C. Use no model because support tickets cannot be summarized
D. Use parallel fan-out to reduce cost

Answer

B. Multi-agent orchestration adds overhead. A simple task should stay single-agent.

Q2. Parallel fan-out

A legal team needs to review 40 independent contracts for the same clause. Each contract can be analyzed separately. What architecture is best?

A. One agent reads all contracts in one context
B. Parallel specialist agents analyze separate contracts, then coordinator synthesizes
C. Hard-code a fixed response without reading contracts
D. Ask the user to paste summaries

Answer

B. Independent, similar subtasks are ideal for fan-out/fan-in.

Q3. Sequential dependency

A coding workflow needs to design a schema before implementing APIs that depend on it. What is the best orchestration pattern?

A. Run schema design and API implementation in parallel
B. Sequential handoff from design agent to implementation agent
C. Give both agents no context
D. Let the reviewer implement everything

Answer

B. Dependent tasks should be sequenced.

Q4. Tool least privilege

A documentation agent needs only read access to source files and write access to docs. The proposed design gives it deployment credentials. What is wrong?

A. Nothing; all agents should share all tools
B. The agent violates least privilege
C. The coordinator should parse natural language instead
D. The agent needs a larger model

Answer

B. Tool access should be scoped to the agent’s responsibility.

Q5. Coordinator synthesis

Three research agents return findings with conflicting recommendations. What should the coordinator do?

A. Paste all three outputs into the final answer unchanged
B. Pick the longest answer
C. Reconcile conflicts using evidence and note uncertainty
D. Ignore all conflicting findings

Answer

C. The coordinator must synthesize and resolve conflicts.

Q6. Arbitrary over-decomposition

A team creates one agent per paragraph for a one-page memo. What is the problem?

A. The task is decomposed by arbitrary surface structure, not capability or independence
B. Multi-agent systems cannot write text
C. The coordinator should force all tools
D. Each paragraph needs its own model

Answer

A. Agent boundaries should reflect meaningful work boundaries.

Q7. Generator–evaluator

A team wants Claude to build a migration plan and catch missing risks before sending it to leadership. Which pattern is strongest?

A. Generator only
B. Generator plus evaluator using explicit criteria
C. Two generators that never compare results
D. One agent with no acceptance criteria

Answer

B. Evaluation should be criteria-driven.

Q8. Compliance gate

A multi-agent finance assistant can approve payments. The compliance rule says payments above $10,000 require human approval. What is the best design?

A. Let the payment agent decide whether approval is needed
B. Add a deterministic approval gate before executing payment
C. Ask the agent to say “I promise to comply”
D. Use more subagents

Answer

B. Compliance-critical behavior should be enforced programmatically.

Q9. Context isolation

A single agent reviewing a large repo becomes confused after reading unrelated files. What architectural change may help?

A. Split work into scoped specialist agents with isolated context
B. Add all files to the system prompt
C. Remove the coordinator
D. Force tool_choice: any

Answer

A. Context-isolated agents reduce noise.

Q10. Escalation

A lightweight model cannot resolve a complex security trade-off. What is the best use of escalation?

A. Retry the same model indefinitely
B. Consult a stronger security-review agent or human expert
C. Ignore the issue
D. Force the lightweight model to approve

Answer

B. Escalation changes capability or authority.

Q11. Fan-out cost

A user asks a simple factual question. The system launches 20 agents by default. Latency improves slightly, but cost explodes. What is the best fix?

A. Use fan-out only when task complexity justifies it
B. Increase max concurrency
C. Remove all limits
D. Launch 40 agents instead

Answer

A. Fan-out multiplies work and should be justified.

Q12. Best architecture selection

A user asks: “Analyze our app for accessibility, security, and performance issues, then prioritize fixes.” What is the best architecture?

A. One agent with every tool and no structure
B. Coordinator delegates to accessibility, security, and performance specialists, then synthesizes priorities
C. Deterministic password reset workflow
D. Calculator-only agent

Answer

B. This is naturally decomposable by specialist domain.

Q13. Dynamic subagent selection

A user asks a simple factual question. The system invokes search, document analysis, critique, synthesis, and report-generation agents every time. What is wrong?

A. It violates dynamic subagent selection
B. It improves reliability by default
C. It is required by hub-and-spoke architecture
D. It is the only way to preserve context

Answer

A. The coordinator should invoke only the subagents needed for the task.

Q14. Scope partitioning

A coordinator launches five research agents, all with the same prompt: “Research renewable energy.” The results are duplicative. What should the coordinator do instead?

A. Remove the coordinator
B. Partition the research scope into distinct subtopics or source types
C. Let agents communicate directly
D. Force the synthesis agent to invent missing sections

Answer

B. Scope partitioning minimizes duplication and improves coverage.

D1.2 memory hooks

Multi-agent is for decomposable complexity, not prestige.
Coordinator decomposes, delegates, monitors, synthesizes, and verifies.
Specialize by tools, expertise, model, or context boundary.
Parallelize independent tasks; sequence dependent tasks.
Structured handoffs beat free-form prose.
Synthesis is not concatenation.
Evaluator agents need explicit criteria.
Least privilege applies per agent.
Compliance rules belong in deterministic guardrails.
Fan-out increases cost, so cap breadth, depth, and concurrency.