The honest default is one agent

Start from a position of suspicion: most problems that get built as multi-agent systems should be one agent with a good set of tools. The multi-agent version tends to win the architecture diagram — it looks organised, it maps onto how a human team would divide the work — and then lose in production, where it is slower, more expensive, and much harder to debug than the single agent it replaced.

This is not an argument against ever splitting. It is an argument for making the split earn its place. A second agent is not a free upgrade; it is a distributed system, with all the coordination cost that phrase implies. If you are new to the underlying building blocks — the perceive–decide–act loop, tools, memory — the single-agent primer is the better place to start, because everything here assumes you can already build one agent that works.

The test in one line. Would you hand this task to two people who sit in different buildings and only exchange written notes? If yes, two agents may fit. If the honest answer is "no, they'd need to sit at the same desk," it is one agent — splitting it just moves the conversation into a lossy channel.

Why a second agent usually costs more than it adds

The intuition that more agents means more capability is backwards for two concrete, measurable reasons. Neither is about compute cost — they are about information and reliability.

The boundary between agents is a lossy channel

Inside one agent, everything the model has seen — the original request, the tool results, the half-formed plan — sits in shared context. The moment you split into two agents, that shared state has to be squeezed through a message: one agent serialises what it thinks the next one needs into a paragraph of text, and the receiving agent works from that paragraph, not from what actually happened. Every hand-off drops information, and worse, it drops silently — the second agent has no way to know what was left out. A support agent that passes "customer is unhappy about delivery" to a resolution agent has thrown away the order number, the tone, and the three earlier tickets that would have changed the answer. Two agents that constantly need each other's full context are one agent wearing a costume.

Errors compound down a chain

Reliability multiplies, and multiplication of numbers below one goes only one way. If each agent in a linear pipeline is a strong 90% reliable, a five-stage chain is 0.9⁵ ≈ 59% — you have built a system that is wrong four times out of ten out of parts that are each individually good. Adding a stage to "improve quality" makes this worse, not better, unless that stage removes errors rather than being one more place to introduce them. This single fact quietly kills most "assembly line of agents" designs: the line is only as trustworthy as the product of its steps, and steps are cheap to add and expensive to verify.

The three times multi-agent genuinely wins

There are real reasons to reach for more than one agent — but there are only about three of them, and they are structural, not organisational. None of them is "because the task has several parts." A single agent handles several parts fine; that is what tools are for. You split when the structure of the work demands it.

One agent + tools the default split only for one of these → Isolation separate context & permissions Verification an independent checker Parallelism independent items at once Everything else stays one agent — add a tool, not an agent
A second agent earns its place for isolation, verification, or parallelism. "The task has several steps" is not on the list — that is what tools are for.

Isolation: separate context and separate permissions

The strongest reason to split is a boundary that should exist anyway. Suppose a machine builder's assistant answers technical questions from the manuals and can file warranty claims into the ERP. Those two jobs want different things: the question-answering side should see a broad slice of documentation and touch nothing; the warranty side needs write access to financial records and a human approval gate. Keeping them in one agent means one blast radius — a prompt-injected manual could reach the ERP. Splitting them puts a real wall between a read-only, low-trust surface and a high-privilege, human-gated action. Here the second agent is not about capability; it is a security boundary, and that is worth the coordination cost.

Verification: a checker that didn't do the work

The one split that reliably raises quality is a verifier: a second agent whose only job is to check the first agent's output against the source, the schema, or the rules — and to send it back if it fails. This works because models are markedly better at judging a finished answer than producing one, and because an independent checker doesn't inherit the producer's blind spot. The catch is the word "independent": if the verifier sees the same context and shares the same failure mode, it will happily wave through the same mistake. And it only helps if it can actually reject — a verifier that comments but cannot force a redo is decoration. This is close cousin to how you should already be evaluating the system offline; a verifier agent is that discipline moved into the live loop.

Parallelism: genuinely independent work at once

If the work is a set of items that don't depend on each other — summarise 200 contracts, check 50 suppliers against a list — running many identical agents in parallel is a straightforward win on wall-clock time. This is the safest multi-agent pattern precisely because there is no hand-off: the agents never talk to each other, so there is no lossy channel and no compounding chain, just a fan-out and a gather. Note that this is horizontal (the same job many times), not the vertical "team of specialists" people usually picture.

The patterns, briefly

When a split is justified, three coordination shapes cover almost everything, and it is worth naming them so you pick on purpose rather than by default.

Supervisor (orchestrator–worker). One agent owns the goal and delegates sub-tasks to workers, keeping the overall plan. This is the most flexible and the most failure-prone: the supervisor is a single point that can misroute, loop, or lose the thread. Use it when tasks are dynamic and you cannot lay out the steps in advance.

Pipeline. A fixed sequence — extract, then transform, then write — where each stage has one job. Predictable and easy to reason about, but remember the compounding-error maths: keep the chain short and put a verifier at the end, not a fourth transform. Most business workflows that look like they need agents actually want a pipeline, and often a plain deterministic pipeline with a model at one step, not agents at every step.

Parallel fan-out. The independent-items pattern above. Cheapest to build, easiest to trust, and the one people reach for last because it doesn't feel sophisticated.

What I would not build. An org chart of agents — a "researcher," a "writer," an "editor," a "manager" — mirroring how a human department is structured. Job titles are a social convention for coordinating people; they are not an information architecture. Splitting by title gives you the coordination cost of a team with none of the shared context a real team has over coffee. Split on isolation, verification, or parallelism, or don't split.

The cost you feel later: debugging

There is a price that never shows up in the design review and dominates the second month in production. With one agent, when something goes wrong you read one transcript top to bottom and you can see the reasoning that produced the bad step. With five agents, you are doing distributed-systems debugging: the failure is an emergent property of how they interacted, it may not reproduce on the next run, and the misleading hand-off that caused it can be three agents upstream of where the error surfaced. Non-determinism, which is merely annoying in one agent, becomes genuinely hard across several. If you do build a multi-agent system, the audit log of every hand-off is not optional — it is the only thing that will let you understand your own system when it misbehaves.

This is the real reason to keep the count low. Not purity, and not cost per token — but that you have to operate, monitor, and fix the thing after it ships, and every agent you add is another moving part that can fail in a way you cannot easily see. Two agents with a clear boundary between them is a system you can hold in your head. Seven agents negotiating is not.

Where Tippel fits

Most of the value in this decision is in refusing the fashionable answer. When a company asks us for "a multi-agent system," the useful first move is usually to find the one agent hiding inside the request — the version with good tools, a tight permission scope, and a single verifier where it actually pays — and to build multi-agent only where a real boundary demands it. That tends to be cheaper to build, cheaper to run, and possible to debug at 2 a.m.

If you are weighing an agent project and want an honest read on whether it needs one agent or several — and where the boundaries genuinely are — that is the kind of question the AI Readiness Check is built to answer, or you can just get in touch. Either way, you can also see how we think about the surrounding architecture in how we work.