Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchiTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A router-plus-specialist workflow has one entry agent that reads each request and sends it to a narrowly scoped specialist. The design decision that matters most is not the code but ownership: should the chosen specialist write the reply the user sees, or should a manager call the specialist for a bounded piece of work and keep responsibility for the final answer? The OpenAI Agents SDK for Python supports both models. It calls them handoffs and agents-as-tools.
What the architecture contains
The pattern has three parts. The first is a router, sometimes called a triage agent, whose only job is to read the request and choose a destination. The second is a set of specialists, each with its own instructions and a clearly bounded scope, such as billing questions, technical troubleshooting, or order status. The third is the runner, which executes the agents and continues the loop through tool calls and handoffs until it reaches a stopping point.
Keep the first version small: one router and two or three specialists. Every additional specialist adds another destination the model must choose between, so overlap between scopes is the most common source of misrouting.
Decide who owns the answer before writing code
The OpenAI documentation frames the choice in one sentence: “Use handoffs when routing itself is part of the workflow and you want the chosen specialist to own the remainder of the current turn.” That wording comes from the OpenAI Agents SDK agent orchestration guide. The guide does not attribute it to a named author.
#1 Best Overall
| Decision axis | Handoffs | Agents-as-tools |
|---|---|---|
| Who owns the next response? | The selected specialist takes over that branch. | The manager stays in control. |
| Best fit | Routing is part of the workflow and the specialist should answer the user directly. | Specialist work is bounded, and the manager should combine outputs or write the final response. |
| Specialist context | The receiving agent gets conversation history by default. Input filters and history configuration can narrow it. | The specialist runs as a tool call for one task, and the manager keeps the conversation. |
As a rule of thumb, use handoffs for a support desk where the billing specialist should continue the conversation. Use agents-as-tools when a planner needs a research helper’s findings before it writes one answer. Sources: agent orchestration and the Python handoffs guide.
Install the SDK and run one agent first
The official Python quickstart recommends getting one agent working end to end before adding routing or other capabilities. The steps are:
- Install the package with
pip install openai-agents. - Import the two core classes with
from agents import Agent, Runner. - Create one
Agentwith a name and instructions. - Call
Runner.run(...)from inside an async function andawaitthe result. - Read the answer from
result.final_output.
The quickstart’s routing example is written in JavaScript, not Python. The Python routing pattern is described in the orchestration guide, so the steps below stay at the level of the documented concepts rather than a copied snippet. Full quickstart details are in the OpenAI Agents SDK Python quickstart.
Recommended Free Tools
Define the router and the specialists
The router (triage agent)
The router’s instructions should say what it decides and nothing more. It should not answer domain questions itself. A workable instruction set states the available destinations, when each applies, and what to do when a request fits none of them, such as asking a clarifying question. The quickstart shows a triage agent with separate handoff destinations, which is the shape to copy.
Specialist agents
Give each specialist distinct instructions and a scope it can actually handle. Two checks help:
- Can you describe the specialist’s scope in one sentence without the word “and” joining unrelated tasks?
- Would two specialists ever plausibly claim the same request? If so, merge them or split the scope more sharply.
Specialist descriptions
A specialist’s handoff description can guide the model when it chooses a destination, so write it as a routing rule rather than a marketing line. For example, “Handles refund and invoice disputes for paid subscriptions” is more useful to the router than “Billing expert.”
Register each handoff destination
Register one handoff per specialist. The SDK exposes those registered destinations to the model as choices. The Python handoffs guide documents optional customization on each handoff: a description, a callback, an input schema, and an input filter. Use the description first. Add the others only when a specific requirement appears, such as a specialist that needs structured input or a filter that removes older turns.
Free tools Windows power users keep installed
One-click scans. No signup required.
Limit the context each specialist receives
Handoffs carry conversation history by default. That is convenient, but it also sends more context than a narrow specialist may need. Keep the context as small as your application allows:
- Use an input filter when the specialist only needs the latest user message and a short summary.
- Use history configuration to limit how much prior conversation is passed on.
- For agents-as-tools, pass only the task text the manager writes for that call, because the specialist runs as a bounded tool rather than taking over the conversation.
Handle the second and later turns
The runner’s loop covers one run: it continues through tool calls and handoffs until it stops. A conversation spans several runs, and the SDK does not make those runs share memory automatically. The runtime documentation distinguishes these two boundaries. OpenAI’s running agents guide describes the state-continuation options. Choose one strategy and apply it consistently:
- Application-held history. Your code stores the message list and passes it to each new run.
- A session. The SDK manages conversation continuity for you.
- A conversation ID. You reference a server-side conversation across turns.
- A previous response ID. Each new run continues from the prior response.
Mixing strategies is the usual cause of a specialist “forgetting” earlier turns. Pick one and test a two-turn exchange before adding more specialists.
Add tracing and guardrails when the workflow needs them
The OpenAI Agents SDK overview lists guardrails, sessions, and tracing as built-in capabilities. Tracing helps you see which agent ran and why a handoff happened. Guardrails are checks on inputs or outputs. Adding them is worthwhile once the basic routing works, but neither one guarantees that routing decisions are correct. Confirm routing with your own test requests.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsQuick Recap
What the official sources do not establish
- The official pages do not publish performance, latency, cost, or reliability figures for either orchestration pattern. Choose by ownership of the answer, not by a claimed speed or accuracy advantage.
- They do not compare the SDK with other agent frameworks. The comparison in this article is between the two patterns inside the same SDK.
- The quoted sentence in the orchestration guide is documentation wording, not a statement from a named person.
“
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
