What is the difference between a single-agent and multi-agent system?

A single-agent system gives one model-driven agent the instructions, context and tools needed to complete a task. The same agent plans, calls tools, checks results and produces the final output. It may use many deterministic tools without becoming a multi-agent system.

A multi-agent system contains two or more model-driven agents with separate roles. They may be coordinated by a manager, transfer control through handoffs or run independent branches in parallel. OpenAI’s Agents SDK documents manager-as-tools and handoffs as two common patterns. These are architecture choices, not maturity levels.

Text equivalent: the single-agent pattern has one agent between the request and its tools. In the manager pattern, one agent owns the result while specialist agents perform bounded subtasks. In the handoff pattern, a triage agent routes the request and the chosen specialist takes control.

How do the architectures compare?

When is one agent enough?

Use one agent when one role can understand the goal, access the necessary context and select from a manageable tool set. Lead intake, appointment preparation, support drafting and internal reporting often begin this way. A tool that calculates, searches or writes a record does not need its own agent if it follows deterministic logic.

A single agent is easier to trace because one instruction set owns the decision loop. It also avoids repeated context packaging and conflicting specialist outputs. Anthropic’s architecture guidance recommends starting with the simplest system and adding complexity only when it produces a measured improvement.

When does a multi-agent system help?

Separate agents can help when a task divides into independent areas that require different instructions or tool access. A research manager might ask parallel agents to explore distinct markets, then compare their evidence. A customer-service router might hand a billing case to a billing specialist with limited account tools.

Parallel research is a strong example because branches can explore different directions without waiting for each other. Anthropic reported that its own multi-agent research system outperformed its single-agent baseline by 90.2% on an internal research evaluation. That result belongs to that system and test set; it does not establish a general advantage for multi-agent architecture.

Good reasons to split

• independent work can run in parallel;
• specialists need different data or tool permissions;
• each specialty has a distinct evaluation set;
• one prompt has become difficult to understand and maintain;
• a routing boundary mirrors a real operational boundary;
• one manager must combine several evidence-producing subtasks.

Should you use a manager or handoffs?

Use a manager when one component must retain the user context, apply shared policy and produce the final answer. Specialists behave like tools: they receive a bounded task and return a result. This is useful for reports, proposals and investigations where several contributions become one deliverable.

Use handoffs when routing is the workflow. The specialist takes over, such as billing, booking or technical support. OpenAI’s handoff documentation allows typed routing metadata and context filters. The design still needs an application-level permission check before any side effect; a model-generated handoff reason is not authorisation.

How do you choose in seven steps?

1. Define one measurable result. State what finishes the run and who owns the business outcome.
2. Build a single-agent baseline. Give one agent only the context and tools needed for the task.
3. Record the real failure. Identify whether failures come from context overload, tool confusion, missing expertise, latency or weak source data.
4. Test a simpler fix. Improve tool descriptions, structured outputs, retrieval and deterministic routing before adding another agent.
5. Name the boundary. Give a new agent separate instructions, tools, permissions and evaluation only when those boundaries matter.
6. Choose manager, handoff or code orchestration. Keep one owner for synthesis, transfer control for service routing, or use code when the sequence must be predictable.
7. Compare against the baseline. Measure task success, routing, evidence, latency, cost and recovery on the same test set.

What can fail in a multi-agent system?

How should you test the decision?

Test each agent in isolation, then every routing or handoff boundary, then the whole system. Use the same normal, ambiguous and adversarial cases for the single-agent and multi-agent versions. Record every agent call, tool call, transfer, source and approval result so a reviewer can reconstruct the run.

Criteria for success

• The chosen architecture completes the defined task more reliably than the baseline.
• Every route is correct or fails into a safe, visible queue.
• Transferred context is sufficient but contains no unnecessary sensitive data.
• Specialist outputs use a defined schema and cite their evidence.
• Loops stop at the configured limit.
• Consequential actions remain behind the same approval gate after every handoff.
• The improvement justifies additional latency, cost and operational work.