1.4 Multi-Agent Systems & Orchestration

At the far end of the complexity gradient from Lesson 1.2 sits a design choice that deserves its own lesson because it's so frequently over-applied: the manager/orchestrator with specialized subagents. A manager (or orchestrator) agent coordinates several subagents, each running its OWN loop, and each returning only a condensed result back to the manager rather than its full working process.

The critical detail — easy to skim past, impossible to overstate — is "its OWN context window." Each subagent doesn't share the manager's conversation; it has a private one, does its work inside it (which might mean reading thousands of tokens of source material, trying several approaches, backtracking), and hands back a short summary. The manager never sees the mess, only the conclusion. This single architectural fact is the source of nearly every benefit — and every cost — that the rest of this lesson unpacks.

Given that shape, three genuine benefits fall out of it, and the exam wants you able to name each on its own terms rather than lumping them together as "multi-agent is good."

CONTEXT ISOLATION is the headline benefit, and it follows directly from the private-context-window fact in 1.4.1: a research subagent can read thousands of tokens of source material, chase down a few dead ends, and still hand the manager back a tight paragraph. The manager's own context stays clean regardless of how much exploration happened underneath. This is a first-class fix for context bloat — not a side effect, the actual reason the pattern exists.

SPECIALIZATION is the second benefit: each subagent can get its own focused prompt, its own tool set, and — notably — its own MODEL TIER. You don't have to run every subtask on your most expensive model. Route the cheap, mechanical steps to a smaller model like Haiku, and reserve the hard reasoning steps for Sonnet or Opus. That's a direct lever for the cost dimension you learned to extract back in Lesson 1.1.

PARALLELISM is the third: when subtasks are genuinely independent, subagents can run concurrently rather than one after another, cutting wall-clock time for work that would otherwise be serial.

Now the half of this lesson that the exam leans on just as hard: multi-agent designs are not free, and they are not automatically better. The cost is real and specific, not vague hand-waving about "complexity." Multiple agents multiply token usage — every subagent has its own context, its own calls, its own overhead, and that's spend that a single well-scoped call simply doesn't incur. On top of the raw tokens, there's coordination overhead: the manager has to decide how to split work, dispatch it, wait for results, and reconcile them — work that doesn't exist at all in a single-agent design.

So the correct posture is: reserve multi-agent hierarchies for work that is GENUINELY SEPARABLE and expensive/complex enough to justify the overhead — not as a default choice you reach for because a task sounds important. If a task can be handled by a single well-scoped augmented LLM call, that single call very often wins outright on cost and latency, and a multi-agent design imposed on top of it is pure overhead bought with no benefit.

This is the mirror image of the trap from Lesson 1.2 — reaching for agentic autonomy before requirements justify it — applied one level up the gradient. "More agents" sounds like "more capability," but capability was never the bottleneck for a task that a single call could already handle.

Put 1.4.2 and 1.4.3 together and you get the actual skill the exam is testing: being able to justify a manager/subagent design by naming its SPECIFIC benefit for THIS task, rather than assuming multi-agent is automatically higher quality. "We used subagents because it seemed more sophisticated" is not a justification an architect should ever give or accept. "We used subagents because the research task genuinely separates into independent domains, and isolating each domain's exploration keeps the manager's context focused on synthesis" is.

Try this test on any proposed multi-agent design: if you removed the manager/subagent structure and replaced it with one well-designed augmented LLM call, what specifically would break? If the honest answer is "nothing, it would just be a longer single conversation," the multi-agent structure isn't earning its overhead. If the honest answer is "the manager's context would fill with raw research material before it could even start synthesizing, and independent research threads that could have run in parallel would have to run one after another," you've just articulated the context-isolation and parallelism benefits — and now you have a real justification, not a hunch.

You now have the shape (manager + subagents, each in its own context window), the three benefits, the real cost, and the justification test. The exam's Task Statement 1.4 items are built almost entirely from combining these: describing a task, and asking whether a multi-agent design is warranted, and if so, how to assign the subagents.

• 1.Ask whether the task is GENUINELY SEPARABLE into independent (or semi-independent) subtasks. If not, stop — a multi-agent design isn't justified regardless of scale.
• 2.If it is separable, ask whether it's HEAVY enough (in exploration volume, specialization needs, or potential for parallel speedup) to justify multiplied tokens and coordination overhead. A small separable task still might not be worth the overhead.
• 3.If both hold, assign each subagent a focused prompt, an appropriate tool set, and the CHEAPEST model tier that meets its subtask's quality bar — don't default every subagent to your most expensive model.
• 4.Name the specific benefit (isolation, specialization, or parallelism) you're relying on — if you can't name one, reconsider the design.