Multi Agent Systems: When One Agent Beats a Team

Start with 1 agent and better tools. Multi agent systems earn their place when separate workers can investigate independently, keep different context, or take ownership of different jobs. A planner, researcher, coder and reviewer that constantly need the same information can create more coordination work than useful progress.

The deciding question is whether a worker can receive a clear assignment, do useful work without constant consultation, and return something you can check. If it cannot, splitting the agent usually moves the difficulty into messages between agents.

The framework behavior below was verified against the makers' live documentation on 26 October 2026. The decision table applies those documented patterns to common builder tasks.

What Are Multi Agent Systems?

A multi-agent system gives separate agents responsibility for parts of a larger job and a way to exchange work. In a large language model (LLM) application, an agent is a model operating inside a loop that can choose tools, inspect their results and decide what to do next. Multiple agents coordinate those decisions instead of placing all of them inside one worker. IBM’s overview describes the broader structure of interacting agents.

The agents can use the same underlying model. What makes them separate is their execution context and responsibility, not whether their model names differ. You might give a researcher source documents and search tools, while a coder receives the repository and a precise change request.

Think of a music producer combining separately recorded tracks. Independent recording works when the musicians share a settled arrangement. If everyone is changing the tempo and rewriting the same passage, the producer spends the session reconciling incompatible recordings. Agent teams face the same choice between independent work and continuous coordination.

Multi Agent Systems in AI: The Scope of This Decision

The broader field includes robots, autonomous vehicles and simulations, as Google Cloud's overview explains. Here, the decision concerns LLM agents working on research, software and business tasks.

Several model calls do not automatically make a system multi-agent. An agent that searches, reads a file, writes code and checks its work can remain a single agent throughout. A fixed sequence of prompts can also remain a workflow with no autonomous workers. The distinction is who gets to make decisions and which context they use.

Start with the agent loop if you need the mechanics of model calls, tools and stopping. The wider AI agent architecture still needs state, permissions and observable outcomes, regardless of the number of agents.

Multi Agent System Design: Choose by Task Shape

Choose multiple agents when the boundary removes more complexity than it creates. A useful boundary separates evidence, expertise or ownership. A cosmetic boundary merely gives the next prompt a job title.

Use these defaults before choosing a framework:

For a founder, this means the first version of an assistant does not need an organization chart. For a builder, it means naming the dependency that prevents a worker from proceeding alone. For an operator, it means judging the completed case, including correction work, rather than counting how many specialists participated.

The familiar planner, researcher, coder and reviewer arrangement is a useful list of activities. It is not automatically a useful list of processes. Planning can happen inside the coding agent. Research can be a tool call. Review can begin with tests that produce a definite pass or fail.

Suppose the requested change is to fix an invoice export. If the plan depends on the database schema, and the implementation reveals an exception in that schema, a separate planner must repeatedly receive updates. Keep planning close to implementation. A separate reviewer may still help if it receives the final patch, the export requirements and the relevant test results.

Multi Agent Architecture Patterns

The patterns differ mainly in who owns the answer and how much information moves between workers. A supervisor, a hierarchy, a handoff and a group chat are arrangements you can combine, not mutually exclusive product categories.

Supervisor or Orchestrator-Worker: One Agent Owns the Result

LangGraph, a runtime for stateful agent workflows, supports a supervisor that delegates bounded work and combines the results. The supervisor keeps responsibility for the user-facing outcome; workers return findings or artifacts.

In LangChain's current supervisor tutorial, calendar and email agents are wrapped as high-level tools. The supervisor invokes those tools and receives the specialists' final responses. It does not need every intermediate operation in its own conversation.

There is an important implementation distinction: the langgraph-supervisor reference still documents create_supervisor, but recommends implementing the supervisor pattern directly through tools for most use cases. That provides more control over what context workers receive and return. The package also documents supervisors managing other supervisors.

Choose this pattern for a research brief with independent questions: investigate product capabilities, examine technical dependencies, and collect evidence from separate source sets. Each worker can finish a meaningful assignment while the lead stays accountable for the combined answer.

Its wall is integration. If every worker needs every other worker's latest discovery, the supervisor becomes a messenger. A supervisor also cannot repair missing evidence simply by writing a confident synthesis.

Hierarchical Teams: Delegate Through Managers

CrewAI, a framework for coordinating role-based agents, organizes a crew around agents, tasks and an execution process. Its hierarchical process uses Process.hierarchical with either manager_llm or manager_agent. The manager assigns work, reviews outputs and decides whether tasks are complete.

A hierarchy can extend to managers overseeing teams, though a CrewAI hierarchical crew does not by itself imply a deeply nested organization. CrewAI also supports Process.sequential, where tasks follow their defined order. Those are different execution choices, not interchangeable names for collaboration.

