Most of These Should Not Exist

In one line: adding agents adds coordination, and coordination is where these systems break.

Start from scepticism

Multi-agent is an appealing design. It maps onto how people organise work, it produces a diagram that looks sophisticated, and it suggests that a problem too hard for one model becomes tractable when split among several.

That last part is mostly wrong, and it is worth being direct about why.

The largest study of multi-agent LLM failures to date — Berkeley's MAST taxonomy, built from over 1,600 execution traces across seven frameworks — found that failures cluster into three categories, and the biggest is specification and design issues, at around 42%. Inter-agent misalignment accounts for roughly 37%, and verification failures about 21%.

Read that as a whole: the overwhelming majority of what goes wrong is how the system was put together, not how capable the models were. Specification, coordination and checking — all three are architecture.

What splitting actually costs

Four costs, and none of them appear on the diagram that made the design look appealing.

Coordination latency. Each layer of hierarchy adds a model call before any real work starts. A three-level structure with a call at each level spends several seconds deciding who should do something before anyone does it.

Compounding error. Each agent's output becomes the next one's input, and an error at step one is a premise at step two. Uncoordinated designs amplify errors substantially; centralised ones with a validation step contain it — but neither eliminates it, and this gets its own lesson.

Context loss at every boundary. An agent hands over a summary, not its working state. Whatever it knew and did not write down is gone, and the receiving agent does not know it is missing.

Multiplied cost. Five agents doing three steps each is fifteen model calls plus the supervisor's own reasoning, against one agent that might have done it in six.

The two things it is usually competing with

Before the gate in the next lesson, two alternatives deserve their turn.

One agent with more tools. Often the right answer. A single loop with access to search, a code runner and a document store handles a great deal of what gets proposed as three agents — with one context, no handoffs, and no coordination.

A deterministic workflow. If the sequence of stages is known in advance, write it as a pipeline with a model at the stages that need judgement. This is the same argument as the single-agent chapter's "if the steps are known, it is a workflow", and it applies with more force here: a fixed pipeline of model calls is not a multi-agent system, and calling it one adds nothing but vocabulary.

That second point is worth pressing. A great many "multi-agent pipelines" are a sequence of prompts with a fixed order. That is a good design, and it should be described accurately, because calling it multi-agent invites coordination machinery it does not need.

What is actually true

To be fair to the design: there are real reasons, and they are narrower than the enthusiasm suggests.

Different context. Two sub-problems need genuinely different information in the prompt, and combining them means both are worse. A code-writing agent needs the repository; a compliance-checking agent needs the policy corpus. Neither benefits from the other's context.

Different tools or permissions. A worker with read-only research access and one with write access to production are different trust domains, and separating them is a security boundary rather than a modelling convenience.

Genuine parallelism. Sub-tasks that are actually independent can run at once, turning a sum of latencies into a maximum. This is the strongest reason and the easiest to verify: if the sub-tasks depend on each other, it does not apply.

Independent verification. A critic that did not produce the work checks it. This is a real structural gain and it gets its own lesson.

Notice what is not on that list: the task being hard. Difficulty is not a decomposition argument.

How to open in an interview

The move that sets up everything else:

Before I design this, I want to be sceptical about the shape. Multi-agent systems fail mostly on specification and coordination rather than on model capability — the published failure taxonomy puts design and inter-agent misalignment at close to eighty percent between them. So I'd want to establish that decomposition is actually justified: different context, different tools or permissions, genuine parallelism, or independent verification. If it is none of those, this is one agent with more tools, or a deterministic workflow.

That is not obstruction. It is the same judgement every other part of system design asks for — knowing when the elaborate shape is not the right one — and it is what makes the rest of the design credible when you do build it.

Next: the gate, in more detail.