What you need to know
A multi-agent system splits work between two roles.
- The orchestrator owns the goal. It breaks the work into sub-tasks, decides what to delegate, and combines the results into one answer. It coordinates rather than doing the sub-task work itself.
- Subagents own scoped sub-tasks. Each runs in its own context window, completes one piece, and returns a result to the orchestrator.
When it is worth it
Multiple agents help when the work is broad and separable: many sources to research, many documents to review, many independent directions to explore. Each subagent gets a clean context focused on its piece, so the work is not squeezed into one crowded window, and independent pieces can run in parallel.
They cost more. Every subagent carries its own instructions and context, so token use rises sharply compared with a single agent, and coordination adds latency and new failure points. Anthropic's write-up of its research system reports that multi-agent runs used many times the tokens of a chat interaction. That trade is worth making for high-value, parallel work and wasteful for tightly coupled tasks where every step depends on the last.
Three things you must design, not assume
- Decomposition. How the goal is split, and how much each subagent is told. Vague task descriptions lead to duplicated work or gaps; each subagent needs a clear objective, boundaries and an expected output.
- Result structure. Subagents should return results in a consistent, structured format, so the orchestrator can combine them without guessing.
- Conflict resolution. When two subagents disagree or leave a gap, the orchestrator needs an explicit rule (prefer the more authoritative source, flag the conflict, or escalate to a person) rather than silently picking one.
Failures are not equal
Where a failure happens decides whether it can be recovered.
| Failure | Where it lands | Design response |
|---|---|---|
| A subagent returns nothing or malformed output | The subagent boundary: recoverable | Validate every result; retry or reassign the unit; record the gap instead of failing the whole run |
| Subagents return conflicting results | The synthesis step: recoverable | Apply a stated conflict rule or escalate |
| The orchestrator loses its goal or its partial synthesis | The orchestrator: often unrecoverable | Checkpoint its state so a run can resume rather than restart |
| Traces scatter across agents | Observability: affects everything | Pass one trace ID through every agent so a run can be reconstructed |
Two practical consequences follow. Make subagent work idempotent, so a retry cannot double-apply an effect. And reconcile coverage at synthesis: the number of results should equal the number of units sent out, so a silently dropped subagent is noticed.
In the exam
Questions in this area usually present a working multi-agent design with one weakness: missing trace IDs, no conflict rule, no validation of subagent output, no checkpoint, or no check that every unit came back. Pick the option that fixes the stated weakness at the right boundary. If the scenario asks whether to use multiple agents at all, weigh independence of the sub-tasks against the extra token cost.
Check your understanding
When does a multi-agent design most clearly justify its extra token cost?
Show answer
Answer: C. Subagents pay off when work is broad and separable, because each gets a focused context and they can run in parallel. Tightly sequential or latency-critical work is cheaper and simpler with one agent or a workflow.
A research run's orchestrator crashes after 40 of 60 subagents have returned. Which design would have limited the damage most?
Show answer
Answer: B. Subagent failures are recoverable at their boundary; losing the orchestrator's state is not. Checkpointing lets the run resume with the 40 results it already has instead of starting again.
A due-diligence report covers 97 of 100 contracts and nobody notices. Which control would have caught it?
Show answer
Answer: A. A coverage check at synthesis (results received equals units dispatched) makes a silently dropped subagent visible. Spot checks and better models can still miss three missing results.
Apply it: Plan the migration audit
Quillstone's platform team must audit all 160 services for the deprecated logging library within two weeks. By hand that is about 400 engineer-hours. Design a multi-agent audit that a platform engineer could run and trust.
- Decide whether multi-agent fits. Use the independence of the work units to justify it, and name what the orchestrator does and does not do.
- Define the subagent's task and its result format. List the fields every subagent must return.
Why: the orchestrator can only combine results that share one structure.
Done when: a "not sure" answer is possible and carries evidence. - Build the failure matrix. For at least four failures, say where each lands and the design response.
- Make coverage provable. Say how the final report shows that all 160 services were audited, and what happens to the ones that were not.
Show model answer
1. Fit. Each service can be audited without knowing anything about the others, so the work is broad and separable: a good fit for parallel subagents with clean, focused contexts. The orchestrator reads the service catalogue, sends one task per service, validates and combines results, and writes the report. It does not audit code itself.
2. Task and result format. Task: "Audit service X in repository Y for use of the old logging library. Read only; change nothing." Each subagent returns:
| Field | Values |
|---|---|
| service, repository, owning team | From the catalogue |
| uses_old_library | yes / no / unclear |
| call_sites | Number found |
| patterns | e.g. direct calls, wrapper class, configuration only |
| risk | low / medium / high, with a one-line reason |
| evidence | File paths and line numbers |
| confidence | high / medium / low |
3. Failure matrix
| Failure | Where it lands | Response |
|---|---|---|
| Subagent returns empty or malformed output | Subagent boundary | Validate against the format; retry once; then mark "needs human audit" |
| Repository too large for one context | Subagent | Split by module; one subagent per module, merged per service |
| Two runs disagree on a service | Synthesis | Rule: "yes" with evidence beats "no"; otherwise flag for the owning team |
| Orchestrator crashes mid-run | Orchestrator | Results written to storage as they arrive; the run resumes from the checkpoint |
| Results cannot be traced to a run | Observability | One run ID and the subagent's task ID on every result |
4. Coverage. The report opens with a reconciliation line: 160 services in the catalogue, results received for N, validated M, and the list of services marked "needs human audit". Nothing is reported as complete until the counts match. The access is read-only throughout, which keeps the audit within Quillstone's production-access rules.