In brief
- Multiple agents are worthwhile only when work divides naturally into accountable, testable subtasks.
- An orchestrator or defined process decides which agent works when and how results are combined.
- Every extra hand-off can lose context, amplify errors and increase latency and cost.
- A single agent or workflow should be evaluated on the same cases as a simpler baseline.
How can multiple agents work together?
In a manager pattern, one central agent decomposes the assignment, calls specialists and combines their results. In a hand-off pattern, one agent transfers the case to another. Parallel patterns ask several agents to handle independent perspectives that are then combined by rules or an accountable decision maker.
Roles should reflect technical boundaries such as different data domains, tools or evaluation criteria. Several named personas with the same context and permissions mostly add complexity.
| Pattern | Control | Useful when | Main risk |
|---|---|---|---|
| Manager and specialists | One central agent assigns and combines subtasks | Decomposition varies while specialist outputs remain testable | The manager loses evidence or combines contradictions incorrectly |
| Hand-off | One agent transfers the complete case to the next role | Ownership and access boundaries change clearly | Intent, context or open issues disappear during transfer |
| Parallel | Several roles work independently before results are combined | Perspectives are independent and time saving is measurable | Duplicate work and conflicting results without a clear decision |
| Workflow with agent steps | Software fixes sequence and hand-off contracts | The overall process is stable but individual steps need flexible AI | Overly rigid interfaces or unnecessary model calls |
When does division provide a real advantage?
Division can help when one context becomes too large, teams have separate access boundaries or subtasks should be scaled and evaluated independently. Each agent then receives only the information and tools needed for its role.
- Subtasks have distinct objectives and testable outputs
- Data or permission boundaries should remain technically separated
- Specialist contexts would overload a single agent
- Parts can run in parallel and demonstrably save time
Which additional risks appear?
A wrong intermediate result can be treated as fact and amplified by later agents. Hand-offs can lose sources, uncertainty or the original user intent. The number of possible paths also grows, making evaluation and troubleshooting harder.
- Duplicate or conflicting actions caused by unclear ownership
- Loss of provenance and uncertainty at interfaces
- Unpredictable loops, latency and model spend
- A larger attack surface through additional tools and messages
- Unclear accountability for the combined final result
How should the architecture be chosen and evaluated?
Start with a simple baseline: a workflow or one agent. Add a role only when a concrete boundary or measurable quality gain justifies it. Every hand-off should use a defined schema containing output, evidence, uncertainty and status.
- Step 1
Justify the split
For each role, record the problem it solves compared with a simpler design.
- Step 2
Define contracts
Specify inputs, outputs, evidence, failures and stop conditions for every hand-off.
- Step 3
Evaluate separately
Test individual agents and their permissions in isolation on representative cases.
- Step 4
Compare the complete system
Measure quality, latency, cost and troubleshooting effort against the baseline.
Example: preparing a tender response
A coordinator separates a requirement list into defined domains. A product agent reads approved product data, a compliance agent checks authoritative evidence and a calculation service returns structured prices. Every part includes sources and open issues. An accountable person reviews the combined dossier and approves it. No agent independently invents or sends customer-specific commitments.
What to remember
Use multiple agents only when subtasks, permissions and hand-offs can be separated clearly and the more complex architecture performs measurably better than a simpler alternative.
Sources and further reading
These primary sources provide further detail on definitions, technical foundations or responsible use.
Content reviewed