Orchestrator-Workers vs Agent Handoffs

How do they differ?

Both patterns split work across several agents. They disagree about where control lives.

In Orchestrator-Workers, control never leaves the center. An orchestrator writes a list of subtasks, sends each to a worker with a clean context, and a synthesizer combines the workers' short reports into one answer. Workers never talk to the user or to each other.

In Agent Handoffs, control moves. A triage agent decides the user's problem belongs to billing and calls transfer_to_billing. From then on the billing agent owns the conversation and answers the user directly. It can hand off again until someone answers or a hop cap sends the user to a person.

In Multi-Agent Topologies terms, Orchestrator-Workers is the one-level hierarchical shape, where a supervisor keeps control, and handoffs are the edges of the router and network shapes, where control moves. The question that separates them: does the user need one answer assembled from several pieces of work, or one specialist at a time?

Side-by-side

Who owns the final answer

This axis most often decides the choice. With Orchestrator-Workers, the synthesizer always writes the answer. It sees every worker's report, including those marked FAILED, so it can compare the pieces, point out conflicts, and name gaps rather than fill them.

With handoffs, the answer belongs to whichever agent holds the conversation at that moment. There is no step where several specialists' outputs meet. The Agent Handoffs page is direct about this: if the task needs several specialists' outputs combined into one answer, use a supervisor, where control stays with one coordinator.

Context: compressed reports versus a handoff payload

Both patterns discard context on purpose. An orchestrator's worker receives the goal and one subtask, reads its own material (one vendor's 8,000-token policy in the worked example), and returns a report of about 400 tokens. Information is lost when the orchestrator writes a short instruction and again when the worker compresses its findings.

A handoff passes a payload to the next agent: a sentence or two of summary, structured state such as order ID and amount in typed fields, and the user's request verbatim. In the Agent Handoffs worked example, a payload handoff costs $57.45 per 1,000 conversations over three billing turns, against $109.65 for a handoff that carries the full 6,000-token transcript and $97.20 for one combined agent with both tool sets. Carrying the transcript costs more than not splitting at all.

A thin worker report makes the final answer vaguer, usually visibly. A thin handoff summary loses an exact value (the amount becomes "a charge") and the next agent acts on wrong facts, which is why values the next agent acts on belong in required schema fields.

Parallelism and latency

Orchestrator-Workers runs its workers concurrently. In the vendor example, the orchestrator plan takes 4.7 s, the slowest small-model worker 3.2 s, and the synthesizer 25.5 s, for 33.3 s per request at $42.90 per 1,000 requests. Run the five workers one after another and it takes 46.0 s. The single large-model call with all five policies is faster (25.5 s) but costs $144.00; the savings come from putting the reading on the small model, not from the orchestration.

Handoffs are sequential by nature. Only one agent is active, and each switch adds a model call to the turn where control changes. In the support example that call writes a 200-token handoff on the large model, 0.5 + 200 / 60 ≈ 3.8 s, so the switch turn takes 8.5 s instead of 4.7 s. When switches are rare, that is a small price for shorter specialist prompts.

When to use Orchestrator-Workers

• The request splits into independent pieces, but which pieces depends on the input, such as one per vendor on a shortlist that changes per question
• Each piece needs heavy reading the others do not, so clean contexts and small-model workers pay off
• The user wants one combined answer, such as a comparison or a report

If your code can list the subtasks, use Parallelization, which is cheaper and deterministic. If the steps depend on each other, use Plan-and-Execute or Prompt Chaining. If the pieces must agree on many shared decisions, keep one agent with the full context; this is the argument Cognition makes against splitting tightly coupled work.

When to use Agent Handoffs

• The conversation can move between domains that need different tools or policies, such as triage, billing, technical support, and account changes
• The right specialist only becomes clear partway through, after a question or two
• Specialists are owned by different teams, or warrant different models

If one classifier on the first message can pick the handler and the domain never changes mid-conversation, a Semantic Router is cheaper and fully deterministic. If one agent with a modest tool set handles every domain well, Tool Calling alone is simpler than any handoff graph.

When the user talks to several specialists

