What you’ll be able to do
- Match manager/subagent, parallel, and sequential patterns to the task shapes that fit them
- Explain what the orchestration tax is and when it’s worth paying
- Design a fan-out/fan-in stage without losing partial failures
- Recognize when a single agent beats any multi-agent pattern
What you need to know
Three patterns, three different task shapes
Multi-agent orchestration isn't one thing with variations — it's three distinct patterns that solve different problems, and the exam consistently tests whether you can read a scenario's task shape and name the matching pattern.
- Manager/subagent (hierarchical) — one orchestrating agent delegates specialized subtasks to subagents and aggregates their results. Fits work that needs specialization or context isolation per subtask, and where the orchestrator has to make judgment calls about how to combine results.
- Parallel fan-out/fan-in — independent subtasks run concurrently, then their results are merged. Fits work that decomposes into pieces with no dependency between them — summarizing five unrelated documents, not five documents that build on each other.
- Sequential pipeline — each stage's output is the next stage's input. Fits work that's genuinely a pipeline: extract, then classify, then route. Forcing independent subtasks through a sequential pipeline just adds latency for no benefit.
The orchestration tax
Every additional agent hop costs a model call: latency, tokens, and a chance for the handoff itself to lose information. That cost is the orchestration tax, and it's paid whether or not the extra structure earned its keep.
The tax is worth paying when subtasks genuinely benefit from specialization (a subagent with a narrower, more focused context does that one thing more reliably) or from context isolation (keeping an unrelated subtask's noise out of the main agent's reasoning). It's not worth paying when the "subtasks" are really just steps a single agent with the right tools could do directly — that's orchestration for its own sake, and the exam rewards recognizing it as unnecessary.
Fan-out without losing partial failures
The failure mode specific to parallel fan-out is what happens when one branch fails while the others succeed. A naive implementation that requires all branches to succeed before proceeding turns one flaky subtask into a total outage.
Design the fan-in stage to handle partial results explicitly: which branches succeeded, which failed, and what the aggregator does with an incomplete set — proceed with a caveat, retry only the failed branch, or fail the whole operation. Silently dropping a failed branch's absence is its own bug: nobody downstream knows a third of the input never contributed.
Key concept
Manager/subagent, parallel, and sequential are answers to different questions about task shape — not interchangeable ways to look sophisticated. Pick by dependency structure, and pay the orchestration tax only where it buys something a single agent couldn’t.
When a scenario lists subtasks with no dependency between them, the pattern is parallel fan-out — not a pipeline, and not a manager delegating them one at a time.
Practice scenario
Work it through, then open this
The contracts are independent — nothing in contract three depends on contract two’s result. Running them one at a time behind a manager pays the orchestration tax (manager overhead) without getting anything for it, and it’s slower than it needs to be. This is a parallel fan-out/fan-in shape: run all five concurrently, aggregate results, and handle any branch that fails independently of the others.
Build exercise — Classify three orchestration scenarios
Intermediate · 20 min
What you’ll learn
- Reading dependency structure out of a task description
- Spotting orchestration tax paid for no benefit
- Designing a fan-in step that survives a partial failure
-
Take three hypothetical multi-step tasks and, for each, write down whether the steps depend on each other’s output.
- Why: Dependency structure is the actual signal for which pattern fits — not how many steps there are.
- You should see: Some steps that are genuinely sequential, and some that only look sequential out of habit.
-
For the task that’s actually independent, sketch a fan-out/fan-in design, including what happens if one branch errors.
- Why: The failure-handling design is usually skipped and is exactly what the exam probes.
- You should see: An explicit decision — proceed with partial results, retry the failed branch, or fail the whole run — rather than an assumption that everything always succeeds.
-
For the task that looks like it needs a manager, check whether two direct subagent calls from a single controller would do the same job without the extra hop.
- Why: A manager layer is itself an orchestration cost; it should be justified by real coordination need.
- You should see: Either a case where the manager earns its keep, or one where it’s an unnecessary layer.
Exam traps
Reaching for multi-agent orchestration because it sounds more sophisticated
Sophistication isn’t the goal. A single well-tooled agent that does the job is cheaper and more reliable than an orchestration layer that doesn’t earn its tax.
Fanning out independent subtasks sequentially out of habit
If nothing depends on anything else, running branches one at a time only adds latency.
Chaining stages sequentially when the subtasks don’t actually depend on each other
The same mistake in pipeline form — a sequential design applied to work that isn’t actually a pipeline.
Ignoring what happens when one branch of a parallel fan-out fails
A naive all-or-nothing join turns one flaky subtask into a total outage for unrelated work.
Adding a manager layer for two subagents that could just run directly
Every hop is a cost. A manager should coordinate real interdependency, not just exist as an org chart.