Guide · Advanced · 10 min
Multi-agent systems: when several agents work better than one, architectures, costs, and pitfalls
Multi-agent systems divide work among specialized agents. Learn when to use them, how to organize their work, and how to keep costs and failures under control.
A multi-agent system becomes useful when work can be split into independent assignments, requires specialized contexts, or needs separate permissions. It can improve coverage and shorten some completion times, but it also introduces communication overhead, costs, and additional ways to fail. Compare its results with those of a properly equipped single agent, then keep only the delegations whose benefits you can measure.
What separates multiple agents from a simple workflow
A multi-agent system coordinates several agents that can make decisions within their assigned scope. Each receives an assignment, may use tools, and returns a result. They can share the same model: their separation also comes from their instructions, context, state, and access rights.
Chaining extraction, translation, and formatting does not automatically create a team of agents. If each step performs a predefined operation, you have a workflow. This is often the better choice for a stable process because its execution path is easier to inspect and verify.
Orchestration determines who receives which task, in what order, with what information, and under which stopping rule. It can be programmed, decided by a model, or combine both approaches. Allowing flexibility in one decision does not require making the entire system flexible.
Anthropic’s foundational guide, Building effective agents, draws this distinction between predefined paths and dynamic decisions. It helps address a common misconception: adding more named roles does not demonstrate greater autonomy or better quality.
The directory of agents and frameworks brings together profiles of the relevant software. Your architecture should still start with the business need, before you choose a framework or describe the system as a team.
When delegation provides a benefit
The first promising case is research that can be divided into separate investigations. When comparing vendors, agents could independently examine technical documentation, contractual terms, and integration options. A coordinator then brings the findings together using a shared evaluation framework. This describes a possible architecture, rather than a measured customer deployment.
The second case is context isolation. An investigation can produce large amounts of documentation and intermediate findings, only a small portion of which matters to the final decision. A subagent can explore that material and return an evidence-backed summary without filling the main conversation with every detail.
The third case involves operational boundaries. One agent reads public information; another queries an internal system with restricted access. This separation provides protection only when the infrastructure actually enforces those restrictions.
In its technical account of its multi-agent research system, published in June 2025, Anthropic describes a coordinator working with parallel subagents. The account covers its own implementation. It does not establish that a similar architecture improves every kind of task.
Keep a single agent when the steps are tightly dependent on one another, the context fits comfortably into one session, or the assignment is short. Before introducing delegation, also check whether better tools, clearer instructions, or more targeted access to documentation would solve the problem.
Architectures and their tradeoffs
The following patterns address different constraints. You can combine them, but each combination increases the number of transitions you need to explain, monitor, and test.
| Architecture | Organization | Suitable use | Coordination overhead | Main pitfall |
|---|---|---|---|---|
| Sequential chain | Each agent passes its output to the next | Specialized stages with distinct deliverables | Successive handoffs | An early error propagates |
| Coordinator and workers | One agent delegates and assembles the results | Divisible research, focused investigations | Planning and synthesis | The coordinator becomes a bottleneck |
| Routing | A request goes to the selected specialist | Clearly separated request categories | Initial classification | Incorrect routing |
| Handoff | A specialist takes over the conversation | Processes requiring successive areas of expertise | Transfer of context and responsibility | Repeated handoffs or lost context |
| Production and verification | One agent produces, another checks | Outputs with verifiable criteria | Review and corrections | Misleading agreement between agents |
A sequential chain preserves a clear order, but does not necessarily reduce completion time. Parallel execution helps only when branches are independent. If every agent waits for the previous one, you are mainly adding boundaries between contexts.
A central coordinator makes it easier to assign work and assemble the final result. In return, it must understand the findings it receives, identify contradictions, and decide whether evidence is missing. Misinterpreting a summary can undermine otherwise sound investigations.
The LangChain documentation on multi-agent architectures covers patterns including subagents, routing, and handoffs. It also notes that a single agent with suitable tools and context can be enough for a complex task.
Choose a pattern based on the dependencies in the work. An organization that resembles a human reporting structure is not necessarily a good fit for a program.
Define assignments and handoffs you can verify
A role such as “quality expert” is not enough to guide a delegated task. The subagent needs a specific question, a defined scope, permitted sources, and an expected output. It also needs to know when to stop and how to report that it cannot complete the assignment.
For document research, an assignment specification can define:
- the points to establish and those outside the scope;
- the documents available and their trust level;
- the format for findings and references;
- limits on time, spending, and tool calls;
- the conditions for escalating to the coordinator.
The deliverable should distinguish established facts, assumptions, and unresolved questions. A fluent answer without references gives the coordinator little basis for verification. Request evidence that supports checking: a source passage, a relevant date, a tool result, or the identifier of the document consulted.
Avoid handoffs that routinely copy the entire conversation. They spread unnecessary data and increase the amount of material processed. An assignment stripped of too much context creates the opposite problem: the specialist must repeat exploration that has already been completed.
Useful context includes the relevant overall objective, applicable constraints, and supporting material. The coordinator should maintain a task register recording the owner, status, dependencies, expected deliverable, and reason for stopping. This makes it possible to identify abandoned tasks, duplicate work, and findings that arrive after the final decision.
Manage shared state and tool access
Separate each agent’s state from the information that serves as the authoritative record for the whole system. Exploratory notes can remain local. Approved decisions, deliverables, and references should go into a controlled space with provenance and version information.
When working with files, assign responsibility for writes explicitly. Agents editing the same document at the same time can overwrite one another’s changes or work from incompatible assumptions. Separate workspaces followed by controlled integration make conflicts visible.
Recovery after a failure deserves the same attention. Before retrying an action, check whether it already succeeded. Creating a ticket or sending a message should not happen again simply because the tool’s response was lost. Use operation identifiers and deduplication mechanisms when the service supports them.
Protocols do not automatically resolve these issues. The official MCP architecture describes communication between applications and servers that expose tools, resources, and other capabilities. It does not replace your task assignment policy.
The A2A protocol documentation addresses communication and collaboration between agents. An internal system can operate without this protocol; its value depends on your interoperability needs.
In every case, define who can read, write, and forward each piece of data. A message between agents is still a transfer of information, even when both agents belong to the same project.
Calculate the cost per accepted task
The number of agents does not directly predict the bill. Cost depends on model calls, the volume of material processed, paid tools, infrastructure, and retries. A team using short contexts can consume less than a single agent that repeatedly reads a long conversation history.
For each call, distinguish input tokens, output tokens, and any categories billed separately. Apply the rates actually used, then add up spending across the agents and coordinator. The LLM pricing calculator helps you prepare these estimates.
Hypothetical arithmetic example, with no performance measurement. The Claude Sonnet 5.5 profile lists $2 per million input tokens and $10 per million output tokens, according to the site’s October 2026 pricing record. At those rates, a hypothetical call with 10,000 input tokens and 2,000 output tokens costs $0.04, excluding other costs and pricing mechanisms.
Four identical calls would therefore cost $0.16. That does not necessarily mean four agents: a single agent can make those calls, while a team can make many more. The example illustrates a calculation method, rather than a typical budget.
Above all, measure cost per accepted task: spending across all attempts divided by the number of results that meet your criteria. Track human correction time separately. An architecture that costs less per attempt can become more expensive if it needs more retries.
Control completion times, budgets, and stopping conditions
With parallel execution, completion time depends on the slowest branch, followed by final integration. You also need to account for queues, service limits, and any human checks. Launching more tasks therefore does not guarantee a faster answer.
A branch can also become unnecessary after a discovery elsewhere. Provide a cancellation mechanism and a way to recover its partial work. Otherwise, the system keeps spending after the decision has already been made.
Set limits at several levels: the overall assignment, each subtask, and each tool. These can cover time, spending, attempts, or delegation depth. The coordinator must not be able to bypass a cap by creating additional workers.
Define exit states as well: complete result, partial result, technical blockage, insufficient evidence, or approval required. A budget overrun should not be disguised as an apparently complete answer.
The guide to reducing AI agent costs explores context management, routing, and budgets in more detail. For multi-agent systems, add another rule: every new delegation needs an explicit reason.
Choose a framework around operational constraints
It helps to distinguish two approaches. LangGraph lets you explicitly represent a system’s steps and transitions. Its documentation on workflows and agents covers patterns including routing, parallel execution, and coordination.
CrewAI organizes work around concepts including agents and tasks. Its process documentation describes sequential and hierarchical arrangements. These concepts can make it easier to represent how responsibilities are distributed.
| Design criterion | Explicit graph approach | Team and task approach |
|---|---|---|
| Work description | States, transitions, conditions | Assignments, roles, delegations |
| Desired control | Visible paths and recovery steps | Clear task allocation |
| Main concern | Graph complexity | Delegation that is too open-ended |
| Required verification | Transitions and persistent state | Assignments and transferred deliverables |
This table compares approaches, rather than drawing an absolute boundary between products. A framework can offer several abstractions; their availability does not prove that your application handles failures correctly.
Before choosing a library, check state persistence, cancellation, execution inspection, secret management, and the ability to replace a model. Test these capabilities in a scenario where something goes wrong.
The article on choosing an AI agent framework complements this guide with a focus on learning and tools. For a limited task, orchestration programmed directly into your application may also be sufficient.
Reliability and security pitfalls
The first pitfall is shared error. Agents using the same sources or receiving the same initial assumption can converge on an incorrect answer. Their agreement does not amount to independent validation.
For review, give the checking agent observable criteria and access to the original evidence. Ask it to look for specific defects: a missing reference, an incorrect calculation, an overlooked constraint, or an unauthorized action. Software checks should handle anything that can be verified mechanically.
The second pitfall is the loss of instructions during delegation. A global constraint can disappear in a handoff. Essential rules should be enforced by the orchestrator and tools, rather than relying solely on a textual reminder.
The third concerns malicious content. An external document can induce an agent to pass a harmful instruction to its coordinator. Receiving a message from a subagent does not turn the material quoted inside it into a trusted instruction.
Restrict each worker’s permissions, keep secrets outside its context, and control outbound transfers. Approval for a sensitive action should cover its exact parameters. General approval of a plan does not authorize every consequence of carrying it out.
The guide to securing an AI agent explains these measures in more detail. In a team of agents, they need to apply throughout the delegation chain.
Evaluate the benefit before deployment
Prepare a set of representative tasks before multiplying roles. Include simple, ambiguous, incomplete, and difficult requests, along with tool outages. Define what counts as an acceptable answer for each task and what requires execution to stop.
Compare a deterministic workflow when the path is known, a single agent, and the proposed multi-agent architecture. Keep conditions comparable: data access, tools, maximum budget, and quality criteria. If you change the model and the architecture at the same time, you will not be able to attribute the improvement clearly.
Track final success, critical errors, cost per accepted result, completion times, and human interventions. Repeat trials when results vary. A favorable average can hide long stalls or expensive failures.
Then examine the traces for poor task decomposition, duplicate work, lost evidence, incorrect synthesis, or excessive permissions. Temporarily remove a delegation to check its contribution. If removing it does not make the result worse, that part of the system is a candidate for simplification.
Before opening the system to production use:
- Every assignment has a deliverable and a stopping rule.
- Budgets and permissions are enforced technically.
- Concurrent writes and retries are controlled.
- Evidence remains available to the reviewer.
- Results have been compared with a simpler solution.
- Sensitive actions have an appropriate approval process.
Finally, retain a way to return to the previous setup. A multi-agent architecture earns its place through broader coverage, greater reliability, or results delivered within a useful time frame, at a cost you can explain. The number of participants is a design choice, never a measure of quality.
Related pages
Frequently asked questions
Do you need several models to build a multi-agent system?
No. Several agents can use the same model with different instructions, tools, and contexts. Using different models is a design choice that should be assessed against the quality of the results and the total cost.
Can a multi-agent system run locally?
Yes, provided the models and tools you choose can run on your infrastructure. Concurrent agents compete for available resources, however: several tasks launched together may end up waiting for the same inference engine.
What is the difference between a subagent and a tool call?
A tool performs a defined function, while a subagent can choose its own steps to complete an assignment. A coordinator can still invoke a subagent through a tool interface: the terms describe different levels of the system.
How many agents do you need?
There is no universally optimal number. Start with a simple architecture and add delegation only when it addresses a limitation you have observed. The useful number depends on independent tasks, timing requirements, and the available budget.
Can agents check each other's work?
Review by another agent can catch some errors, but it provides no guarantee. For sensitive actions, combine software checks, restricted permissions, and human approval appropriate to the consequences.