When do I need multi-agent orchestration instead of one agent with tools?

I still get the same request: a fleet of specialists because a vendor deck said multi-agent. They name a researcher, a writer, a reviewer, a deployer. Two weeks later they cannot say which one dropped the finish line.

I run one agent with a short tool list until that worker would hold keys that should never sit together: research and deploy, search and send, a draft and the live list. One body with all of those grants is not a clever operator. It is a blast radius.

When I do split, I am not buying more intelligence. I am buying isolation. Specialists share a goal, they do not share a wallet, and orchestration is the shop rules: who acts, what gets passed, who is allowed to spend.

One agent with tools is the default. A fleet is a shop: specialists under one goal, split grants, a packet at every seam. Use the shop when one worker would need permissions that should never sit together, and split late, because extra agents add extra failure at the handoff.

One agent with tools is the default

A single worker with a job, a short tool list, and a stop rule will finish most desks I see. Tool calling is the contract: the model picks a name and arguments, and the runtime returns a short true result. Extra agents do not make that loop smarter, and they make it harder to read.

An ops agent is software given a job and a set of tools. It plans, calls those tools, reads what came back, and continues until the job is finished or it hits a limit you set. I wrote that definition in what an ops agent is, and multi-agent orchestration is what you add after one worker would have to hold two jobs that should never share a grant.

Anthropic’s Building effective agents, published 19 December 2024, opens with the same bias: find the simplest solution possible, and only increase complexity when needed. For many applications, one model call with retrieval and a few tools is enough. Agentic systems trade latency and cost for task performance, and you should know when that trade is worth it before you name a second worker.

OpenAI Agents SDK orchestration guide says the same in 2026: start with one agent whenever you can. Add specialists only when they materially improve capability isolation, policy isolation, prompt clarity, or trace legibility. Splitting too early creates more prompts, more traces, and more approval surfaces without making the workflow better.

LangGraph’s multi-agent docs are blunt about the same default. Not every complex task needs several agents; a single agent with the right tools and prompt can often do the job. I treat that as the production rule, not as a footnote.

What “one agent with tools” actually means is tool calling. You declare named functions with a schema, the model emits a name and arguments, and your runtime executes the call, logs it, and feeds a short true result back. Search is not send, read is not deploy, and the description of the tool is the prompt, so be exact.

I start under ten tools, because each extra tool is a way to wander. If the list grows because the job has several verbs, I do not immediately mint specialists. I first ask whether the verbs share a permission class: inbox search, thread archive, and a file write can live on one worker, and inbox search and a wire to the bank cannot.

Split only on permissions

The hard rule is grants, not job titles. If one worker would hold the repo keys and the bank keys, I split. If the tools share a permission class, I keep one body and I shorten the tool list, because skill names on a slide are not a reason to add a specialist.

Permissions are the reason a fleet exists. A researcher that can read the wiki should not merge to production, an inbox worker that can search mail should not send the list, and a coder that can open a pull request should not push the production tag. Draft is not send, and branch is not production: those are grants, not vibes.

OpenAI’s 2026 orchestration guide lists policy isolation as one of the few material reasons to add a specialist, and that is the sentence I keep. You can split grants inside one agent if the runtime enforces them, because a tool the model can see is not a tool the runtime will run. Many “we need a fleet” tickets die there: the team needed a permission matrix, not three new names.

I split agents when the runtime cannot keep those grants honest inside one body. If the model can talk itself into a forbidden call, and the only wall is a sentence in the prompt, the wall will fall. A second worker with a second keyring is the wall that holds: the researcher never receives the deploy token, and the deployer never receives the research corpus if that corpus is out of scope.

• Research can retrieve and cannot ship.
• Triage can draft and cannot hit send on the list.
• Code can open a branch and cannot tag production.
• Spend can quote and cannot wire.

If none of those pairs appear on the job, I keep one worker. A writer and a reviewer that share a folder and a read grant are not two agents. They are two prompts pretending to be a company.

