The Gate

In one line: four conditions justify splitting a task across agents, and each has a test that a plausible-sounding case usually fails.

Condition one: different context

The sub-problems need genuinely different information in the prompt, and combining them degrades both.

The test: would putting both contexts in one prompt make the model worse at each? Not merely bigger — worse. A long context dilutes attention and pushes relevant material away from the edges where it is best attended to, so two large unrelated bodies of knowledge genuinely interfere.

Where it fails: "the research agent needs search results and the writing agent needs the outline" is not different context — the outline came from the research, and one agent holding both is fine.

Condition two: different tools or permissions

A worker that can only read and one that can write are different trust domains, and separating them is a security boundary.

The test: would you be uncomfortable giving one agent both capabilities? If the answer is yes, the split is a permission decision and it is a good one — it is the least-privilege argument from the guardrails chapter, applied at the agent level.

Where it fails: "the search agent uses search and the summary agent doesn't" is not a permission boundary. Nobody is worried about a summarising agent having search access.

Condition three: genuine parallelism

Sub-tasks that are actually independent can run concurrently, turning a sum of latencies into a maximum.

The test: can sub-task B start before A finishes, without A's output? If not, this is a pipeline, and a pipeline of agents is a workflow with extra vocabulary — sequential agents get all the coordination cost and none of the parallelism benefit.

Where it fails: most proposed decompositions. Plan, then research, then write, then check is entirely sequential, and running it as four agents buys nothing over four prompts in order.

Condition four: independent verification

A critic that did not produce the work checks it. Structurally different from asking the producer to self-assess, for the reason established in the single-agent chapter: a model that generated something also generated its justification.

The test: does the checker have information or a perspective the producer lacked? A critic with the same context and the same prompt is an expensive re-roll. One with the acceptance criteria and not the reasoning that produced the answer is a genuine check.

How many agents

Once decomposition is justified, the count is a real decision and the answer is fewer than instinct suggests.

Coordination cost grows with the number of participants, and in designs where every agent can talk to every other it grows quadratically — so those degrade quickly and are rarely worth their complexity past a handful of participants. A centralised design, where workers talk only to a supervisor, scales far better because the edges grow linearly.

The practical guidance: start with two and add one only when a specific condition above demands it. Every additional agent is another handoff, another context boundary, and another place for the specification to be wrong — which is the largest failure category.

Scoping a real system

Four questions once the gate is passed.

What is the goal, and who owns it? Exactly one component holds the overall objective and decides when it is met. Distributing that produces a system where nobody can say whether it finished.

What is the budget, and who holds it? Same answer, same reason. A total step and cost budget owned by one component, allocated to workers, is what stops a multi-agent system from spending without bound.

What does a worker receive, and return? The interface, and it is the part most designs leave implicit. It gets its own lesson.

What happens when a worker fails? Retry, reassign, replan, or escalate. Deciding this per failure type is what separates a design from a diagram.

Committing

A research-and-drafting system. Decomposition is justified on two of the four conditions: the retrieval workers need large and disjoint source contexts that would interfere in one prompt, and they are genuinely parallel — three independent searches that do not depend on each other. Plus a critic that sees the acceptance criteria and the output but not the reasoning. One supervisor owns the goal and the budget. Workers never talk to each other.

That last clause is worth stating explicitly. Workers talking to each other is the design decision that most often turns a manageable system into an unmanageable one, and defaulting to a star topology rather than a mesh is nearly always right.

The honest fallback

Worth keeping in view as the design proceeds.

If the gate is passed on only one weak condition, the better answer may still be a single agent with more tools plus a critic — which gets the verification benefit, the strongest of the four, without any of the coordination cost.

That configuration — one worker, one critic — is the smallest multi-agent system that earns its keep, and it is a good default when the other conditions are marginal.

Next: the shapes these systems take.