What is a multi-agent system?
Split one job across five agents and a wrong answer has five places to hide. Nobody can tell you which one produced it.
Multi-agent system
Agent orchestrationMulti-agent architecture
A multi-agent system is a setup where several AI agents each handle part of a task and pass results to one another. One agent does not do the whole job, and each gets its own instructions and its own tools.
Two shapes cover almost every build. A lead agent breaks the job into pieces and hands each to a worker, then puts the answers together. Or the work moves down a line, where each agent finishes its part and passes the result on.
The word agent is doing real work here. Every one of these parts decides its own next step and calls tools to act. Chain together five prompts on a fixed path and you have a pipeline, whatever the diagram calls it.
The split is a cost, not a feature
Every handoff is a place the job can go wrong. One agent gives you one prompt to fix, one log to read, one bill per run. Five agents give you five of each, plus the question of which one was wrong.
So the split has to pay for itself. It pays when the parts need different tools and different instructions. Reading a contract is not the same job as querying your billing database, and one prompt covering both does neither well. Separate agents also let you hold a risky step for approval on its own.
It does not pay when the pieces are just steps in a fixed order. Write that as code. Code is cheaper, faster, and it fails in a way your team can read.
- 01Cost climbs with every agent, because each one runs its own model calls.
- 02Latency stacks up. A reader waits for the whole chain, not the fastest link.
- 03One weak result early gets treated as fact by everything downstream.
- RouteLead agent picks who works.
- SplitEach worker gets its own brief.
- ActWorkers call their own tools.
- MergeResults come back to the lead.
- CheckSomeone has to grade the join.
Most teams build the first four stations and skip the fifth. That is where the wrong answers get through.
Common questions
01How many agents is too many?
More than you can debug on a bad afternoon. There is no magic number. Every agent you add multiplies the paths a request can take, and a team that cannot draw the whole flow on a whiteboard cannot support it at 2am. Start with one. Split only when a part needs its own tools or its own approval step.
02Is a multi-agent system the same as multiple LLM calls?
No, and the difference is who chooses the order. Several model calls on a fixed path is a pipeline you wrote. In a multi-agent system each agent decides its own next step and picks its own tools, so the path changes run to run. That flexibility is the whole point and the whole risk.
03Do the agents need to use the same model?
They do not, and mixing is often the cheaper build. A small fast model can classify and route while a stronger one does the reasoning that needs it. Give each agent its own eval set. A model swap on one worker can quietly change what the whole system returns.
04What breaks first in production?
Tracing. Everything works until the day a customer disputes an answer, and the team finds they logged the final output but not the intermediate handoffs. Decide what you log before launch. Retro-fitting a trace across agents means rerunning history you no longer have.