The job that is already a shop

Permissions are the hard split. Some desks are already a shop for other reasons, and those reasons are real: tools that fight in one prompt, different clocks, a handoff across people and time zones. I treat those as supporting evidence, not as a license to mint five workers on day one.

LangGraph’s multi-agent documentation names three capabilities people are usually reaching for. Context management means you cannot dump every specialist’s corpus into one window, distributed development means different teams own different tools, and parallelization means independent subtasks can run at the same time. All three are mechanisms, and none of them is a substitute for a finish line.

Tools that fight are the cleanest secondary reason: retrieval wants long quotes, writing wants a short brief, review wants a rubric, and ship wants a diff, so one prompt that holds all four will sand them into mush. I split those only if the grants also differ. Different clocks are a handoff, not a swarm: evening in one office, morning in another, one packet at the seam.

A real handoff is the last supporting reason: the first agent finishes, the second starts, and context must not drop. If that seam does not exist in the actual work, you do not need a fleet; you need a loop that stops. I wrote the packet rules in How to hand off an agent to a human, because orchestration without a packet is just more chat.

One agent versus a fleet

One agent is a worker, and a fleet is a shop. The worker has one loop and one tool list, and the shop has specialists under a shared goal, split grants, and a packet at every seam. I keep the worker until the shop is cheaper to run than the blast radius of one body with every key.

The failure column is the one teams skip. A single worker that misses the file leaves one trace, so you read the tool log and see the bad search or the double send. A fleet that misses the file leaves a seam: the researcher swears the brief existed, the writer never saw the file id, both traces look busy, and the artifact is still missing.

I still call the shop a fleet when I run it. It is not a product you install, and it is the pattern: specialists, one goal, split grants, a packet. Anthropic’s 2024 post is explicit that agentic systems trade latency and cost for performance, so a fleet multiplies that trade, and if the shop does not beat one worker on the artifact, you paid for theater.

Orchestrator-workers is a workflow

Most “multi-agent” decks are workflows with extra labels. Anthropic’s 19 December 2024 post draws the line: a workflow is a system where models and tools are orchestrated through predefined code paths, and an agent is a system where the model directs its own process and tool use. Orchestrator-workers sits on the workflow side of that line.

When to use it, in their words: complex tasks where you cannot predict the subtasks in advance, such as coding that touches an unknown set of files, or search that has to gather from several sources. The shape looks like parallelization; the difference is flexibility. Parallelization uses subtasks you already named, and the orchestrator names them at run time from the input.

YouTube

Open original

Harrison Chase of LangChain walked the same multi-agent graph on 23 Jan 2024.

LangGraph’s workflows-and-agents guide implements the same pattern: an orchestrator breaks the job into subtasks, delegates them to workers, and synthesizes the outputs. Their Send API creates those workers dynamically, each worker gets its own state, and outputs write to a shared key the orchestrator can read. That is a graph you can audit, not a swarm with opinions.

I use orchestrator-workers when the job is “change whatever files this ticket actually touches” or “pull whatever sources this question actually needs,” not because I want three brand names in a trace. The orchestrator is allowed to create work. The workers are not allowed to hold the production keys unless that is their grant, because the pattern does not suspend the permission rule.

Handoffs versus agents as tools

Once you have two specialists, the next design choice is ownership: who writes the user-facing answer, or the artifact, at each branch. OpenAI Agents SDK in 2026 splits that choice into two patterns. Handoffs move control to the specialist, and agents as tools keep a manager in control and call specialists as bounded capabilities.

Handoffs are tools from the model’s point of view. If you hand off to a refund agent, the tool is named transfer_to_refund_agent, the triage agent routes, and once the handoff fires the specialist owns the turn. OpenAI’s docs say this is the fit when the next branch needs different instructions, tools, or policy, and when you want the specialist to speak, or to act, without the manager remaining in the way.

