Multi-agent systems: orchestration and handoffs

Adding a second agent to a system doesn't halve the problems. It multiplies them. Every agent you add is one more place a mistake can start, and one more handoff where it can get worse before anyone notices.

That's not an argument against multi-agent systems. It's the reason to be honest about when they're actually worth it, instead of reaching for one because it sounds more sophisticated than a single agent with a good loop and a working memory.

Why split one agent into several at all

A single agent juggling everything, research, writing, fact-checking, formatting, tends to do all of it a little worse than a specialist would do each piece. Splitting the work gives each agent a narrower job, a smaller set of tools to choose from, and a prompt that only has to cover one kind of task. Narrower usually means more reliable, the same reason a specialist doctor is often better at their one thing than a generalist trying to cover everything.

The supervisor pattern

The most common shape is a supervisor agent that doesn't do the actual work itself. It receives the task, decides which specialist agent should handle which piece, and passes each piece along. A specialist finishes its part and hands the result back to the supervisor, which decides what happens next, another specialist, a final answer, or a request for more information.

This keeps the decision-making centralized in one place instead of scattered across agents that each have to guess what the others are doing. The supervisor is the single point that understands the whole task, even though no individual specialist does.

Handoffs are where things actually break

The handoff, one agent's output becoming another agent's input, is the most fragile point in the whole system, more fragile than any single agent's own reasoning. A few concrete ways it goes wrong:

• Lossy summaries. If the supervisor summarizes a specialist's output before passing it along, and the summary drops a detail the next specialist actually needed, that detail is just gone. Nobody erred loudly. It just silently stopped existing.
• Format mismatches. One agent's output doesn't match the shape the next agent expects, and unless something validates that handoff, the receiving agent either fails or, worse, confidently misinterprets malformed input as valid.
• Context loss. A specialist agent often doesn't see the full conversation, only what the supervisor chose to pass it. If that's too little, it makes a decision that would've been obviously wrong with the full picture.

The real costs, stated plainly

Cost multiplies. Every agent invocation is its own set of model calls. A task that took one agent one pass now takes a supervisor call plus however many specialist calls, and that adds up fast on anything that runs frequently.

Errors cascade. A mistake made early by one agent doesn't stay contained to that agent, it gets passed along as if it were fact, and the next agent builds on top of it without knowing it's wrong. Debugging a multi-agent failure often means tracing back through several handoffs to find where the actual mistake happened, not just where it became visible.

Debugging gets harder, not easier. More moving parts means more places to look when something goes wrong, and a failure in agent three might have been caused by a subtly bad output from agent one. Splitting the work doesn't split the debugging effort the same way, it usually multiplies it too.

When it's genuinely overkill

If a single well-scoped agent with a decent prompt and the right tools already does the job reliably, adding more agents on top of that is complexity you're paying for without a problem it solves. Multi-agent earns its cost specifically when the task has genuinely distinct sub-skills that benefit from separate, focused prompts, and you're seeing the single-agent version actually fail on the parts a specialist would handle better. Reach for it because you've measured the failure, not because it sounds more advanced.

However many agents you're running, none of this addresses a separate problem: whether you can trust what any of them actually output. That's next.