A "multi-agent" AI system sounds like the advanced version of a chatbot: instead of one assistant, several specialized agents splitting up the work and talking to each other. More and more vendors sell it as the natural next step, the one you're supposed to take as soon as a single agent "isn't enough" anymore. For most of the small and mid-sized businesses we talk to, that step isn't needed, and building it too early trades one problem for a worse one.
What the market sells when it says "multi-agent"
The label covers very different things under the same name: one agent that plans and another that executes, a "supervisor" agent that hands out tasks to "worker" agents, or several assistants with roles (one that answers, one that bills, one that analyzes) passing information back and forth. The sales pitch is always the same: more agents, more capacity.
The problem is that a system with several agents doesn't add capacity on its own. It adds coordination: something has to decide which agent does what, pass context from one to another without losing anything along the way, and resolve what happens when two agents reach different conclusions about the same data. Every coordination step is a new place where something can break, and that cost exists whether or not the business problem actually needs it.
The question that really decides it: do the tasks share context?
Before asking how many agents you need, you have to ask how many truly independent tasks there are. The most common mistake is treating steps of the same task as if they were separate tasks:
| Situation | Is it multi-agent? | Why |
|---|---|---|
| Validate the client, apply the price, check stock and create the order | No | These are steps of the same quote, in the same context. It's one agent with several tools. |
| Read an invoice, match it to the vendor, and post it to accounting | No | Same flow, same data, different queries against the same system. |
| Handle sales WhatsApp and, in parallel, monitor the accounting firm's tax inbox | Yes, or close to it | These are processes that don't share context or depend on each other. |
| One agent that audits morning invoices and another that calls and books sales appointments | Yes | Different rhythms, data and goals; they don't need to talk to each other. |
The decision rule is this: if you can describe the work as a list of steps that depend on each other and use the same underlying data, it's one agent with several tools, not several agents talking to each other. You only need more than one agent when there are genuinely independent tasks, ones that could stop without affecting the other, and that don't need to share the thread of the conversation.
Real case: one agent with five tools, not five agents
At an industrial distributor with over 50,000 products in its catalog, we built an AI sales agent that quotes over WhatsApp inside the ERP itself (the full case is in AI sales rep in the ERP). Every quote requires several checks: who the client is, what price applies to them, whether the product is in stock, whether an agreed discount applies and, if the deal closes, recording it as an opportunity and an order in Odoo.
A multi-agent approach would have built a "client validator" agent, a "stock checker" agent, a "price calculator" agent and an "orchestrator" to coordinate them. Instead, we built a single agent with five tools: check the client, check the price, check the stock, apply the discount, and create the record. The agent decides which order to call them in based on what the customer is asking, without having to hand the conversation's context off to anyone else or wait on another process to respond.
The result, already told in detail in 30 minutes to 3 per quote, is that each quote went from around 30 minutes of human work to being resolved in minutes, without dropping any of the checks a person used to do by hand. None of those steps needed a separate agent. They needed one more tool, inside the same agent.
When you actually do need more than one agent
There are real cases where building more than one agent is the right call, and it's worth recognizing them so you don't overcorrect into the opposite mistake (cramming everything into one giant agent):
- Processes that run in parallel, on different rhythms. An agent that posts incoming invoices during the day and another that calls by voice and books sales appointments don't need to depend on each other; one failing shouldn't stop the other.
- Domains with incompatible rules and permissions. An agent with write access to the sales ERP and another with read access to the accounting firm's tax inbox shouldn't share credentials or context, even if the same company uses both.
- Volume that overwhelms a single agent. When one type of task arrives at a volume a single agent can't process with a reasonable margin, it makes sense to split instances of the same agent, which is different from splitting different roles across different agents.
Checklist before requesting (or selling) a multi-agent system
Before signing off on a proposal that includes "multi-agent architecture," run the project through this list:
- Can I write the full process as a list of steps, start to finish, without odd branches?
- Do all those steps use the same underlying data (the same client, the same document, the same conversation)?
- If one step fails, does it make sense for the whole process to stop, or should another part genuinely keep going on its own?
- Do I need two processes to run in parallel without waiting on each other?
- Are there different permissions or systems that shouldn't be mixed into the same agent?
If the first three answers are yes and the last two are no, the problem calls for one agent with several tools. If either of the last two is yes, then there's a real reason to consider more than one agent, and the question stops being "how many" and becomes "how do they split the work without losing track of who did what," which is the part that actually needs careful design.
The question to ask a vendor
When a vendor proposes a multi-agent system, the question that separates a real design from an architecture sale is simple: "which part of my process needs two agents working without knowing about each other?" If the answer describes steps of the same task, what's missing isn't more agents, it's more tools inside a single one, built on top of the real system instead of a layer above it. It's the same principle behind every project we build: first the data and access to the real system get put in order, and only then do we decide how many agents are actually needed, almost always fewer than it looked like at first.
If you want us to look at whether your case calls for one agent or several, check our services to see how we work on integrating with the real system before touching any AI. And if you're ready to start, get in touch and we'll look at it together.
