TL;DR for devs
- Split work across agents for distinct tools or permissions, different instructions, independent subtasks or clear ownership.
- Manager pattern: one agent stays responsible and calls specialists. Handoff pattern: control transfers to a specialist.
- Multiple agents add cost, latency, error points, harder debugging and conflicting outputs.
- Keep each agent's permissions narrow and enforce authorization outside prompts.
- Start with one agent or a fixed workflow and split only when a measured problem calls for it.
Manager and handoff patterns, plus the cost, debugging and security trade-offs
Imagine asking an AI system to research a product category, compare several options, check current pricing, and prepare a recommendation. One agent could do the whole task. Or a system could assign research to one specialist, calculations to another, and final synthesis to a manager.
This is a multi-agent system: multiple agent instances or roles collaborate within an application. The idea sounds powerful, but it introduces new questions. Who decides which agent should work? How do they share information? Which one owns the final answer? How does the system detect conflicting or low-quality results?
A multi-agent architecture is useful when separate roles make the work clearer or more manageable. It can be wasteful when a single agent or fixed workflow already handles the task well. This guide explains the trade-offs with a beginner-friendly example and a simple Python orchestration pattern.
What Is a Multi-Agent System?
A multi-agent system uses two or more agents to handle a task. Each agent may have its own instructions, tools, or area of responsibility. A coordinator may route work to specialists, combine results, or transfer control to a specialist that takes over the interaction.
For a research report, roles might include:
- Research agent: finds information from approved sources.
- Analysis agent: compares data and identifies trade-offs.
- Review agent: checks that claims are supported and required sections are present.
- Coordinator: decides which work to request and prepares the final response.
These roles can be implemented as separate model calls, separate agent configurations, or a combination of models and ordinary code. The important thing is the division of responsibility, not the number of model instances.
OpenAI’s orchestration and handoffs guide describes two common patterns: a manager can call specialists as bounded tools, or a handoff can transfer control so a specialist owns the next response. Anthropic’s Building Effective Agents also discusses workflow patterns such as routing, parallelization, and evaluator loops.
Why Split Work Across Agents?
There are several reasons teams consider multiple agents:
Distinct tools or permissions
A research role may need read-only search tools. A publishing role may need access to a content platform and require approval before posting. Separating responsibilities can make the permission boundary clearer.
Different instructions
A data extraction agent and a customer-facing writer need different output styles. Focused instructions can reduce confusion compared with one very broad prompt.
Independent subtasks
If three sources can be reviewed independently, separate workers may process them at the same time. A coordinator can then merge the results.
Clear ownership
A billing specialist may need to take over a billing conversation. A handoff pattern can make it clear which agent now owns the next response.
These benefits only matter if the roles are genuinely different. Creating several agents with nearly identical instructions and tools may add overhead without improving quality.
The Manager Pattern
In a manager-style design, one agent remains responsible for the user-facing answer. It calls specialists as tools, receives their bounded outputs, and synthesizes them.
For example, a product-comparison manager might ask a research specialist to retrieve current plan details and a calculator function to compute team cost. The manager still checks whether the information is enough and writes the final recommendation.
This pattern works well when:
- The user should receive one coherent answer.
- Specialists perform bounded subtasks.
- The manager needs to compare or reconcile their results.
- You want one stable owner for the final response.
The manager itself needs safeguards. It should not treat a specialist’s claim as automatically true. It may need source links, timestamps, confidence markers, or structured fields to verify the result.
The Handoff Pattern
In a handoff design, a routing agent transfers control to a specialist. That specialist then takes responsibility for the next stage of the conversation. A support assistant might route a billing issue to a billing agent, which asks follow-up questions and handles the case under its own instructions.
A handoff is appropriate when the specialist should own the conversation rather than merely provide information behind the scenes. Make the routing conditions clear, and ensure the specialist receives only the context it needs.
If a user’s request crosses specialties, the system needs a way to transfer or coordinate again. Avoid confusing users with internal agent changes. The user-facing experience should still feel like one service, even if several components collaborate behind it.
A Practical Example: Preparing a Market Brief
Suppose a user asks for a short market brief comparing three project management products for a small design team. A multi-agent workflow might be:
- The coordinator extracts constraints: team size, needs, budget, and deadline.
- A research specialist finds current product and pricing information from approved sources.
- An analysis specialist calculates team costs and compares features.
- A reviewer checks whether each claim has evidence and whether the recommendation addresses the user’s requirements.
- The coordinator writes the final brief, noting missing or uncertain details.
This plan has several explicit contracts. The researcher returns source URLs and dates. The analyst receives structured data rather than vague prose. The reviewer checks a defined rubric. The coordinator owns the final response.
A structured response might look like:
{
"product": "Example Tool",
"monthly_price_per_user": 12.0,
"team_size": 5,
"source_url": "https://example.com/pricing",
"checked_at": "2026-10-22",
"unknowns": ["Annual discount terms"]
}
Contracts like this help reduce ambiguity between agents. They also make it easier to inspect outputs and identify which stage introduced an error.
A Simple Python Orchestration Pattern
The following example uses placeholder functions to show the control flow. It is not tied to a particular provider SDK; real agent APIs have their own interfaces.
from dataclasses import dataclass
@dataclass
class ResearchResult:
facts: list[dict]
sources: list[str]
unknowns: list[str]
def run_market_brief(request: str) -> str:
requirements = extract_requirements(request)
research: ResearchResult = research_agent(
category=requirements.category,
constraints=requirements.constraints,
)
analysis = analysis_agent(
facts=research.facts,
team_size=requirements.team_size,
)
review = review_agent(
draft=analysis,
sources=research.sources,
required_checks=["claims have sources", "unknowns are disclosed"],
)
if not review.passed:
return "I could not verify enough information to prepare a reliable brief."
return coordinator_agent(
request=request,
research=research,
analysis=analysis,
)
The central lesson is that the coordinator controls sequence and completion. Each specialist has a bounded job, and the application can reject a result that fails a review. For predictable tasks, some of these “agents” could be regular functions instead. For example, multiplying a per-user price by team size should be done with Python arithmetic, not delegated to a language model.
Sequential or Parallel Agents?
Some subtasks depend on earlier results. For instance, analysis cannot compare products until research has identified them. That work should happen sequentially.
Other subtasks may be independent. Separate researchers could inspect different products at the same time. Parallelism may reduce total waiting time, but it can increase the number of model calls and make synthesis more important. Agents may use inconsistent definitions or find conflicting values.
Before running tasks in parallel, define:
- What each worker is responsible for.
- Which sources or tools it may use.
- The expected output format.
- How the coordinator resolves conflicts.
- What happens when a worker fails or returns incomplete data.
Parallel work is most effective when the subtasks are truly independent and the combined result can be checked.
Multi-Agent Risks and Trade-Offs
More cost and latency
Every agent may add model calls, tool calls, and time. A request that took one response may become a chain of several operations. Measure the improvement against the added expense and wait time.
More places for errors
A researcher can retrieve a wrong fact, an analyst can misinterpret it, and a coordinator can present it too confidently. Each handoff can lose context or meaning.
Harder debugging
A single-agent failure may be easier to inspect than a failure spread across four traces. Use clear logs and stable identifiers to connect the steps of one run.
Conflicting outputs
Two specialists may disagree. The coordinator needs an explicit policy: verify against the source of truth, ask for human review, or disclose the uncertainty. It should not select whichever answer sounds more confident.
Security and permission complexity
Every agent toolset creates an access surface. Keep permissions narrow, enforce authorization outside prompts, and ensure retrieved context cannot silently change system rules.
How to Decide If You Need Multiple Agents
Start with one agent or a fixed workflow. Measure where it struggles. Consider splitting only when a concrete issue appears, such as:
- The prompt has become difficult to maintain because roles conflict.
- Different tasks genuinely need different tools or permissions.
- Independent work can safely run in parallel.
- A specialist produces a materially better result on a bounded task.
- The application needs a clear ownership transfer.
Then compare the single-agent version and multi-agent version on the same evaluation set. Check accuracy, completion rate, latency, cost, tool selection, and failure handling. More agents are justified only if they improve the outcomes that matter enough to offset the coordination cost.
Frequently Asked Questions
Are multiple agents always better than one?
No. Additional agents add prompts, calls, coordination, and opportunities for error. A single agent or normal program may be simpler and more reliable for many tasks.
What is the difference between an agent handoff and calling an agent as a tool?
When an agent is called as a tool, a manager usually stays responsible for the final response. A handoff transfers control to a specialist that owns the next part of the conversation. Choose based on who should own the user-facing interaction.
Can multi-agent systems work in parallel?
Yes, when subtasks are independent. The system still needs to combine results, handle disagreements, and verify important claims.
Should every specialist be a separate model?
Not necessarily. A specialist may be a distinct prompt or configuration using the same underlying model. Some tasks are better handled by a regular function or service.
How do I prevent agents from trusting incorrect outputs from one another?
Use structured outputs, preserve sources, validate claims against authoritative data, and define how to handle uncertainty. A handoff does not make information trustworthy by itself.
Conclusion
Multi-agent systems can help when a task benefits from distinct roles, separate permissions, or parallel work. A manager can call specialists while keeping ownership of the final response, or a handoff can transfer control to a specialist that should take over the conversation.
Start with the simplest design that works. Add specialists only when their responsibilities are meaningfully different, define the information they exchange, and make the coordinator accountable for validation and completion. Measure the result against a single-agent or fixed-workflow baseline. The goal is not to maximize the number of agents; it is to deliver a clearer, more reliable outcome for the user.
References
I write about building AI agents and full-stack AI apps. Follow me for the next one, and tell me in the comments: Have you hit a task where one agent wasn't enough? What made you split it?
Top comments (1)
I build Aladdin, a job agent. This manager pattern is the one we ended up with, for the reason you give in the TL;DR.
One agent holds the application and stays responsible for the final answer. A fresh worker reads the actual page and form for each application, because the form is the source of truth for that run. If the worker cannot read the form, or an answer is unknown, it returns that as unknown instead of filling in a guess. The manager then asks the user.
The part I would add is your line about not treating a specialist claim as automatically true. We learned that with fit scores too. A score on its own is easy to pass along. A score with reasons, and the source it came from, is what lets the manager check it before it goes out.