Quick answer: Start with one agent and a small tool set. Use multiple agents only when separate specialists need materially different instructions, tools, permissions, models or ownership. Multi-agent systems can improve isolation and parallel research, but they add routing errors, duplicated context, more approvals, higher cost and harder evaluation.
“Multi-agent” can mean several different designs: a router hands a conversation to a specialist, a manager calls specialist agents as tools, or independent agents collaborate through a protocol. The right choice starts with who owns the final answer and the external action.
Comparison at a glance
| Dimension | Single agent | Multi-agent system |
|---|---|---|
| Ownership | One agent controls the run | Control routes or delegates between specialists |
| Prompting | One main instruction set | Several contracts and routing descriptions |
| Tools | Shared allowed surface | Tools can be isolated by specialist |
| Context | Easier to keep coherent | Must transfer or filter state between agents |
| Latency and cost | Usually lower | More model calls and duplicated context |
| Debugging | One trajectory | Routing plus specialist trajectories |
| Best fit | Bounded task with related capabilities | Distinct domains, policies or parallel subtasks |
Single-agent architecture
One agent receives the goal, chooses tools and produces the final response. It can still call many functions, retrieve data and request approval.
Advantages:
- simpler state and evaluation;
- fewer model calls;
- one owner for the final answer;
- less prompt duplication;
- easier approval and error handling.
Limitations:
- a large prompt can mix incompatible responsibilities;
- a broad tool list can hurt selection;
- policies may become difficult to isolate;
- one model configuration must serve every branch.
Use tool grouping or dynamic loading before assuming you need more agents.
Multi-agent architecture
Multiple agents receive separate roles or tasks. Common patterns:
Handoffs
A triage agent transfers control to a specialist. OpenAI's orchestration guidance uses handoffs when the specialist should own the next conversation branch.
Example: Billing agent takes over a refund discussion because it has different tools and approval policy.
Agents as tools
A manager calls specialists for bounded results and retains the final answer.
Example: A research manager calls legal-document and market-data specialists, then synthesizes one report.
Parallel workers
Several agents investigate independent parts of a task. Anthropic has described a multi-agent research system where subagents explore different directions. Parallelism can improve coverage when subtasks are genuinely separable.
Peer-to-peer agents
Independent agent systems communicate across service or vendor boundaries. A2A is designed for agent-to-agent interoperability; it is not the same as using MCP to expose tools. See MCP vs A2A.
When one agent is enough
Stay with one agent when:
- the final owner is clear;
- tools share one permission model;
- task context is strongly connected;
- one model can handle the work;
- a deterministic router can cover simple branches;
- latency and cost are important;
- the evaluation dataset is still small.
OpenAI's current agent guidance says to add specialists only when they materially improve capability isolation, policy isolation, prompt clarity or trace legibility.
When multiple agents help
Split when:
- a specialist requires a distinct credential or tool surface;
- policy or approval differs materially;
- the next branch needs a different model or output contract;
- parallel independent research improves coverage;
- a specialist can be evaluated as a reusable capability;
- conversational ownership should transfer visibly;
- organizational or service boundaries already exist.
Do not split merely to give every department an “agent.” Architecture should follow contracts, not an org chart.
The context transfer problem
Passing full conversation history to every specialist wastes tokens and can leak unnecessary information. Passing too little causes incorrect assumptions.
Define a handoff contract:
- user goal;
- authenticated identity and tenant reference;
- verified facts with provenance;
- work completed;
- unresolved question;
- allowed actions;
- expected output schema;
- return or escalation path.
Keep secrets and code-only context outside model-visible handoff data.
Tool and permission isolation
Multi-agent systems can reduce capability exposure. A research agent may have read-only search, while a billing agent can prepare—but not approve—a refund. The final operation should still be checked by a central authorization and policy layer.
MCP can expose different servers or allowed tool subsets to specialists. Use MCP security best practices and how MCP works when designing the connections.
Failure modes unique to multi-agent systems
- Wrong routing to an underqualified specialist.
- Ping-pong handoffs with no owner.
- Contradictory conclusions without resolution policy.
- Duplicate external actions by two agents.
- Lost approval or identity context.
- Hidden prompt injection propagating between agents.
- Expensive context replication.
- Partial success presented as complete.
- Difficult attribution of the final decision.
Use globally unique operation identifiers, explicit ownership and a shared task ledger controlled by trusted code.
Evaluation strategy
Evaluate three layers:
Specialist
Can each agent complete its bounded job with the right tools and policy?
Router or manager
Does it choose the correct specialist, pass sufficient context and regain control correctly?
End-to-end system
Does the workflow achieve the user goal without duplicate action, policy violation or unacceptable cost?
The AI agent evaluation guide provides a full scorecard.
A migration path
- Build one agent for one task.
- Inspect traces and categorize failures.
- Isolate a specialist only when failures map to a distinct contract.
- Define typed handoff input and output.
- Keep external write authorization centralized.
- Evaluate routing and specialist separately.
- Add parallelism only for independent work.
Visual architecture tools such as Lynara may help document multi-layer systems, while OpenWeave is listed around execution governance for agents. Verify current capabilities directly.
Frequently asked questions
Are multi-agent systems more accurate?
Not automatically. Specialization and parallel search can help, while routing and context-transfer errors can make the system worse. Measure the full workflow.
How many agents should a system have?
Use the fewest agents that create clear capability or policy boundaries. There is no optimal universal number.
Can multiple agents share memory?
They can share an application-controlled task store. Define which facts are authoritative, who may write them and how provenance is preserved.
Is a tool-calling agent a multi-agent system?
No. Calling ordinary tools does not create another agent. A specialist agent has its own model-driven contract and behavior.
OpenWeave
Preflight.sh
dullnote
ClawHost
Ship Studio