One agent answers questions. Several agents handing work to each other cover an entire process — from inbound enquiry to the report on the manager's desk. The difference between those two things is bigger than it looks, and it is not about quantity.
A multi-agent system is not "lots of bots". It is a division of labour: each agent owns a narrow slice, and the result passes down the chain automatically.
One agent versus a system
| Aspect | Single agent | Multi-agent system |
|---|---|---|
| Scope | One task | A whole process or department |
| Trigger | A person initiates it | Fires on an event — an enquiry arrives, Monday comes |
| Interaction | Works in isolation | Agents pass results to one another |
| Instructions | One general set | Each has its own, narrow and therefore more precise |
| Setup complexity | Low | High — handover logic and failure handling required |
That last row is the reason not to start with a system. More on this below.
What it looks like in practice
An example for a sales department — four agents in a chain.
The intake agent watches every channel: website, Telegram, Instagram, CRM. An enquiry appears — it records it and passes it on.
The qualifier asks clarifying questions, works out whether this is a fit and how urgent it is, then decides: hot leads go to a rep immediately, the rest into the normal queue.
The assistant takes a hot lead and drafts a proposal from templates and the catalogue, then sends it to the rep for review.
The analyst summarises the funnel once a day and sends management the picture: what has stalled, where conversion dropped, what changed over the week.
The key point: none of the four makes a decision on a human's behalf. The first collects, the second sorts, the third drafts, the fourth reports. People decide and people send.
Why specialisation works better
A narrow instruction beats a general one. An agent that only handles qualification can be given ten pages of detail about it. You cannot give a universal agent an instruction like that: the more it does, the blurrier each individual capability becomes.
A failure does not take everything down. If the reporting agent breaks, intake keeps running. With one large agent any problem stops everything at once.
You can change one part at a time. Qualification criteria changed — one agent gets edited, the rest stay untouched. In a monolithic instruction any edit risks disturbing adjacent behaviour.
You can see where the error was. When something goes wrong, it is clear which step produced it. In a single agent you are left guessing across the whole chain of reasoning.
Where it is justified, and where it is not
A multi-agent system makes sense when three conditions hold at once:
- the process consists of genuinely distinct steps rather than one repeated action;
- the volume is enough for the automation to justify the complexity;
- the steps are already described — you could explain them to a new hire in words.
If even one of those fails, a single agent will do, and it will be more reliable.
An honest rule: the complexity of the system should be lower than the complexity of the process it automates. Five agents on something one person does in an hour a week is an expensive toy.
What you pay for it
Three things people rarely warn you about.
Errors compound down the chain. If the first agent misreads the request, the second works on distorted data and the third on data distorted twice over. Which is why real systems put checks at every handover — and that is half the configuration work.
Debugging is harder. Tracing a strange result through four steps takes longer than through one. Hence the requirement to log every handover; without it the system becomes unmanageable within a month.
It costs more. Each agent makes its own calls to the model. At typical volumes this is still tens of dollars a month, but it has to be counted across the whole chain rather than one link.
How you get there
Not by designing a system, but by starting with one agent.
- Launch one process — intake and qualification of enquiries, say.
- Get it to run stably and confirm the team is actually using it.
- Add a second agent on the adjacent step and connect the two.
- Repeat.
The system grows rather than being designed whole in advance. The reverse route — draw a diagram of eight agents, then build it — almost always ends with half the diagram turning out unnecessary and the other half built the wrong way.
What every agent needs defined
Regardless of the size of the system, four things have to be defined for each agent. If even one is left undescribed, that agent will eventually become a source of problems.
- Input. What it receives and from whom — an event, data, the previous step's result.
- Task. One task, stated in a single sentence. If it does not fit in a sentence, that is two agents.
- Output. What it passes on and in what shape. The format has to be fixed, otherwise the next agent cannot rely on it.
- Failure behaviour. What happens when it cannot cope: hand to a human, retry, halt the chain. The item forgotten most often — and the one that determines whether the system behaves predictably on a bad day.
Those four points double as a ready-made specification. If you can fill them in for every step, you can explain the system to a contractor.
Frequently asked questions
How many agents do we need?
As many as there are genuinely distinct steps in the process — usually between two and five. The number means nothing on its own: fifteen agents on a poorly described process work worse than two on a well-described one.
Do the agents talk to each other directly?
Usually not. They exchange data through shared storage or a queue rather than "conversing". That is more robust: every step is visible and each can be re-run independently.
Is this the same as automation in n8n or Zapier?
Structurally similar, but the nature of the steps differs. In a classic scenario every step is a hard rule. In a multi-agent system some steps require interpretation: understanding what someone wrote, judging whether a request is a fit. The two are often combined — orchestration in n8n, understanding in the agents.
Where should we start?
With the one process that hurts most. How to choose it is in 5 processes to automate first.
What does launching a system cost?
The first agent — a pilot at $1,500. After that the cost does not scale with agent count: the knowledge base and integrations already exist, only logic gets added. The budget breakdown is in how much AI automation costs.
Where to start
Take one process and break it into steps the way you would explain it to a new hire. If you end up with two or three similar steps, you need one agent. If you end up with five that differ in character, you have described a future multi-agent system — but the place to start is still step one.
Want to break down a process together? We run a free audit and will say plainly if the complexity is not warranted.