Module 1 · Lesson 8
Single-Agent vs Multi-Agent Systems
A multi-agent system is not automatically more capable. Start with one agent, then split responsibilities only when specialization, context isolation or ownership boundaries justify the coordination cost.
What is a single-agent system?
A single agent owns the user-facing task and has access to the tools it needs. It may perform many steps, but one active agent remains responsible for deciding what happens next.
User → General Agent → tools → final answerThis is often the simplest architecture to build, trace and evaluate.
What is a multi-agent system?
A multi-agent system separates capabilities across specialized agents. One agent may route, delegate or coordinate work performed by others.
→ Research Agent
User → Manager → Data Agent
→ Writing Agent
OpenAI's current Agents SDK supports two core orchestration styles: agents as tools, where a manager remains in control, and handoffs, where a specialist becomes the active agent for the rest of the turn.
Manager vs handoff
Manager / agents-as-tools
A manager calls specialists for bounded subtasks, receives their results and owns the final response. This works well when one agent must combine outputs or enforce a unified policy.
Handoffs
A triage agent transfers control to a specialist. OpenAI documents handoffs as useful when different agents specialize in distinct areas such as refunds, FAQs or order status and the specialist should directly own the remainder of the turn.
Why split into multiple agents?
Specialized instructions
A narrow prompt can be easier to optimize than one enormous system prompt covering unrelated tasks.
Tool isolation
A billing agent does not need deployment tools. Reducing each agent's tool surface can make selection clearer and permissions easier to reason about.
Context isolation
Specialists can receive only the context relevant to their job instead of carrying a massive shared conversation.
Different model or cost profiles
Some subtasks may need a stronger model while others can use a cheaper or faster one. Architecture can make those choices explicit.
The coordination tax
Every extra agent introduces handoff or delegation decisions, more prompts, more model calls, more traces and more ways to lose context. Multi-agent systems therefore require a clear reason.
| Concern | Single agent | Multi-agent |
|---|---|---|
| Implementation | Simpler | More orchestration |
| Context | Shared and straightforward | Must decide what to pass |
| Tool surface | Can grow large | Can isolate tools by specialist |
| Tracing | Easier | More complex execution graph |
| Latency | Usually lower | May add extra model turns |
| Specialization | One prompt handles everything | Strong separation of roles |
When to stay with one agent
- The tool set is small and distinct.
- One set of instructions handles the domain well.
- The agent needs the same context across subtasks.
- You have not yet measured a real failure caused by prompt or tool overload.
When multi-agent architecture becomes useful
- Different domains need sharply different instructions.
- Permissions or tool access must be separated.
- A manager must combine several specialist results.
- Routing to a specialist is itself a core product behavior.
- Context size becomes difficult to control in one agent.
Parallel specialists
Some subtasks can run independently. A manager may ask one agent to inspect technical risk while another estimates cost, then combine the results. Parallelization can reduce wall-clock latency when dependencies allow it, but it still increases total work and cost.