The thesis in one line: building a multi-agent system in the enterprise is in fashion, and it’s almost always the wrong answer. LinkedIn loves the swarm: five, ten, twenty agents splitting the work and passing tasks around like a human team. It sounds like the future. In practice, a single well-built agent —with good tools and continuous context— beats an army of agents passing the buck to each other almost every time. Orchestrating several has its moment, but it’s the exception, not the starting point.
The multi-agent system in the enterprise: why it’s in fashion (and why it’s almost always overkill)
Multi-agent sells because it tells a pretty story: if one agent is smart, many coordinated agents will be an unstoppable team. It’s the same instinct that makes us draw org charts —divide and conquer—. The problem is that AI agents aren’t people, and what in a human team is delegating, between agents is splitting the context. Every agent you add is a copy that only sees its slice of the problem and guesses the rest. You multiply the heads and you multiply the misunderstandings.
This isn’t a contrarian take for sport. Cognition —the people behind Devin— put it bluntly in their engineering: don’t build multi-agents. Their argument is that the architecture of parallel sub-agents is fragile by design: by isolating context between agents, they make decisions that contradict each other and the result doesn’t fit together («Don’t Build Multi-Agents», Cognition). Anthropic reaches the same caution from another angle: it recommends starting with the simplest thing that works and adding agents only when they deliver measurable value, and warns that its own multi-agent system burned roughly 15× more tokens than a normal chat to solve the same problem («Building Effective Agents», Anthropic).
Why a well-built agent wins almost every time
The boring —and almost always better— alternative is a single agent with continuous context and good tools. Instead of splitting the work across five heads that don’t talk to each other, you give one all the context and the tools to do the job end to end. The key isn’t how many agents you have, it’s what the one you have can touch. An agent with orderly access to your systems —your CRM, your email, your data— resolves more than a blind swarm. How you build that agent so it holds up to real work we break down in building an AI agent for companies, and what its accuracy depends on —access to your information— in training it on your own information.
The jump in quality rarely comes from adding agents; it comes from giving the one you already have well-designed tools. An agent that can query your database, open a ticket or send an email with clear, well-typed tools does more than ten agents that only know how to talk to each other. That’s exactly the shift the standard for connecting tools to agents brought, and why it matters we cover in what MCP is and why it changes enterprise agents. Good tools, one agent. Not twenty one-armed agents.
When orchestrating several agents does make sense
This isn’t a flat no to multi-agent. There are cases where splitting the work between agents is the right call, not the posturing. The rule is simple: you orchestrate several when the work can genuinely be split into independent chunks that don’t need to talk to each other at every step.
- Genuinely parallel tasks. When you have to run twenty independent searches at once and then combine results, splitting across agents saves time. The work divides cleanly and recombines at the end; nobody depends on the neighbour halfway through.
- Specialties that don’t share context. An agent that drafts and another that reviews with different criteria can coexist if the boundary between them is sharp and the information they pass is small and clear.
- Isolating to contain risk. Sometimes you separate an agent with dangerous permissions —touching production, moving money— from the rest, precisely so no other piece can trigger what only it should do under control.
| Situation | A well-built agent | Multi-agent system |
|---|---|---|
| Sequential work with shared context | Wins: continuous context, no losses | Fragile: agents contradict each other |
| Independent parallel tasks | Chokes on scale | Wins: splits and recombines |
| Cost and latency | Low, a single thread | High: up to ~15× more tokens |
| Debugging when it fails | Traceable, a single thread | Opaque: which agent broke it? |
The question that decides the architecture (not the LinkedIn fashion)
The decision isn’t «multi-agent yes or no» as a flag. It’s «what’s the simplest shape that solves this job». Start with one agent and good tools. If it chokes on real scale —not imagined scale—, then, and only then, you orchestrate. Most office jobs —classifying, drafting, reconciling, replying— are handled easily by a well-built agent, like the AI admin agent that clears the inbox without a committee of bots behind it. And when the work crosses several systems, what decides isn’t the number of agents: it’s that someone builds the process and sustains it, which is exactly what operations automation does.