Your multi-agent system probably doesn't need five agents

The most common thing we are asked to build right now is a multi-agent system. The second most common thing we end up delivering is a single agent with three good tools, which does the same job for a fifth of the cost and can actually be evaluated.

This is not a complaint about the technology. It is a complaint about how the architecture decision gets made — usually once, early, in a slide, before anyone has measured anything.

What an extra agent actually costs

An agent is not a free abstraction. Each one you add brings:

• Latency, serially. A supervisor that consults three specialists before answering cannot be faster than the slowest specialist plus two round trips of its own.
• Cost, multiplicatively. Every hop re-sends context. A five-agent topology running a critic loop is routinely 6–10x the token spend of a single-agent baseline.
• Failure surface. Each handoff is a place where intent gets lossy. The supervisor summarises, the specialist answers the summary, and nobody notices the original question had a second clause.
• Evaluation difficulty. When a four-agent system gives a wrong answer, "which component was wrong" is a research project unless you built the tracing first.

An agent architecture is a distributed system that occasionally hallucinates. The usual rules about chatty service boundaries still apply.

The test we apply

Before we add a second agent, the design has to clear one of these bars. If it clears none of them, we build one agent with more tools.

Notice what is not on that list: "the domains feel different", "it is easier to write the prompts", or "the diagram looks better". Those are real feelings and bad reasons. Prompt organisation is not an architecture requirement — you can get the same separation with well-named tools and a single system prompt, at one hop.

Where multi-agent genuinely wins

To be clear, the pattern earns its place regularly:

1. Permission isolation. This is the strongest case by far. Separate service principals per specialist means a compromised or confused agent reaches less. We build this routinely and would not collapse it into one agent to save tokens.
2. Parallel fan-out and reduce. Independent subtasks against different sources, concurrently, then a deterministic reducer that reconciles and cites. Research and document-comparison workloads feel completely different with this.
3. Long-running work with human checkpoints. Durable state, an interrupt before any consequential write, resumption hours later. In practice this means a graph with explicit nodes, and that is a multi-agent shape whether or not you call it one.

Keep the loop bounded

Whatever topology you land on, the thing that decides whether it survives production is not the number of agents. It is whether the loop provably terminates.

class State(TypedDict):
    question: str
    findings: Annotated[list, add]
    steps: int          # bounded, always
    escalate: bool

def route(state: State) -> str:
    # Loops end. That is not negotiable.
    if state["steps"] >= MAX_STEPS or state["escalate"]:
        return "handoff"
    return supervisor.choose(state)

Three ceilings on every run — steps, tokens, wall clock — and a defined handoff when the agent is out of its depth. An agent that says "I need a human" is worth ten that confidently invent a refund amount.

Start with one, measure, then split

The honest sequence is: build the single-agent baseline, build the evaluation harness around it, and only then add the second agent — because now you can prove the split helped. Nearly every time we have done this, the baseline was closer to good enough than anyone expected, and the money was better spent on retrieval quality and tool design.

If you take one thing from this: the number of agents is an output of the design, not an input to it.