Agents as tools is the manager pattern: in TypeScript you call agent.asTool(), and in Python you call agent.as_tool(). The specialist does a bounded job (summarize, classify, extract), returns a result, and the manager synthesizes the artifact. OpenAI’s 2026 guide says this is the better fit when the manager should own the final answer, when the specialist is doing one bounded task, and when you want one stable outer workflow.

I use agents as tools when I still want one owner of the file: a research helper that returns citations is a tool, a writer that returns a draft is a tool, and the manager is the one I score. I use handoffs when the next branch is a different permission class. Billing should not keep talking after the job has become a refund, and deploy should not keep the research corpus once the ticket is “merge this branch.”

You can combine them. OpenAI’s agent orchestration page is explicit: a triage agent can hand off, and that specialist can still call other agents as tools. I do that when the outer seam is a policy split, and I do not do that on day one, because two patterns at once is two ways to drop state.

Whatever pattern you pick, the seam still needs a packet, because a handoff that dumps the chat log is how the second agent starts the job over. I keep that contract in How to hand off an agent to a human: goal, evidence, next action, limits. The SDK can pass history, and I still force a decision object, because history is a pile and the packet is the baton.

What LangGraph actually orchestrates

LangGraph is a low-level orchestration framework and runtime. It does not decide whether you need a fleet, and it gives you a graph of state, nodes, and edges. Nodes do the work, edges decide what runs next, and you mix code where the path must not drift with a model where you cannot draw the path in advance.

LangGraph’s 2026 multi-agent index lists subagents, handoffs, skills, a router, and a custom workflow. Skills keep one worker when grants match. If you need all of them, you do not have an architecture, and you have a catalog.

I almost never ship a network where any agent can call any other, because anyone-to-anyone is how a goal dissolves. A supervisor is orchestrator-workers with a name, and custom edges are for a path that is already a checklist.

If you use LangGraph, read the graph you compiled, and know which edge is code and which node is a model. I start with one worker and raw tool calls, and I adopt a graph when the path is a graph.

The packet at every seam

Fleets die at handoff: the first specialist does the work, and the second starts as if nothing happened. The first thread was long, and the second agent did not read it. The fix is a packet, not a novel, because shared memory can hold the files and the packet holds the baton.

• Goal: the original finish line, unchanged.
• Evidence: facts and artifact ids, not a vibe summary.
• Next action: the one step the incoming agent must take.
• Limits: spend left, permissions, deadline.

The outgoing agent is not done until it writes that packet, and the incoming agent may not re-ask the whole question. If evidence is missing, it calls a tool; it does not invent a recap.

I use this when work starts in one office in the evening and continues in another in the morning. Time zones hold if the packet is clean. They fail if you pass a transcript and hope.

OpenAI’s handoffs can carry filtered history and structured metadata; use that, and do not confuse it with a decision. Filtering a transcript is hygiene, and writing the next action is orchestration. LangGraph handoffs can return a Command that both updates state and routes to the next node, so put the packet in that state update, because if the next node has to mine a message list you abandoned a pile.

Shared memory is still useful for file ids, retrieved chunks, and prior scores. Agents can read memory; they should not have to mine it to know the job. I keep both, memory for the files and the packet for the baton, and the companion piece on How to hand off an agent to a human is the spec for the seam this page allows you to have.

What usually breaks

The shop fails in the same few ways, and I see them in traces more than I hear them in standups. The model is rarely the interesting part: the seam is, the grants are, and the missing score is. Read those three before you add another specialist.

• One agent with every permission, so a bad step is a bad week.
• A fleet minted from job titles, so three specialists share one grant and still drop the goal.
• A chat dump as the handoff, so the next agent starts the job over.
• Thirty tools on one worker, so it shops instead of working.
• No spend cap, so a retry storm is the first invoice.
• Eval after launch, so the first users are the test set.
• A network where any agent can call any other, so nobody owns the artifact.