Consider a product assessment with a research workstream and an implementation workstream. A hierarchy is plausible when each workstream already has coherent responsibilities and produces a stable deliverable. It is much less persuasive when the entire job is a short answer and the managers mainly restate one another's instructions.

Its wall is management overhead. Each layer has to interpret the assignment and report its result. Add a layer because a team boundary exists in the work, not because a human company has departments.

Handoffs: A Specialist Takes Over

OpenAI Agents SDK, a code library for running agents and tools, implements handoffs as transfers of control to another agent. Its handoffs configuration lists the destinations that an agent can delegate to. The receiving specialist owns the next response. That differs from calling a specialist with as_tool(), where the manager retains ownership of the answer. OpenAI's orchestration documentation makes this distinction explicit.

A support conversation illustrates the difference. If a billing specialist must ask follow-up questions and resolve an invoice issue, handing it the conversation makes sense. If the main assistant only needs a billing calculation before answering a wider question, a tool or bounded specialist call may be enough.

Its wall is the transfer boundary. The receiving agent needs the relevant facts, unresolved questions and permissions. A handoff does not automatically mean that all previous work was correct or that the specialist has authority to take every action. Application code must enforce access and approval rules.

Use handoffs when ownership should change. Using them merely to make every stage a different persona adds opportunities to lose context.

Group Chat: Agents Work Through a Shared Conversation

Microsoft Agent Framework, a framework for building agent applications and workflows, implements group chat with an orchestrator that chooses who speaks next. Its Python GroupChatBuilder supports a selection function or an agent-based orchestrator, along with a termination condition. Participants have separate sessions whose conversation history is synchronized. Microsoft's group-chat documentation describes the mechanism.

This fits a proposal that improves through interaction: a writer revises the draft after a reviewer identifies a missing requirement, then another specialist checks the revised argument. Unlike independent research branches, later turns intentionally depend on earlier contributions.

Its wall is conversation growth. Participants can spend their turns discussing the work rather than changing it. Shared discussion also exposes workers to the same mistaken premise. Agreement in that conversation is not independent verification.

Give group chat an artifact to improve, a concrete acceptance condition and a stopping rule. For a task with an obvious fixed order, a simple workflow is usually easier to understand.

The AI agent frameworks comparison covers the broader implementation choice. Once you have decided a split is justified, AI agent orchestration covers coordination, state, approvals and operational controls.

Multi Agent Systems Examples: Where the Split Helps

Broad research is a stronger starting case than tightly coupled editing. Anthropic's documented Research system uses a lead agent and parallel workers that investigate separate directions before returning findings. In its published internal evaluation, a Claude Opus 4 lead with Claude Sonnet 4 subagents outperformed single-agent Claude Opus 4 by 90.2%. That is a reported relative improvement on that research evaluation, not a 90.2% success rate or a universal gain from adding agents. The comparison also changes the arrangement of models and computation. Anthropic's engineering account.

For a builder assessing integration options, the analogous task is to investigate each candidate's documentation independently and return evidence against the same requirements. The final decision still needs someone to resolve conflicting claims and missing information. Parallel research can expand the evidence available; it cannot make incompatible evidence agree.

Coding has a different dependency pattern. Independent workers might inspect authentication code, locate relevant tests and research a library's documented behavior. Those are bounded investigations. Having several workers simultaneously rewrite the same authentication flow is a much harder arrangement because their decisions can invalidate one another.

Customer support offers a different reason to split: responsibility. A general assistant can identify the issue, while a specialist handles a distinct domain. The benefit comes from the specialist's narrower instructions and tools, not from making the conversation longer.

These coding and support scenarios are design examples, not reported deployments or measured improvements. Their usefulness depends on whether the proposed worker can do something the original agent cannot do as clearly with a better tool or a better-scoped prompt.

Why Do Multi Agent LLM Systems Fail?

They can fail at the boundaries even when each worker looks competent in isolation. More agents create more assignments to interpret, more intermediate results to trust and more places where the original requirement can change meaning.

More Tokens and Waiting Between Dependent Steps

Delegation adds instructions, worker context, returned results and synthesis. Repeated attempts and shared conversation history add further work. Anthropic reports that its multi-agent systems used about 15× the tokens of chats in its own data. The baseline is chats, not single-agent runs; this is not a general planning multiplier. Anthropic's reported token usage.

Token overhead is a risk to measure, not a universal law that every multi-agent arrangement must use more. Separate contexts may avoid repeatedly loading irrelevant material. What matters is total usage for an accepted result, including failed branches and rework.

Parallel workers can shorten elapsed time only where their work is independent. A researcher that must finish before the planner can act, followed by a coder that must wait for the plan, is still a chain of dependencies. Giving those steps different names does not make them concurrent.

Harder Debugging

The final answer can hide the first wrong decision. A coder may implement a bad requirement correctly, while a reviewer approves the implementation against that same bad requirement. Looking only at the last response will blame the wrong component.

