When to use one AI agent or a team
Add agents when separate work, context, or permissions justify them. Compare a single-agent baseline against coordination cost, quality, and recovery needs.
On this page
Before adding another agent, name the problem it solves. Independent research, separate tool permissions, and a task that needs more information than one agent can handle well are plausible reasons. A diagram that looks more sophisticated is not evidence that the system will work better.
We would keep a single-agent or fixed-workflow baseline and compare the proposed design against it. The decision should include quality, latency, cost, and the ability to recover when one part fails.
TL;DR Add agents when work can be separated usefully. Compare the whole team with one agent or a fixed workflow, including quality, cost, delays, and recovery. Keep one owner for the final result.
Identify work that can be handled separately
Start by mapping dependencies. Can one piece of work finish without waiting for another agent's interpretation? Can its result be checked independently? Who resolves disagreements?
Parallel research is one useful case. Different workers can investigate separate sources and return evidence to a coordinator. By contrast, dividing a tightly coupled decision across agents can force them to repeat the same context and negotiate every change.
Separate permissions can also justify different roles. A read-only investigator and an action-taking executor may need different tool access. Enforce that boundary in the application; naming an agent "read-only" in its prompt is insufficient.
Treat published results as evidence about a workload
Anthropic's account of its research system reports a 90.2% improvement over its single-agent comparison on an internal research evaluation. The same article reports much greater token consumption and describes workloads where coordination is a poor fit.
That is useful evidence for evaluating broad research tasks. It is not a predicted gain for your support agent or a universal cost multiplier. The models, budget, tools, and mix of tasks affect the comparison.
Specify what passes between agents
A handoff needs more than a paragraph of generated text. Define the task, allowed tools, required evidence, and completion conditions. Return source references and unresolved questions alongside conclusions.
Assign one owner for the final result. That owner needs rules for conflicting evidence, duplicate work, and missing outputs. Otherwise the system can produce a polished synthesis of mutually inconsistent claims.
Avoid letting several agents update the same external record without coordination. Use version checks, transactions, or a single authorized writer as appropriate. Parallel reasoning does not make concurrent writes safe.
Compare against the simpler system fairly
| Measure | What to include |
|---|---|
| Quality | Correct outcomes and important failure categories |
| Cost | Every worker, coordinator, retry, and escalation |
| Latency | End-to-end time, including slow workers |
| Recovery | Partial results, timeouts, and interrupted writes |
| Review burden | Human effort needed to verify or repair results |
Choose the comparison that matches your decision. An equal-budget comparison asks whether the architecture uses resources better. A production comparison asks whether the extra quality is worth the actual extra spend. State which question you are testing.
Use ordinary and difficult cases that were not used to design the system. OpenAI's evaluation guidance stresses task-specific evaluations; one impressive completed task is not a release test.
Add recovery before adding more workers
Bound worker count, runtime, and retry policies. Save completed work so an interrupted coordinator does not rerun everything. Decide whether a partial result is useful or must be withheld.
A reviewer agent can help find gaps, but agreement between agents is not proof. Check claims against sources, and use code to verify facts such as record IDs and totals where possible. This is the same distinction that matters for confidently wrong AI answers.
If the proposed architecture cannot explain who owns an incomplete task, it is not ready for more concurrency. The demo-to-production review should cover the entire workflow, not each agent in isolation.
Pick one workload where separation appears useful, implement that boundary, and compare it with the baseline. Keep the extra agent only if the measured benefit justifies the added system you will operate.
Sources
- Anthropic: How we built our multi-agent research system
- Anthropic: Building effective agents
- OpenAI: Evaluation best practices
Common questions
When are multiple agents useful?
When are multiple agents useful?
When work benefits from independent investigation, separate context, specialized tools, or distinct permission boundaries. Measure whether those benefits exceed coordination and operating costs.
Do multiple agents always improve accuracy?
Do multiple agents always improve accuracy?
No. They can introduce inconsistent assumptions, repeated work, and errors passed between agents. Evaluate the full system against a simpler baseline.
Is a reviewer agent independent verification?
Is a reviewer agent independent verification?
It is another model judgment. It may catch mistakes, but shared assumptions and correlated errors remain possible. Use external evidence and deterministic checks where available.
Should every workflow step have its own agent?
Should every workflow step have its own agent?
No. Known steps may be ordinary functions or a fixed workflow. Give a model decision-making control only where the task needs it.
