What a multi-agent system is
It is an arrangement where one task is completed by several specialised agents, each with its own instructions, tools and permission scope, plus a defined mechanism for passing results between them. The idea borrows from how human teams are organised: instead of one person doing everything at an average level, several specialised roles with an explicit handoff.
Why split at all
- Different permissions: an agent that reads sensitive financial data should not also hold external messaging rights.
- Different tools and knowledge: a legal agent relies on entirely different documents from a shipping agent.
- Different owners: when two departments own the definition of quality, one instruction set rarely satisfies both.
- A need for independent review: a second agent checks the first one's output against written criteria before it counts.
Coordination patterns
1) Central orchestrator
One agent receives the goal, distributes sub-tasks to specialists, and assembles the results. It is the easiest to trace and diagnose and fits most business cases, because responsibility for the final outcome stays in one place.
2) Sequential handoff
A chain: each agent finishes its stage and passes a defined output to the next. It suits processes with natural stages (intake → verification → pricing → dispatch), and its precondition is a clear data contract between every pair of stages.
3) Independent reviewer
An agent whose only job is to evaluate another agent's output against a checklist: did it follow policy, are the figures sourced, is the action within scope? Used for high-impact work, it raises quality at the cost of extra latency and spend.
One agent or a team?
| Situation | Right design | Why |
|---|---|---|
| One task, few tools | Single agent | Splitting adds complexity with no return |
| Permissions of differing sensitivity | Team with separated scopes | Limits blast radius on error |
| Stages with different owners | Sequential handoff | Each stage has its own quality definition |
| High-impact output | Executor plus reviewer | Independent check before it counts |
| Fast exploration | Single agent | Quicker to change and measure |
Risks and cost
Every extra handoff means possible context loss: the second agent knows only what was explicitly written into the passed output. Calls multiply, so latency and cost rise. Diagnosis gets harder too: a wrong result from the third agent may trace back to how the first phrased its output. That is why any multi-agent system needs a unified trace showing the full task path.
Checklist before splitting
- Is the current agent actually failing? Name the failure: missing knowledge, too many tools, or conflicting instructions?
- Is the failure a permission conflict? If so, splitting is justified on security grounds, not just performance.
- Can you specify the exchanged output precisely? If not, the handoff will break.
- Who owns the final result? One clear accountability must remain.
- How will you measure the improvement? Define the metric before building, not after.
If you want applied examples of agent teams working together inside one department, see the agent teams pages on the platform.