The problem
An engineer proposes using four specialized subagents to solve an analysis task that consists of reading two files and comparing two numerical values. The rationale offered: "multi-agent systems are more robust." In practice, the outcome is four isolated context sessions, higher latency, multiplied token costs, and zero quality improvements — because the task never required independent reasoning perspectives. It needed a deterministic assertion check.
Multi-agent orchestration is not a linear scale of "better" as you add more agents. It is a specialized architectural pattern suited for specific conditions: when a task genuinely benefits from context isolation, strict domain specialization, or genuine execution parallelism. Outside these boundaries, it simply introduces unneeded complexity.
The core architectural concept
The first question before deciding on any multi-agent topology is: can this task fit comfortably within a single context window, utilizing a compact toolset, without requiring isolated reasoning chains? If yes, a single coordinator solves the problem with the fewest moving parts. Multi-agent topologies are justified only when at least one of these conditions is true:
- The task benefits from independent parallel research — exploring multiple sources or hypotheses simultaneously without contaminating each other's reasoning streams.
- The task requires isolated review — an independent evaluator that inspects only the final deliverable without seeing the generative scratchpad, eliminating self-evaluation confirmation bias.
- The task involves genuinely distinct subdomains — where specialized subagents load only domain-specific context rather than accumulating a bloated, monolithic context window.
Deterministic validation — such as comparing numerical metrics or calculating a file hash — never justifies a subagent. It must be implemented in native code or a narrowly scoped tool, because deterministic operations gain nothing from autonomous reasoning loops. This is the most common scenario distractor: proposing multi-agent orchestration for operations that follow exact procedural algorithms.
The second decision axis is topology. A coordinator delegating to specialized subagents operates effectively when subtasks are known upfront with clear boundaries — each subagent receives a defined scope and returns structured payloads. True parallelism (running multiple subagents concurrently) only creates value when subtasks are mutually independent — if step B depends on the output of step A, parallelizing adds orchestration overhead without saving time.
The third axis is sequential versus adaptive task decomposition. Sequential decomposition works when steps are fixed in advance — a deterministic "extract, validate, format" pipeline. Adaptive decomposition is required when subsequent steps depend dynamically on prior discoveries — where the coordinator must decide at runtime whether to delegate, to whom, and under what scope as the problem space unfolds.
The most expensive mistake in multi-agent orchestration is not deploying too few agents — it is deploying too many agents for a task that fits within a single context, multiplying latency and operational spend without delivering measurable quality gains.
Put it into practice
In this lesson's lab, you will implement a topology decision engine in Python: given operational signals (does it require true parallelism? does it require isolated review? is it deterministic?), it recommends the optimal architecture — including identifying when the correct architectural response is "zero subagents, execute in native code."