Anthropic reports that full tracing helped distinguish search, source-selection and tool failures in its research system. It also describes errors compounding across stateful agent runs. Engineering findings.

For your design comparison, ask whether you can identify the earliest divergence from the task: what the worker was told, which evidence it received, what it returned, and what the next worker treated as established fact. If you cannot inspect those boundaries, you cannot tell whether an extra reviewer improves the system or merely adds a reassuring final message.

Errors Compound Across Hops

A hypothetical researcher writes, “This endpoint appears to support exports, but the permission requirements are unclear.” A planner compresses that to “Use the export endpoint.” The coder implements the plan. A reviewer checks the patch against the plan and sees no discrepancy.

The original uncertainty disappeared without anyone resolving it. More agents participated, but none checked the missing evidence.

Return source references, explicit unknowns and the actual artifact alongside the summary. Give reviewers the original requirement rather than only the producer's account of it. These are reasons to prefer a small, inspectable team over a long sequence of loosely specified roles.

What's Overhyped About Agent Teams?

Role count is a poor measure of capability. More agents do not automatically produce more knowledge, independent judgment or faster execution. The relevant question is what new work becomes possible because of the split.

A single agent can use parallel tools, so concurrent searches alone do not require a team. It can also load specialized instructions when needed. LangChain documents a skills pattern that keeps one agent in control while bringing in relevant knowledge on demand.

Do not confuse separate prompts with security isolation, either. Calling one agent a researcher and another an approver does not restrict their access by itself. The application must enforce the tool permissions and approval boundary you intend.

The strongest argument for multiple agents is usually specific: this worker needs a distinct context, can investigate a question independently, or should own a different conversational domain. “It resembles a team” is not enough.

Your Monday Move: Compare the Smallest Useful Split

Keep a single-agent baseline and add only the worker that addresses a visible failure. If the current system succeeds, adding managers and reviewers creates a new system to justify.

1. 1

   Name the failure in the current workflow

   Choose actual tasks where the agent misses evidence, selects the wrong tools, loses requirements or produces an unacceptable artifact. Fix missing tools and unclear instructions before treating the agent count as the cause.

2. 2

   Define a bounded alternative

   For a coding assistant, keep the main agent responsible for the patch and add an independent reviewer only if review is the gap. Specify the reviewer's inputs and the evidence it must return. Avoid changing the whole workflow at once.

3. 3

   Compare accepted outcomes

   Run the baseline and the alternative on the same task set with the same acceptance criteria. Record completion quality, total tokens, elapsed time and the human work needed to diagnose or correct failures. Account for model differences when interpreting the result.

4. 4

   Keep or remove the boundary

   Retain the worker if it improves the outcome enough to justify its operational burden. If it mainly repeats context or restates another agent's work, fold that activity back into the original agent. Operators with no measured gap can wait; builders with independent research branches have a clearer reason to experiment now.

Questions About Multi-Agent Systems

Is ChatGPT a multi-agent system?

The name ChatGPT alone does not establish the architecture of a particular workflow. To call a feature multi-agent, look for documented separate agents that exchange work or transfer control. A chat interface, tool use or a long answer is not enough evidence.

What is an example of a multi-agent system?

Anthropic’s Research system delegates investigations to workers and combines their findings, an example of the orchestrator-worker pattern.

What is the best multi-agent system?

There is no universal best. Match the pattern to the task: a supervisor for bounded specialist work, handoffs for changing conversational ownership, and group chat for useful iterative critique. Keep a single agent when the split does not improve the result.

What are the big 4 AI agents?

There is no canonical industry list called the “big 4.” Planner, researcher, coder and reviewer are common role labels in proposed agent teams, not mandatory components. Define each role's work before making it a separate agent.

Is ChatGPT an agent or LLM?

ChatGPT is an application name; an LLM is the underlying kind of model. An agent describes a system that uses a model to choose actions and respond to results. These describe different layers, so inspect the specific feature rather than treating the labels as interchangeable.

What are the 7 types of AI agents?

Seven-item lists combine different classifications, such as decision rules, learning behavior, task roles or collaboration patterns. There is no fixed seven-part architecture you need to implement. For this decision, distinguish an individual agent's behavior from the arrangement of several agents.

What are the most common AI agents?

Useful business categories include support assistants, research agents and coding agents. These are task categories, not a verified popularity ranking. Their names do not establish whether they run alone, under a supervisor or through handoffs.

Can you give me some examples of AI agents?

Examples include a support agent that looks up an order and chooses the next action, a research agent that searches and checks sources, and a coding agent that edits files and runs tests. Each can be a single agent even when it takes many steps.

What are the 5 types of AI agents?

IBM describes a classical taxonomy of simple reflex, model-based reflex, goal-based, utility-based and learning agents. It classifies how an agent decides or learns. It does not prescribe how many LLM workers your application should use.

For practical decisions about building with AI, subscribe to the newsletter.