The permission failure is the expensive one: a researcher that can deploy will, eventually, and a triage worker that can send the list will, eventually. Prompts do not hold a production boundary; keys do. If you only needed a shorter tool list you never needed a fleet, and if you needed a second keyring you should not have shipped the combined worker in the meantime.

The handoff failure is the quiet one. Both traces look busy, both specialists sound sure, and the file id never moved. Force a done check on the packet or the shop will loop: I fail the outgoing run if the packet is missing a finish line or an evidence id, and I fail the incoming run if it rewrites the goal.

The eval failure is the cultural one. A fleet is harder to score than one worker because you can hide a miss between specialists, and pretty traces that miss the artifact are still zeros. Score the shop the way you score the worker, as I wrote in How to evaluate AI agents: frozen jobs, several attempts, the file as the grade, and a fleet that cannot beat one agent on that set does not ship.

Score the fleet against one worker

A fleet has to beat the single agent it replaced, on the same jobs and the same finish lines. The winner is the one that produced the artifact, not the one that drew a nicer graph. If you cannot name that comparison, you are still in demo, with more names on the trace.

Freeze the task set before you split. Ten jobs that look like production is a start, fifty is better, and you write the done condition for each. Run the single worker until you have a baseline (pass rate, cost per success, steps to done, tool errors), then run the shop on the same set and log which specialist acted, what it was handed, and what it handed on.

Adding orchestration because a slide said multi-agent is how you pay more for the same miss. Adding it because the fleet beat the worker on the artifact, at a cost you can live with, is how a shop earns a place on the desk.

Log the seam: input packet, output packet, latency, spend, error. Failures hide in the handoff, and if you only keep the final message you will not see that the researcher omitted the file id or that the deployer ignored the spend left. A manager pattern gives you one outer trace and a handoff pattern gives you a chain; both are fine if the log names the owner of each step.

I also score grants: a researcher that never attempted deploy is a pass on isolation, and a fleet that finishes by quietly reusing one body with every key is a fail, even if the file landed. Production still follows the same steps I use in How to put an AI agent in production. The fleet version adds one step: prove the split beats the worker, and do not start with a swarm.

Keep one worker until the keys force a split

The route is short: start with one agent and tools, then split only on permissions. If the job is a shop, add a packet at the seam and pick ownership: handoff when the specialist takes the branch, agents as tools when a manager keeps the artifact. Score the shop against the worker, and keep the shop small.

1. 01

   Write the finish line for the whole job

   Name the artifact. “Brief.pdf in the shared drive and the vendor thread archived.” If a script cannot tell that this happened, a person will have to, forever, across however many specialists you invent.

2. 02

   Give one worker the tools that share a grant

   List the calls and keep them under ten if you can. Tool calling is the contract. If the verbs share a permission class, they share a body.

3. 03

   Mark the pairs that must not share a keyring

   Research and deploy, search and send, branch and production tag. If those pairs are absent, stop. You wanted a fleet, and you needed a tighter tool list.

4. 04

   Split those roles and choose ownership

   Handoff when the next branch needs different instructions, tools, or policy. Agents as tools when a manager should synthesize the file. Write a packet at the seam either way.

5. 05

   Score the shop on the frozen set

   Same jobs as the single worker, artifact first, cost and steps second, isolation of grants as a hard gate. If the shop loses, keep the worker.

Anthropic in 2024, OpenAI Agents SDK in 2026, and LangGraph’s multi-agent docs all rhyme: simple first, one worker first, specialists only when isolation, context, or a real graph of work requires it. I tighten that to one sentence for ops. Default is one agent, and you split only on permissions.

An ops agent with a short list of tools will finish the desk you actually have, and a fleet is for the desk where one body would be unsafe. Orchestration is how that shop shares a goal without dropping the evidence. If you cannot say which specialist is allowed to spend, you do not have orchestration; you have extra names.