This case points at handoffs. A user fixes a login error with technical support, then asks about a double charge. The right agent has changed, and the new one should answer directly and keep answering on later turns; the handoff pattern persists the active agent so it does. An orchestrator could treat each turn as a new request, but every turn would pay for a plan and a synthesis on the large model, and no specialist would own the conversation.

The reverse case points at Orchestrator-Workers. If a single user question needs billing, technical, and account information together ("why was I charged after I closed the account that kept failing to sync?"), a supervisor that asks all three at once and writes one reply fits better than a relay of partial answers.

Loop risks: ping-pong versus runaway fan-out

Handoffs ping-pong. Two agents with overlapping scopes each decide the request belongs to the other. The Agent Handoffs implementation sets MAX_HANDOFFS = 3, which allows at most four agent calls per user turn before escalating to a person. If each hop writes a 200-token handoff at about 3.8 s per call, a ping-pong that hits the cap costs about 15.3 s before the user sees the escalation message. Every cap hit means two scopes overlap; tighten the descriptions and pass the path so each agent sees who already declined.

Orchestrators fan out too far. Left alone, an orchestrator splits a simple question into many subtasks, each adding a worker call and a report to the synthesizer's input. The implementation caps the plan at MAX_SUBTASKS = 6. Using the vendor example's per-worker figures and holding the plan's cost fixed, six workers bring the request to about $45.57 per 1,000; twenty uncapped workers would bring it to about $82.95, with the synthesizer reading 8,500 input tokens instead of 2,900. Follow-up rounds need their own limit too.

Debuggability

An orchestrator's wrong answer traces back to a bad plan, a bad worker, or a bad merge. Log all three, and every request's trace has the same shape even when the worker count changes.

A handoff conversation's wrong answer traces back to a path: which agent handed off to which, with what payload, on which turn. Log every handoff so you can replay the conversation. Routing is also harder to test than a classifier, because each agent's model makes the decision; test it with fixed conversations per agent, plus the router's validation and cap.

Can they work together?

Yes. The common composition puts handoffs at the conversation level and an orchestrator inside one specialist. A support system hands a user to a research specialist, which runs Orchestrator-Workers across several sources and replies itself. Control moved once, and the fan-out stayed inside the agent that owns the answer.

Keep each pattern's caps, and give the whole request one step budget, as Multi-Agent Topologies recommends, because composed shapes multiply calls in ways that are easy to underestimate.

Common mistakes

Building a supervisor out of handoffs. Passing a growing payload through five specialists so the last one can summarize is a slow chain with model-chosen routing. If one answer needs several specialists, use an orchestrator.

Using an orchestrator for a conversation. Planning and synthesizing on every turn of a support chat costs two large-model calls per message and leaves no agent owning the thread.

Trusting the model's structure. Both patterns take structure from model output: a JSON plan or a handoff tool call. Validate it and fail closed: an unparseable plan falls back to a single call, and an unknown handoff target goes to a person.

Leaving the loops unbounded. Cap subtasks, rounds, and hops in code, not in the prompt.

Choosing based on your constraints

If the user needs one combined answer from several independent pieces of work, use Orchestrator-Workers.

If the conversation moves between domains, use Agent Handoffs, with a Semantic Router for the first assignment when the opening message is easy to classify.

If latency per conversational turn matters, handoffs add a call only on turns where control changes; an orchestrator adds a plan and a synthesis to every request.

If neither fits cleanly, try one agent with the right tools first; both pattern pages treat the extra agents as overhead when it answers well.

References

• Anthropic. (2024). Building Effective Agents. Names orchestrator-workers as a workflow in which a central LLM breaks down tasks dynamically and synthesizes results, and describes the routing workflow.
• Anthropic. (2025). How we built our multi-agent research system. A lead agent spawns subagents with separate context windows; covers delegation instructions, scaling effort to query complexity, and token cost.
• Cognition. (2025). Don't Build Multi-Agents. Argues that subagents working without shared context make conflicting decisions.
• OpenAI. OpenAI Agents SDK documentation: Handoffs and agents as tools. Handoffs presented to the model as tools, and one agent delegating to others.