Single-Agent vs Multi-Agent Systems
A practical guide to choosing one capable agent, one agent with tools, sub-agents, or a true multi-agent architecture.
A difficult task does not automatically need a team of AI agents. One capable agent can reason, plan, remember relevant context, call several tools, inspect results, and revise its work. Adding more agents introduces specialization and parallelism, but it also introduces communication failures, duplicated work, higher cost, and a much larger system to evaluate.
The useful question is not, “How many agents can we add?” It is:
What is the simplest architecture that can complete this task reliably?
This lesson builds on the [basic AI-agent mental model](/what-is-an-ai-agent/), the [agent execution loop](/how-ai-agents-work/), and the [core components inside an agent](/anatomy-of-an-ai-agent/).
TL;DR
- A single-agent system uses one agent identity and one main decision loop, even if it makes many model calls and uses many tools.
- A multi-agent system gives multiple agents distinct roles, instructions, tools, context, or state, then coordinates their work.
- One capable agent is usually the best starting point because it is cheaper, faster, easier to debug, and easier to evaluate.
- Multi-agent designs are most useful when work benefits from real specialization, context isolation, independent review, or parallel execution.
- More agents do not automatically create a more advanced or more reliable system. Coordination must earn its cost.
What is a single-agent system?
A single-agent system has one primary agent responsible for moving from a goal to a completed result.
That agent can still be sophisticated. It may:
- interpret the user's goal;
- use [reasoning](/reasoning-in-ai-agents/) to choose the next action;
- create and update a [plan](/planning-in-ai-agents/);
- retrieve and write [memory](/memory-in-ai-agents/);
- call search, code, database, browser, or application [tools](/tool-use-in-ai-agents/);
- maintain task state across many steps;
- inspect observations and [reflect on mistakes](/reflection-in-ai-agents/);
- retry or revise its strategy.
The defining feature is not the number of steps, tools, or model calls. It is the presence of one main agent boundary: one role, one responsibility for the task, and one decision loop controlling progress.
A single research agent, for example, could search the web, read documents, run calculations, compare evidence, draft a report, check citations, and revise weak sections. That is complex behavior, but it is still one agent.
A single agent can use many tools
Tools extend what an agent can do. They do not create additional agents.
Consider a travel-planning agent with these tools:
- flight search;
- hotel search;
- weather lookup;
- maps;
- calendar;
- budget calculator.
The agent decides which tool to use, prepares the input, observes the result, and chooses the next action. Different tools perform different operations, but none independently interprets the overall goal or manages its own task loop.
This architecture is often enough because the agent already provides the flexible decision-making layer while tools provide specialized capabilities.
What is a multi-agent system?
A multi-agent system contains multiple agent boundaries that collaborate toward a larger goal.
Each agent may have its own:
- role or objective;
- instructions;
- model;
- tools and permissions;
- working context;
- memory or state;
- decision loop;
- stopping condition.
The system must also decide how work is assigned, how agents communicate, how results are combined, and what happens when they disagree or fail.
Research and production systems use several coordination patterns. Anthropic describes an orchestrator-worker research architecture in which a lead agent delegates parallel research to sub-agents. OpenAI's agent-building guidance similarly presents manager-style orchestration and handoffs as distinct multi-agent patterns. These are useful patterns—not universal requirements for complex work.
A tool executes a bounded capability for an agent. A delegated agent receives a goal and decides how to pursue it.
Specialized agents and roles
Specialization means assigning narrower responsibilities to different agents. A product-launch system might use:
- a market-research agent;
- a customer-insight agent;
- a pricing agent;
- a risk-review agent;
- an editor agent.
Specialization can improve focus because each agent sees only the instructions, tools, and context needed for its role. It can also allow different models or permission levels to be used for different jobs.
But a role label alone does not make an agent useful. If five “specialist agents” all receive the same context, use the same tools, and produce overlapping answers, the architecture may only multiply cost.
Delegation and handoffs
Delegation happens when one agent assigns a goal to another agent. The receiving agent decides how to complete that goal and returns a result.
A handoff transfers responsibility for the next part of the interaction or task. For example, a triage agent may hand a billing issue to a billing agent, which then becomes responsible for the user conversation.
The difference is ownership:
- With delegation, the original agent normally remains responsible for the overall result.
- With a handoff, control moves to another agent, at least temporarily.
Communication, shared context, and shared state
Agents need a way to exchange useful information. Common options include:
- direct messages;
- structured task and result objects;
- a shared workspace or “blackboard”;
- shared memory;
- a central task ledger;
- events sent through a queue.
Shared context is the information multiple agents can read, such as the user's objective, source documents, or a project brief.
Shared state records what has happened: tasks created, owners, progress, outputs, errors, approvals, and completion status.
Sharing everything is rarely ideal. Too little context causes inconsistent work; too much context increases cost and can distract specialists. Good multi-agent design shares the minimum information required for coordination.
Supervisors, orchestrators, and peers
A supervisor or orchestrator coordinates other agents. It may:
- break a goal into work packages;
- select agents;
- start tasks;
- track progress;
- resolve dependencies;
- review results;
- request revisions;
- combine outputs;
- decide when the overall task is complete.
The orchestrator can be an agent that reasons dynamically, or it can be deterministic software using fixed routing and state-machine rules.
In peer-to-peer collaboration, agents communicate without one permanent central supervisor. This can suit negotiation, debate, or distributed domains, but it makes ownership and termination harder to control.
Sequential and parallel collaboration
Multi-agent work can be:
- Sequential: one agent's output becomes the next agent's input.
- Parallel: independent agents work at the same time, then their results are merged.
- Hybrid: some tasks run in parallel while dependencies remain sequential.
Parallel execution is valuable only when the work is genuinely separable. If every agent needs the previous agent's full result, adding parallel workers cannot remove that dependency. Recent Google Research work on scaling agent systems likewise found that the best topology depends on task structure; “more agents” is not a universal scaling rule.
Key distinctions that prevent architecture confusion
Agent vs sub-agent
An agent is a system that receives a goal, makes decisions, takes actions, observes results, and manages progress within a defined boundary.
A sub-agent is still an agent. The word “sub” describes its position in a larger runtime hierarchy: another agent created or delegated work to it. It usually has a narrower goal, limited context, and a shorter lifetime.
Multi-agent system vs multi-step workflow
A multi-step workflow moves through several stages. Those stages may be fixed code, tools, model prompts, or human approvals.
A multi-agent system contains multiple decision-making agent boundaries.
For example:
Classify request → Retrieve policy → Draft answer → Run safety check
This is multi-step, but it is not necessarily multi-agent. If fixed code controls the stages and the model calls do not independently manage goals or actions, it is a workflow.
Agent delegation vs tool calling
When an agent calls a tool, it requests a bounded operation: search this query, run this SQL, send this email, or calculate this total.
When an agent delegates to another agent, it gives the receiver a goal with some freedom to decide the steps, tools, and stopping point.
A helpful test is:
Is the receiver executing a defined operation, or deciding how to achieve an objective?
The first is usually a tool. The second may be an agent.
Orchestrator vs agent
“Orchestrator” describes a coordination responsibility; “agent” describes a decision-making system.
Therefore:
- an orchestrator may be an agent;
- an orchestrator may also be deterministic code;
- an agent does not have to orchestrate other agents.
Do not turn routing logic into an LLM agent unless dynamic judgment is actually necessary.
Multiple LLM calls vs multiple agents
One agent can make many LLM calls—for planning, action selection, summarization, and review—while maintaining one role and one task state.
Multiple agents require meaningful separation, such as different goals, instructions, tools, contexts, state, ownership, or independent loops. Counting model calls is not a reliable way to count agents.
Single-agent vs multi-agent systems
| Dimension | Single-agent approach | Multi-agent approach |
|---|---|---|
| Complexity | One main control loop and fewer interfaces | Multiple loops plus routing, messaging, state, and synthesis |
| Cost | Usually fewer tokens and model calls | Often higher because agents repeat context, reason separately, and review each other |
| Latency | Usually lower for sequential work | Can be lower for parallelizable work but higher when coordination dominates |
| Reliability | Fewer handoff and synchronization failures | Can add independent checks, but also creates new coordination failure modes |
| Specialization | One generalist prompt and toolset may become crowded | Roles, models, tools, and permissions can be tailored |
| Context isolation | One context is easy to follow but can become overloaded | Specialists can receive smaller, cleaner contexts |
| Parallelism | Limited unless the runtime supports parallel tool work | Natural fit for independent work streams |
| Coordination overhead | Low | Requires delegation, communication, ownership, conflict resolution, and stopping rules |
| Debugging | Easier to reconstruct one trace | Requires cross-agent traces and causal links between messages |
| Evaluation | One agent and end-to-end outcome can be tested | Each agent, each handoff, and the combined system need evaluation |
| Maintainability | Fewer prompts, schemas, and interfaces | More components can be replaced independently, but contracts must stay compatible |
The multi-agent column is not a list of upgrades. Each benefit comes with another system responsibility.
When should you use each architecture?
Use this progression. Move to the next level only when the current level has a measured limitation.
1. Use one agent
Choose one agent when:
- the goal is coherent;
- the context fits comfortably;
- the task is mostly sequential;
- one model can handle the required reasoning;
- the agent needs few tools;
- low latency and simple evaluation matter.
Examples include drafting a structured brief, answering questions from a policy set, or completing a small data-analysis task.
2. Use one agent with many tools
Choose one agent with many tools when the task crosses systems but still benefits from one owner.
Examples include:
- a sales assistant that reads CRM data, checks inventory, drafts an email, and schedules a follow-up;
- a data agent that queries a warehouse, runs Python, creates a chart, and writes an explanation;
- a support agent that searches documentation, checks account status, and submits a refund request.
The agent remains the decision-maker. Tools add reach, not additional agency.
3. Use an agent with sub-agents
Choose a manager agent with temporary sub-agents when:
- the main agent can decompose the task at runtime;
- work streams are independent enough to run in parallel;
- each worker benefits from isolated context;
- one lead agent should remain accountable for synthesis;
- the added cost is justified by quality or speed.
Deep research is a strong example: a lead agent can create separate sub-agents for market size, competitors, customer evidence, and regulation, then reconcile their findings.
4. Use a true multi-agent architecture
Choose a persistent multi-agent architecture when the domain contains durable roles and boundaries, such as:
- agents owned by different teams;
- different data access or safety permissions;
- independent services or organizations;
- long-running work with separate queues and state;
- multiple agents that must negotiate, review, or collaborate repeatedly;
- peer-to-peer communication that cannot be reduced to a manager-worker call.
At this level, treat agent messages and shared state as production interfaces. Version their schemas, trace their decisions, enforce permissions, and test failure recovery.
Practical example: creating a market-entry recommendation
Suppose the goal is:
Evaluate whether a software company should launch an AI sales product in Japan and produce an evidence-backed recommendation.
Single-agent architecture
One market-strategy agent receives the goal and uses several tools.
- It plans the research questions.
- It searches for market, competitor, customer, pricing, and regulatory evidence.
- It stores notes in structured task state.
- It uses a calculator or code tool for estimates.
- It drafts the recommendation.
- It checks evidence, contradictions, and missing sections.
- It revises and returns the report.
Why choose it: The research threads are related, the final narrative needs one consistent view, and the simplest architecture may already meet the quality target.
Main risk: A long context can become noisy, and one agent may under-explore some research areas.
Multi-agent architecture
A strategy orchestrator decomposes the goal and delegates:
- Market Agent → demand, segments, and market size;
- Competitor Agent → products, pricing, and positioning;
- Customer Agent → buyer pains and adoption barriers;
- Regulation Agent → data, privacy, and operational constraints.
The four agents research in parallel. Each returns a structured evidence package with claims, sources, uncertainty, and open questions. The orchestrator compares conflicts, requests targeted follow-ups, and synthesizes the final recommendation. A review agent may independently test whether the conclusion is supported.
Why choose it: The research areas are separable, parallel work reduces elapsed time, specialists can use focused context, and independent review may catch unsupported claims.
Main risks: Agents may duplicate research, use incompatible definitions, disagree about assumptions, or produce evidence that the orchestrator cannot reconcile. The system also costs more and requires evaluation of every delegation and synthesis step.
The architectural lesson
Both systems can solve the task. The multi-agent version becomes worthwhile only if its parallelism, context isolation, or specialization produces a measured improvement over the single-agent baseline.
Common multi-agent failure modes
Vague delegation
“Research the market” gives a worker no clear scope, output format, evidence standard, or stopping condition. Delegations should define the objective, boundaries, required output, and success criteria.
Context loss at handoffs
The next agent receives a summary that omits assumptions or evidence. Use structured handoff objects and link claims back to sources and state.
Duplicate work
Several agents explore the same area because ownership is unclear. Keep a shared task ledger with explicit owners and status.
Coordination loops
Agents repeatedly ask each other for clarification, review the same output, or hand control back and forth. Set retry budgets, escalation rules, and termination conditions.
Weak synthesis
Parallel agents produce good local results, but the orchestrator concatenates them instead of resolving contradictions. Synthesis needs its own rubric: compare evidence quality, normalize definitions, expose uncertainty, and make one decision.
Error amplification
One agent's incorrect assumption becomes trusted context for every downstream agent. Preserve provenance, validate important intermediate outputs, and allow downstream agents to challenge inputs.
Permission expansion
A specialist receives tools or data it does not need. Assign the minimum permissions required for each role and place consequential actions behind explicit guardrails or human approval.
Debugging and evaluating multi-agent systems
End-to-end success is necessary, but it is not enough to explain why a multi-agent system succeeds or fails.
Evaluate at three levels:
- Agent level: Did each agent follow its role, use tools correctly, and produce a valid output?
- Coordination level: Were tasks routed well, handoffs complete, dependencies respected, and conflicts resolved?
- System level: Was the final result correct, useful, timely, safe, and worth its cost?
Capture a trace that connects:
User goal → delegation → agent actions → tool results → messages → shared-state changes → synthesis → final result
Then compare the system against a single-agent baseline using the same tasks. Measure outcome quality, cost, latency, failure rate, recovery rate, and maintenance effort. If the multi-agent design does not produce a meaningful advantage, simplify it.
Builder and product implications
- Start with the user outcome and task structure, not an agent count.
- Build a capable single-agent baseline before adding coordination.
- Separate tools from agents using the operation-versus-objective test.
- Use structured contracts for delegation, handoffs, and results.
- Keep shared state explicit; do not rely on chat history as the only coordination layer.
- Design permissions per role.
- Give every agent and orchestrator a stopping condition.
- Evaluate the architecture, not only the final answer.
My Take
Multi-agent design is valuable when it creates a real boundary: specialized capability, isolated context, independent ownership, parallel work, or separate permissions. Without such a boundary, “more agents” often means more prompts, more tokens, and more failure points.
The best default is one capable agent with well-designed tools. Add sub-agents when evidence shows that the task needs parallel exploration or isolated specialists. Build a persistent multi-agent system only when those roles and coordination relationships are part of the problem itself.
Architecture should follow task structure—not fashion.
What to learn next
You now have the full conceptual foundation: agent loops, components, reasoning, tools, memory, planning, reflection, and collaboration patterns. The next step is to combine them in a small working system by following Build Your First AI Agent when Lesson 10 is published.
