Canonical: https://botbento.com/blog/openai-agents-sdk-handoffs-vs-agents-as-tools/ Format: Markdown representation of the public HTML page. [Home](/) / [Blog](/blog/) FIELD NOTES / 5 MIN READ # Handoffs or Agents-as-Tools: Which Pattern Fits Your Bot's Delegation? The OpenAI Agents SDK gives you two built-in ways to let one agent involve another: handoffs, which transfer conversation control, and agents-as-tools, which keep a manager agent in charge. Picking the wrong one either fragments your bot's final answer or buries a specialist's nuance inside a tool result. By BotBento Editorial · Published 2026-10-22 · Updated 2026-10-22 AI-assisted editorial: researched and drafted with AI using the primary sources linked below. Examples are illustrative; they are not measured product results. [Editorial policy](/editorial/). ## In this article - [Two Ways One Agent Can Call Another](#the-two-patterns) - [Which Pattern Fits Your Bot's Task](#how-to-choose) - [Worked Example: A Support Bot With Billing and Refunds](#worked-example) - [What Breaks If You Pick the Wrong Pattern](#failure-paths) - [The Decision](#the-decision)[Read as Markdown ](/text/blog/openai-agents-sdk-handoffs-vs-agents-as-tools/index.md) ## Key takeaways - Handoffs transfer ownership of the conversation to the specialist; agents-as-tools keep a manager agent in control and responsible for the final reply. - Use agents-as-tools when you need one agent to combine multiple specialists' outputs or enforce shared guardrails in one place; use handoffs when the specialist should respond directly and own the rest of the turn. - The two patterns combine: a triage agent can hand off to a specialist that still calls other agents as tools for narrow subtasks. ## Two Ways One Agent Can Call Another An agent in the OpenAI Agents SDK is an LLM equipped with instructions, tools, and handoffs, and given an open-ended task it can autonomously plan how to tackle it, using tools to take actions and handoffs to delegate to sub-agents. That single sentence hides two genuinely different delegation mechanics, and the SDK's own orchestration guide treats them as a real choice rather than two names for the same thing. With a handoff, a triage agent routes the conversation to a specialist, and that specialist becomes the active agent for the rest of the turn. Handoffs are represented as tools to the LLM, so a handoff to an agent named Refund Agent shows up as a callable tool named transfer\_to\_refund\_agent, but invoking it switches which agent is actually driving the conversation. With agents-as-tools, a manager agent keeps control of the conversation and calls specialist agents through Agent.as\_tool(), meaning the manager stays in charge and is responsible for combining whatever the specialist returns into its own reply. The JavaScript SDK describes the same split in plain terms: sometimes you want an Agent to assist another Agent without fully handing off the conversation, and agent.asTool() is how you do that without losing the calling agent's ownership of the exchange. Sources: [Agent orchestration - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/multi_agent/), [Handoffs - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/handoffs/), [Tools](https://openai.github.io/openai-agents-js/guides/tools/). ## Which Pattern Fits Your Bot's Task OpenAI's own guidance reduces the choice to two questions. Use agents as tools when a specialist should help with a bounded subtask but should not take over the user-facing conversation, and use handoffs when routing itself is part of the workflow and you want the chosen specialist to own the remainder of the current turn. The developer-facing orchestration page restates this as a table: handoffs apply when a specialist should take over the conversation for that branch of the work, and agents-as-tools apply when a manager should stay in control and call specialists as bounded capabilities, with the manager keeping ownership of the reply either way. In practice this maps onto two different failure tolerances. If a wrong or incomplete specialist answer needs to be caught, reworded, or merged with another specialist's answer before the user sees it, you want a manager that never lets go of the conversation — agents-as-tools. If the specialist's full voice, formatting, and follow-up questions should reach the user directly, and you don't need anyone double-checking it, a handoff is less code and less latency, since there's no manager round-trip to re-read the specialist's output. The two patterns are not mutually exclusive. A triage agent might hand off to a specialist, and that specialist can still call other agents as tools for narrow subtasks, so a single bot can use a handoff for the big routing decision and agents-as-tools inside each branch for small, bounded lookups. Sources: [Agent orchestration - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/multi_agent/), [Orchestration and handoffs](https://developers.openai.com/api/docs/guides/agents/orchestration). ## Worked Example: A Support Bot With Billing and Refunds Illustrative case: say your bot fields customer messages and needs to involve a billing specialist and a refund specialist. The SDK's own pattern for this is a manager design: a customer-facing agent handles all user interaction and invokes specialized sub-agents exposed as tools, so the booking and refund agents never see the raw conversation and never reply to the user directly. The customer-facing agent stays responsible for tone, for deciding whether to show the refund agent's numbers at all, and for merging a billing answer and a refund answer into one message if the user asked about both. Now change the scenario slightly: the user clearly wants to open a dispute, and once that's true, the refund agent should just take over — asking clarifying questions, requesting an order number, and closing the loop without a manager agent translating every message. That's the handoff shape: a triage agent routes the conversation to a specialist, and that specialist becomes the active agent for the rest of the turn. The same bot can use agents-as-tools for its default multi-topic handling and a handoff for the single case where one specialist should own the rest of the exchange. The mechanical difference matters for what the specialist sees, too. A handoff's receiving agent still sees the conversation history unless you change it with an input\_filter, so the refund agent you hand off to inherits everything said so far. An agent called as a tool gets whatever input the manager decides to pass it — by default a single input parameter — and returns either its last message or a value from a custom output extractor, which the manager then has to fold into its own reply. Sources: [Orchestration and handoffs](https://developers.openai.com/api/docs/guides/agents/orchestration), [Agents - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/agents/), [Handoffs - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/handoffs/), [Tools](https://openai.github.io/openai-agents-js/guides/tools/). ## What Breaks If You Pick the Wrong Pattern Using a handoff where you needed a manager loses your last checkpoint. Once a specialist agent is active after a handoff, nothing in the SDK makes the original agent review what it says next; the specialist owns the turn until it hands off again or the conversation ends. If your bot needs to guarantee that every refund amount gets validated against a policy tool before the user sees it, routing through a handoff means that validation has to live inside the refund agent itself, not in a manager you can audit separately. Using agents-as-tools where you needed a handoff creates a narration tax. Every specialist response gets re-read and re-expressed by the manager agent, which adds a model call, adds latency, and risks the manager paraphrasing away detail the specialist meant to state precisely — a worked calculation, a specific policy citation, a multi-step explanation. If the specialist's own voice and formatting matter to the user, forcing it through a manager's summary is the wrong trade. There's also an authorization trap specific to handoffs with structured input: the SDK calls your on\_handoff check before the model returns handoff arguments, so you cannot authorize values that live inside an argument-bearing handoff at that point. If your bot's handoff decision depends on a field the model fills in — say, which refund tier applies — gate that check inside on\_handoff itself, before any side effects run, rather than assuming the handoff mechanism validated it for you. Sources: [Handoffs - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/handoffs/). ## The Decision Default to agents-as-tools whenever your bot needs to own the final answer, merge more than one specialist's output, or apply a guardrail check before anything reaches the user — this costs one extra model call per specialist but keeps a single reviewable point of control. Switch to a handoff only when a specific branch of the conversation should be owned end-to-end by one specialist, and you're comfortable with that specialist's own instructions being the only check in place once control transfers. Most small-team bots will use agents-as-tools for routine multi-specialist questions and reserve handoffs for the one or two branches — a dispute, a cancellation, an escalation — where a single agent should visibly take over and run the rest of the conversation itself. ## Primary sources Sources checked 2026-10-22. Standards and product documentation can change; follow the linked version when implementing. - [Agent orchestration - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/multi_agent/) — OpenAI - [Agents - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/agents/) — OpenAI - [Orchestration and handoffs](https://developers.openai.com/api/docs/guides/agents/orchestration) — OpenAI - [Tools](https://openai.github.io/openai-agents-js/guides/tools/) — OpenAI - [Handoffs - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/handoffs/) — OpenAI BotBento is in development. [Suggest a correction](/contact/).