Canonical: https://botbento.com/blog/supervisor-agent-vs-single-agent-tools/ Format: Markdown representation of the public HTML page. [Home](/) / [Blog](/blog/) FIELD NOTES / 3 MIN READ # When Should a Bot Use a Supervisor Agent Instead of One Agent With Tools? Multi-agent orchestration adds routing and context decisions. Start with one agent and its tools; add specialists when different instructions, tools or policies materially improve the work, then choose whether a manager keeps control or hands off the turn. By BotBento Editorial · Published 2026-09-26 · Updated 2026-09-26 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 - [The default is one agent with tools, not a supervisor](#the-default-is-one-agent) - [If you do split, there are two distinct patterns](#two-ways-to-split) - [A worked example: a support bot that also books refunds](#worked-example) - [Splitting adds failure modes you now own](#new-failure-modes)[Read as Markdown ](/text/blog/supervisor-agent-vs-single-agent-tools/index.md) ## Key takeaways - Start with one agent where possible; add specialists when they improve capability or policy isolation, prompt clarity, or the ability to inspect a run. - Two common orchestration patterns are agents-as-tools, where a manager keeps the user-facing turn, and handoffs, where a specialist becomes active for the rest of that turn. - Splitting introduces new failure modes you must design for yourself: how much context to pass at a handoff, what happens when a sub-agent fails, and how to test the added routing paths. ## The default is one agent with tools, not a supervisor Bot builders often reach for a supervisor-and-workers design before they need one. The official guidance from OpenAI's Agents SDK documentation is direct on this point: start with one agent whenever you can, and only add orchestration once a single agent with a good prompt and the right tools stops being sufficient. The reason is that a multi-agent design adds coordination decisions: how work is split, who owns the final answer, what context moves between agents, and what happens when a specialist fails. A single agent still needs clear tool and error handling, but has fewer routing paths. If one set of instructions and tools works well in evaluation, keep it until a specific split improves the result. Sources: [Orchestration and handoffs | OpenAI API](https://developers.openai.com/api/docs/guides/agents/orchestration). ## If you do split, there are two distinct patterns When a split has a clear benefit, the OpenAI Agents SDK documentation describes two patterns that come up most often. One is agents-as-tools, where a specialist helps with a bounded subtask while the manager keeps the user-facing turn. The other is handoffs, where the chosen specialist becomes the active agent for the rest of the current turn. These answer different ownership questions. In the agents-as-tools pattern, a central manager invokes specialists and combines their results into the final answer. In the handoff pattern, the first agent transfers control and the specialist responds directly. That does not mean the specialist owns every future conversation; the application still decides how later turns resume and route. Anthropic's own engineering guidance uses similar language for a comparable pattern it calls orchestrator-workers, where a central LLM dynamically breaks down tasks, delegates them to worker LLMs, and synthesizes their results. Anthropic recommends this specifically for complex tasks where you can't predict the subtasks in advance -- for example, coding tasks where the number of files that need changing depends on the input. That's a different signal than the routing signal behind handoffs: orchestrator-workers is about not knowing the shape of the task ahead of time, while handoffs are about which specialist should own the conversation once the category of the request is known. Sources: [Orchestration and handoffs | OpenAI API](https://developers.openai.com/api/docs/guides/agents/orchestration), [Agent orchestration - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/multi_agent/), [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents). ## A worked example: a support bot that also books refunds Illustrative example. Suppose a small team is building a support bot. Most requests are simple questions answered from a knowledge base -- one agent, one retrieval tool, no split needed. Now two request types show up: billing disputes that need a policy lookup, and refund requests that use a different tool and require an approval step. The team can keep one agent with both tool sets if evaluation shows it routes correctly and respects approval policy. If the instructions or permissions interfere, it can use a triage agent that hands off to a billing or refund specialist. The specialist split should be justified by observed routing or policy outcomes, not the mere presence of two categories. If the team picks handoffs, it must decide how much conversation history the refund specialist receives. Pass irrelevant history and the specialist may lose focus; pass too little and the customer may need to repeat an order number. The SDK provides a mechanism for filtering handoff history, but the team must choose and test a policy for its own workflow. Sources: [Orchestration and handoffs | OpenAI API](https://developers.openai.com/api/docs/guides/agents/orchestration), [Agent orchestration - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/multi_agent/). ## Splitting adds failure modes you now own Multi-agent orchestration adds work. First, context passing: how much history moves at a handoff, and whether filtering is appropriate, requires a deliberate decision. Second, error handling: if a specialist fails mid-task, the application must decide whether to show an error, retry or return control to triage. Third, testing: each supported route and context boundary needs a representative evaluation. More agents can mean more combinations to check, but the number depends on the actual routing graph; there is no universal exponential rule. None of these problems disappear by choosing agents-as-tools instead of handoffs -- they just shift shape. In the agents-as-tools pattern, the manager retains the final say, so a failing sub-agent is easier to catch before it reaches the user, but the manager now needs its own logic for deciding when a sub-agent's result is good enough to use. For a personal or small-team bot, begin with the smallest set of specialists that solves an observed problem. Review traces and test the routes that exist before adding another role. Include ordinary questions, policy-bound refund cases and failed tool responses in that evaluation. OpenAI recommends adding specialists when they materially improve isolation, clarity or trace legibility, rather than splitting for its own sake. Sources: [Orchestration and handoffs | OpenAI API](https://developers.openai.com/api/docs/guides/agents/orchestration), [Agent orchestration - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/multi_agent/). ## Primary sources Sources checked 2026-09-26. Standards and product documentation can change; follow the linked version when implementing. - [Orchestration and handoffs | OpenAI API](https://developers.openai.com/api/docs/guides/agents/orchestration) — OpenAI - [Agent orchestration - OpenAI Agents SDK](https://openai.github.io/openai-agents-python/multi_agent/) — OpenAI - [Building effective agents](https://www.anthropic.com/engineering/building-effective-agents) — Anthropic BotBento is in development. [Suggest a correction](/contact/).