Multi-Agent Orchestration: When One Smart Agent Beats Five Specialized Ones

Multi-agent systems get proposed by default in a lot of agent tutorials — a “planner” agent, a “researcher” agent, a “critic” agent, coordinated by an orchestrator. It’s an appealing design because it mirrors how a human team would split the work. It’s also, in most cases people reach for it, the wrong first move.

Why splitting into agents feels right and often isn’t

Each additional agent in a pipeline adds three concrete costs that are easy to underweight:

• Context loss at the handoff. Agent A doesn’t pass its full reasoning to Agent B — it passes a summary or a structured output. Whatever nuance didn’t make it into that handoff is gone, permanently, for every downstream agent.
• Compounding error rate. If each agent is individually right 90% of the time, a 4-agent pipeline where each depends on the previous one’s output is right roughly 0.9⁴ ≈ 66% of the time end to end — worse than any single agent in the chain.
• Debugging surface area. A failure in a single-agent loop has one place to look. A failure in a 5-agent pipeline could be a bad handoff, a bad tool call inside any one agent, or the orchestrator routing to the wrong agent — and you often can’t tell which without instrumenting every hop.

When one agent with more tools beats a pipeline

If the task is “gather information, then reason about it, then produce an answer” — which describes a large fraction of what gets built as multi-agent — a single agent with access to all the relevant tools and a large-enough context window usually does better, because it never loses information at a handoff:

# one agent, several tools — no orchestration layer, no handoff loss
tools = [search_web, query_database, read_file, run_calculation]

agent = Agent(model="claude-sonnet-5", tools=tools, system_prompt=(
    "Research and answer the question. Use whichever tools are relevant, "
    "in whatever order makes sense. You don't need to plan phases up front."
))

The model itself is capable of deciding “search first, then check the database, then calculate” without you hand-coding that sequence into separate agent roles. The tool-calling loop from tool-calling vs. function-calling vs. MCP already handles the “do several things in sequence” case — that’s not, by itself, a reason to introduce multiple agents.

When multiple agents genuinely earn their cost

• Truly independent subtasks that don’t share context. If Agent A is summarizing a legal document and Agent B is independently checking a codebase for a bug, running them in parallel as separate agents is a real win — they don’t need each other’s context, so there’s no handoff loss to worry about.
• A task that exceeds one context window even after compaction. If the work genuinely doesn’t fit — a codebase too large to reason about in one pass — splitting by subsystem into separate agents, each with a narrower context, can be the only way to fit the problem at all.
• You need an adversarial check, not a collaborative pipeline. A “critic” agent that reviews another agent’s output without seeing its reasoning — only its final answer — catches errors a single self-reviewing agent tends to rationalize past. This is one of the few cases where deliberately withholding context between agents is the point, not a cost.
• Different subtasks genuinely need different models. If one subtask needs a large, expensive model for hard reasoning and another is simple classification that a cheap small model handles fine, splitting into separate agent calls with different models attached is a real cost optimization — this is less “multi-agent architecture” and more “route work to the right-priced model.”

The decision rule

Before adding a second agent, ask: does this subtask need to not see the other agent’s full context, or am I just organizing my own code into role names? If the honest answer is the latter — you’re calling them “the researcher” and “the writer” because it reads cleanly in a diagram — you’re paying the handoff-loss and compounding-error costs above for an organizational preference, not a functional requirement. Keep it one agent with more tools until something concrete forces the split.