You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
docs: Add more clarity on multi-agent design patterns (#1650)
This pull request updates the "Agents" documentation page to mention
both manger and handoffs design patterns. I've got a feedback from a
customer that the Agents SDK documentation does not mention the "agents
as tools" design pattern when mentioning handoffs, so he thought this
SDK supports only handoffs. This is a valid feedback, so we can consider
improving the documentation to give more clarity.
Copy file name to clipboardExpand all lines: docs/agents.md
+47-7Lines changed: 47 additions & 7 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -71,9 +71,47 @@ agent = Agent(
71
71
72
72
When you pass an `output_type`, that tells the model to use [structured outputs](https://platform.openai.com/docs/guides/structured-outputs) instead of regular plain text responses.
73
73
74
-
## Handoffs
74
+
## Multi-agent system design patterns
75
75
76
-
Handoffs are sub-agents that the agent can delegate to. You provide a list of handoffs, and the agent can choose to delegate to them if relevant. This is a powerful pattern that allows orchestrating modular, specialized agents that excel at a single task. Read more in the [handoffs](handoffs.md) documentation.
76
+
There are many ways to design multi‑agent systems, but we commonly see two broadly applicable patterns:
77
+
78
+
1. Manager (agents as tools): A central manager/orchestrator invokes specialized sub‑agents as tools and retains control of the conversation.
79
+
2. Handoffs: Peer agents hand off control to a specialized agent that takes over the conversation. This is decentralized.
80
+
81
+
See [our practical guide to building agents](https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf) for more details.
82
+
83
+
### Manager (agents as tools)
84
+
85
+
The `customer_facing_agent` handles all user interaction and invokes specialized sub‑agents exposed as tools. Read more in the [tools](tools.md#agents-as-tools) documentation.
86
+
87
+
```python
88
+
from agents import Agent
89
+
90
+
booking_agent = Agent(...)
91
+
refund_agent = Agent(...)
92
+
93
+
customer_facing_agent = Agent(
94
+
name="Customer-facing agent",
95
+
instructions=(
96
+
"Handle all direct user communication. "
97
+
"Call the relevant tools when specialized expertise is needed."
98
+
),
99
+
tools=[
100
+
booking_agent.as_tool(
101
+
tool_name="booking_expert",
102
+
tool_description="Handles booking questions and requests.",
103
+
),
104
+
refund_agent.as_tool(
105
+
tool_name="refund_expert",
106
+
tool_description="Handles refund questions and requests.",
107
+
)
108
+
],
109
+
)
110
+
```
111
+
112
+
### Handoffs
113
+
114
+
Handoffs are sub‑agents the agent can delegate to. When a handoff occurs, the delegated agent receives the conversation history and takes over the conversation. This pattern enables modular, specialized agents that excel at a single task. Read more in the [handoffs](handoffs.md) documentation.
77
115
78
116
```python
79
117
from agents import Agent
@@ -84,9 +122,9 @@ refund_agent = Agent(...)
84
122
triage_agent = Agent(
85
123
name="Triage agent",
86
124
instructions=(
87
-
"Help the user with their questions."
88
-
"If they ask about booking, handoff to the booking agent."
89
-
"If they ask about refunds, handoff to the refund agent."
125
+
"Help the user with their questions."
126
+
"If they ask about booking, hand off to the booking agent."
127
+
"If they ask about refunds, hand off to the refund agent."
-`ToolsToFinalOutputFunction`: A custom function that processes tool results and decides whether to stop or continue with the LLM.
207
248
208
249
```python
@@ -242,4 +283,3 @@ agent = Agent(
242
283
!!! note
243
284
244
285
To prevent infinite loops, the framework automatically resets `tool_choice` to "auto" after a tool call. This behavior is configurable via [`agent.reset_tool_choice`][agents.agent.Agent.reset_tool_choice]. The infinite loop is because tool results are sent to the LLM, which then generates another tool call because of `tool_choice`, ad infinitum.
0 commit comments