Yes. Since you already have the article, I would not repeat it. However, because you asked to continue the series, I suggest we use the next article after planning/reasoning as Multi-Agent Systems. The official Agents SDK documentation currently describes two main orchestration patterns: agents as tools and handoffs. (OpenAI GitHub)
Here is the next page in the same style.
Building a Multi-Agent System
So far, we have built our AI Agent step by step.
Our Agent can now work with:
- An LLM
- Tools
- Memory
- RAG
- MCP
- Planning and reasoning
But there is another interesting possibility.
What if we use more than one AI Agent?
Instead of creating one Agent that tries to do everything, we can create several specialized Agents and allow them to work together.
This is called a Multi-Agent System.
What Is a Multi-Agent System?
A Multi-Agent System is an application where multiple AI Agents work together to solve a problem.
Each Agent can have a specific role.
For example:
Multi-Agent System
|
+----------------+----------------+
| | |
v v v
Research Agent Coding Agent Review Agent
Each Agent specializes in a particular type of task.
For example:
Research Agent
Finds and analyzes information.
Coding Agent
Works with programming and software development.
Review Agent
Checks the work produced by other Agents.
Why Use Multiple Agents?
A single Agent can be given many tools and instructions.
However, as the application becomes larger, the Agent’s responsibilities can become difficult to manage.
For example:
One Large Agent
|
+-- Research
+-- Programming
+-- Testing
+-- Documentation
+-- Customer Support
+-- Database
+-- Security
+-- Reporting
This can become complicated.
Instead, we can divide the responsibilities:
Manager Agent
|
+-----------------+-----------------+
| | |
v v v
Research Agent Coding Agent Review Agent
Each Agent has a smaller and clearer responsibility.
Specialized Agents
A good Multi-Agent System often uses specialized Agents.
For example:
Research Agent
|
+-- Finds information
Coding Agent
|
+-- Writes code
Testing Agent
|
+-- Tests the code
Review Agent
|
+-- Reviews the result
This is similar to a software development team.
One person researches the problem, another writes the solution, another tests it, and another reviews the result.
The Manager Agent
One common architecture uses a Manager Agent.
The Manager Agent communicates with the user and coordinates the other Agents.
User
|
v
Manager Agent
|
+-------------+-------------+
| | |
v v v
Research Coding Review
Agent Agent Agent
| | |
+-------------+-------------+
|
v
Manager Agent
|
v
User
The Manager remains responsible for the final response.
The OpenAI Agents SDK calls this pattern agents as tools: the manager can invoke specialist Agents as tools while keeping control of the conversation. (OpenAI GitHub)
Example: Creating a Technical Report
Imagine the user asks:
Create a technical report about AI Agents.
The Manager Agent could divide the work.
User
|
v
Manager Agent
|
+----> Research Agent
| |
| v
| Research
|
+----> Writing Agent
| |
| v
| Draft Report
|
+----> Review Agent
|
v
Check Report
The Manager then combines the results and produces the final report.
Manager Agent as an Orchestrator
The Manager does not necessarily perform every task itself.
Instead, it decides which specialist is appropriate.
For example:
User:
Research Kubernetes security and
write a technical report.
Manager:
|
+--> Research Agent
|
+--> Security Agent
|
+--> Writing Agent
|
+--> Review Agent
The Manager orchestrates the workflow.
Agents as Tools
In the OpenAI Agents SDK, one Agent can be exposed to another Agent as a tool using Agent.as_tool(). This allows a manager Agent to call a specialist Agent for a bounded task while retaining control of the overall conversation. (OpenAI GitHub)
A simplified Python example looks like this:
from agents import Agent
research_agent = Agent(
name="Research Agent",
instructions="Research the requested topic and return useful findings."
)
manager_agent = Agent(
name="Manager Agent",
instructions="Coordinate the task and use the research agent when necessary.",
tools=[
research_agent.as_tool(
tool_name="research",
tool_description="Research a topic and return useful findings."
)
]
)
The important idea is:
Manager Agent
|
v
Research Agent
The Research Agent is being used as a capability of the Manager.
Handoffs
Another important Multi-Agent pattern is called a handoff.
With a handoff, one Agent transfers responsibility for the conversation to another Agent.
For example:
Triage Agent
|
+--------------+--------------+
| | |
v v v
Billing Technical Sales
Agent Agent Agent
The Triage Agent determines which specialist should handle the request.
For example:
I have a problem with my payment.
The Triage Agent can hand the conversation to the Billing Agent.
The Billing Agent then becomes responsible for the conversation.
The OpenAI Agents SDK describes this as a different pattern from agents-as-tools: with a handoff, the specialist takes over the conversation rather than simply returning a result to a manager. (OpenAI GitHub)
Manager vs Handoff
These two approaches are important to understand.
Agents as tools
Manager
|
+----> Specialist
|
<---- Result
|
v
Manager gives final answer
The Manager remains in control.
Handoff
Triage Agent
|
+----> Specialist Agent
|
v
Specialist
talks to user
The specialist takes over.
When Should We Use a Manager?
A Manager is useful when one Agent should remain responsible for the final result.
For example:
Manager Agent
|
+-- Research Agent
+-- Calculation Agent
+-- Writing Agent
The Manager collects the results and creates one final response.
This is useful for:
- Research
- Report generation
- Data analysis
- Complex workflows
- Software development
When Should We Use a Handoff?
A handoff is useful when different types of requests should be handled by different specialists.
For example:
Customer Support
|
v
Triage Agent
|
+---- Billing
|
+---- Technical Support
|
+---- Sales
The specialist then communicates directly with the user.
Multi-Agent Example: Customer Support
Let’s build a simple conceptual customer-support system.
Customer
|
v
Triage Agent
|
+--------------+--------------+
| | |
v v v
Billing Agent Support Agent Sales Agent
The user asks:
My invoice is incorrect.
The Triage Agent identifies this as a billing question.
Customer
|
v
Triage Agent
|
v
Billing Agent
Another customer asks:
How do I install the application?
The request can be routed to:
Triage Agent
|
v
Technical Support Agent
Multi-Agent Example: Software Development
A software-development system could use:
Development Manager
|
+-------------------+-------------------+
| | |
v v v
Requirements Coding Agent Testing Agent
Agent | |
| | |
+--------------------+-------------------+
|
v
Review Agent
The user might say:
Add a customer search feature to the application.
The workflow could be:
1. Requirements Agent
|
v
2. Coding Agent
|
v
3. Testing Agent
|
v
4. Review Agent
|
v
5. Final result
Multi-Agent Systems and Planning
Planning becomes particularly useful when several Agents are involved.
The Manager can create a workflow:
Goal
|
v
Create Plan
|
+---- Research
|
+---- Development
|
+---- Testing
|
+---- Review
|
v
Final Result
The Manager therefore acts as an orchestrator.
Multi-Agent Systems and Tools
Each Agent can also have its own tools.
For example:
Research Agent
|
+-- Web Search
+-- RAG
Coding Agent
|
+-- File System
+-- Code Execution
Testing Agent
|
+-- Test Runner
Database Agent
|
+-- Database Tool
The overall system becomes:
Manager Agent
|
+--------------------+--------------------+
| | |
v v v
Research Agent Coding Agent Testing Agent
| | |
RAG File Tools Test Tools
| | |
+--------------------+--------------------+
|
v
Final Result
Multi-Agent Systems and Memory
Agents can also use memory.
For example, a development Agent might remember:
Project:
Customer Management System
Language:
C#
Framework:
ASP.NET Core
Database:
SQL Server
The Testing Agent might have different information:
Testing Framework:
xUnit
Test Type:
Unit Tests
The Manager can coordinate the Agents while each Agent uses the information relevant to its task.
Multi-Agent Systems and RAG
RAG can also be specialized.
For example:
Research Agent
|
v
Technical Documentation
Security Agent
|
v
Security Documentation
Legal Agent
|
v
Legal Documentation
Each Agent can retrieve information from the appropriate knowledge source.
Multi-Agent Systems and MCP
MCP can provide external capabilities to individual Agents.
For example:
Coding Agent
|
v
MCP
|
+-- Git
+-- Files
+-- Development Tools
Another Agent could use:
Database Agent
|
v
MCP
|
+-- Database
+-- Reporting System
This allows different Agents to have different capabilities.
A Complete Multi-Agent Architecture
We can now combine everything we have learned:
User
|
v
Manager Agent
|
+----------------+----------------+
| | |
v v v
Research Agent Coding Agent Review Agent
| | |
v v v
RAG Tools Tools
| | |
+----------------+----------------+
|
MCP
|
+------------+------------+
| | |
v v v
Database Files Services
|
v
LLM
|
v
Final Result
This is a much more realistic architecture for complex AI applications.
One Agent or Multiple Agents?
A common question is:
Should I build one Agent or several Agents?
There is no universal answer.
A single Agent may be better when:
- The task is relatively simple.
- The Agent has a small number of tools.
- The workflow is straightforward.
- There is no clear need for specialization.
Multiple Agents may be useful when:
- Different tasks require different expertise.
- The workflow contains clearly separated responsibilities.
- Different Agents need different tools.
- Different Agents need different instructions.
- The application has several distinct domains.
The goal is not to create as many Agents as possible.
The goal is to create an architecture that is clear, maintainable, and reliable.
Too Many Agents Can Also Be a Problem
More Agents do not automatically mean a better system.
For example:
Manager
|
+-- Agent 1
+-- Agent 2
+-- Agent 3
+-- Agent 4
+-- Agent 5
+-- Agent 6
+-- Agent 7
+-- Agent 8
This can create unnecessary complexity.
More Agents can mean:
- More API calls
- More latency
- More cost
- More complicated debugging
- More complicated communication
- More opportunities for errors
Therefore, use multiple Agents when there is a clear reason to do so.
Multi-Agent Systems and Human Approval
Some workflows should include a human.
For example:
Manager Agent
|
v
Coding Agent
|
v
Testing Agent
|
v
Deployment Plan
|
v
Human Approval
|
+--+--+
| |
Reject Approve
| |
Stop v
Deployment
This can be important when an Agent is allowed to perform actions that could affect production systems.
Testing a Multi-Agent System
Testing becomes particularly important when multiple Agents are involved.
We should test:
- Did the Manager select the correct Agent?
- Did the specialist perform the correct task?
- Was the correct tool selected?
- Was the correct information retrieved?
- Was the final result correct?
- Did the system recover from an error?
The OpenAI Agents SDK also provides tracing and evaluation-related capabilities that can help developers inspect and improve Agent workflows. (OpenAI GitHub)
Cost and Performance
A Multi-Agent System can require more model calls than a simple Agent.
For example:
One Agent
|
+---- 1 model call
could become:
Manager
|
+---- Research Agent
|
+---- Coding Agent
|
+---- Review Agent
Each Agent may require additional model calls.
Therefore, developers should consider:
- Number of Agents
- Number of model calls
- Token usage
- Response time
- Tool calls
- Parallel execution
The Agents SDK provides usage information that can be used to monitor requests and token consumption. (OpenAI GitHub)
Parallel Agents
Not every task needs to be performed sequentially.
Suppose we need to research three independent topics:
Topic A
Topic B
Topic C
They could potentially be researched at the same time:
Manager
|
+---------+---------+
| | |
v v v
Agent A Agent B Agent C
| | |
+---------+---------+
|
v
Combine Results
Parallel execution can reduce waiting time when the tasks do not depend on each other. The Agents SDK documentation lists parallel agent execution as one of the common orchestration patterns. (OpenAI GitHub)
Sequential Agents
Other tasks depend on previous results.
For example:
Research
|
v
Writing
|
v
Review
|
v
Final Report
The Writing Agent needs the research before it can write.
The Review Agent needs the draft before it can review it.
This is a sequential workflow.
Parallel vs Sequential
A simple comparison:
Parallel
Manager
/ | \
A B C
\ | /
Result
Good when tasks are independent.
Sequential
A → B → C → D
Good when each step depends on the previous step.
What We Have Learned
In this article, we introduced Multi-Agent Systems.
We learned that multiple specialized Agents can work together to solve complex problems.
We explored:
- Multi-Agent architecture
- Specialized Agents
- Manager Agents
- Agents as tools
- Handoffs
- Planning
- Tools
- Memory
- RAG
- MCP
- Human approval
- Sequential workflows
- Parallel workflows
- Cost and performance
The basic concept is:
User
|
v
Manager Agent
|
+-------------+-------------+
| | |
v v v
Research Coding Review
Agent Agent Agent
| | |
+-------------+-------------+
|
v
Final Result
Conclusion
A Multi-Agent System allows us to divide a complex problem into specialized responsibilities.
Instead of building one Agent that tries to perform every task, we can create several Agents, each designed for a particular purpose.
A Manager Agent can coordinate these specialists, or a Triage Agent can hand the conversation to the appropriate specialist.
The OpenAI Agents SDK currently provides both agents-as-tools and handoffs as core patterns for this type of orchestration. (OpenAI GitHub)
Our AI Agent architecture has now grown considerably:
AI Agent System
|
+---------------------+---------------------+
| | |
v v v
Planning Memory Tools
| | |
v v v
RAG MCP External Systems
|
v
Knowledge Base
And when the application becomes more complex, these capabilities can be distributed across several specialized Agents.
In the next article, we will explore Guardrails and Security for AI Agents and learn how to control what an Agent can see, what it can do, and how to prevent unsafe or unintended actions.
→ Adding Guardrails and Security to AI Agents
← Back to AI Agents – Step-by-Step
Suggested practical example
For the practical part of this series, I recommend that we next build a small Multi-Agent system in Python rather than only explaining it.
For example:
Manager Agent
|
+-----------+-----------+
| |
v v
Research Agent Writer Agent
| |
+-----------+-----------+
|
v
Final Article
This would be a very good demonstration for your readers because they will actually see how one Agent can use another Agent. The current OpenAI Agents SDK supports this directly through Agent.as_tool(). (OpenAI GitHub)