One agent vs. many: when orchestration is overkill, and when it's the only thing that works.

According to Salesforce's 2026 Connectivity Benchmark, the average enterprise now runs 12 AI agents — and half of them operate completely alone, with no connection to other agents. Meanwhile, every conference talk and vendor pitch in 2026 is about multi-agent orchestration: routers, supervisors, hierarchies, agent-to-agent protocols, swarms.

Which means a lot of teams are sitting in meetings right now wondering: do we actually need this? Or is one well-built agent fine?

We've shipped both patterns into production. Here's the honest decision framework.

The default should be one agent

Let's start here because nobody else is saying it: the default should be one agent. Multi-agent systems are more complex, more expensive, harder to debug, harder to evaluate, and harder to operate. They're worth that cost only when the work genuinely can't be done by a single agent. Most work can.

One Claude with a good system prompt and 10 well-designed tools beats a swarm of five specialized agents on most tasks we've benchmarked. It's faster. It's cheaper. It fails in fewer ways. The traces are easier to read. The evaluations are easier to run.

Multi-agent feels like the future, but for most use cases, it's a future you don't need yet.

When to use a single agent

Use a single agent when:

• The task fits in one mental context. A customer support agent answering a question and resolving a refund is one task, even though it touches multiple systems. One agent handles it fine.
• The tools are related. If your tools are all "ways to interact with our CRM," that's one agent's job.
• You're early in the project. Always start with one agent. Add more only when you have a specific, named reason the single agent isn't working.
• Latency matters. Multi-agent systems add coordination overhead. If you need a response in under 3 seconds, one agent is almost always the right call.
• The team operating it is small. Multi-agent systems are harder to debug. If your ops team is two people, one agent is easier to keep healthy.

When to use multiple agents

Use multiple agents when one or more of these is true:

1. The task has genuinely separate phases with different "modes of thinking"

A research agent that needs to plan a research strategy, then execute a series of searches, then synthesize results into a report is doing three very different kinds of cognitive work. Splitting these into a planner, executor, and synthesizer often works better than asking one model to do all three because each agent can have a different system prompt, different tools, and different evaluation criteria.

2. You need parallelism

If the task is "review these 50 contracts," running 10 contract-review agents in parallel is genuinely faster than one agent processing them sequentially. This is the easiest multi-agent win to identify and the hardest to mess up.

3. Permissions need to differ

If part of the workflow needs read access to sensitive data and another part needs write access to public-facing systems, splitting these into two agents with different tool permissions is a cleaner security boundary than one agent with everything.

4. You need a "supervisor" pattern

For high-stakes workflows, having a separate supervisor agent that reviews the primary agent's proposed actions before they execute is genuinely valuable. The supervisor doesn't need to be smart — it just needs to apply rules. We've used this pattern for financial workflows and the supervisor catches about 3% of actions that the primary agent would have done incorrectly.

The pattern most people get wrong

The most common mistake we see: teams build a multi-agent system because it sounds modern, when a single agent with better tools would have worked. The result is a system that's harder to debug, harder to evaluate, more expensive to run, and not actually any better at the task.

The second most common mistake: teams build a single agent when they actually needed multi-agent. The symptom is usually "the agent gets confused when it has to switch between very different kinds of tasks." If your prompt is starting to read like three different jobs glued together with "if X then... else if Y then... else if Z then..." — that's the signal you actually need separate agents.

Our rule of thumb

We start every engagement with a single agent. We only split into multiple agents when we hit a specific named problem the single agent can't solve. Usually that's one of: parallelism we can't fake, separation of permissions we can't fake, or planning/execution/synthesis phases that the single agent measurably handles worse than three specialized ones.

One good agent beats three mediocre ones. Multi-agent isn't an upgrade — it's a tradeoff. Pay the cost only when the single agent has measurably failed.

If you can't name the specific failure of your single-agent system that multi-agent would fix, you don't need multi-agent yet. You need a better single agent.