Orchestration and handoffs

The last lesson gave you the topologies - supervisor, network, hierarchical. This one makes them mechanical: how control and context actually move between agents at runtime. Two questions decide every design - who owns the final answer, and what context crosses the boundary - and getting the second one wrong is the classic reason multi-agent systems quietly fall apart.

Two questions govern every multi-agent design

A single agent is a model in a loop with tools. The moment you add a second agent, you inherit two orthogonal decisions. Answer them explicitly and the architecture almost writes itself; leave them implicit and you get the failure modes at the end of this lesson.

The orchestrator loop

The productionized form of coordination is orchestrator-workers (a.k.a. the supervisor). A central LLM receives the request, dynamically decides what sub-tasks exist, delegates each to a worker, reads the results, and either delegates again or synthesizes the answer. The word that matters is dynamically: unlike fixed routing, the sub-tasks are not predefined - the orchestrator invents them at runtime from the input.^[3]

Concretely, imagine a customer-support manager agent. A message arrives - "I was double-charged and the export button is broken." The manager reads it, recognises two domains, and delegates: a billing brief to one specialist, a technical brief to another. Each worker runs its own loop in its own context window, returns a result, and the manager stitches the two into one reply.

Stripped to its skeleton, the orchestrator runs this loop each turn.

1. Receive and hold context. The manager keeps the full history - it is the only agent that sees the whole picture.
2. Decide the shape. One domain: route or hand off. Several independent domains: fan out to parallel workers. (Decomposition is planning applied to agents.)
3. Delegate with a brief. Give each worker an objective, an output format, tool/source guidance, and a boundary. Vague delegation leads to duplicated, misaligned work.^[4]
4. Collect results. Workers return; the manager reads them. (In a handoff, the specialist has already answered the user and the loop ends.)
5. Synthesise or loop. Enough to answer? Compose the reply. Gaps remain? Spawn more workers and repeat, until done or a step budget trips.

The supervisor is a clean, debuggable hub - but it is also a bottleneck and adds one routing call per hop. When a single supervisor manages too many workers, you go hierarchical: supervisors of supervisors. That escalation ladder is the previous lesson.

Handoffs vs agents-as-tools

These are the two API-level ways to wire the first question - and the OpenAI Agents SDK makes it an explicit choice. Ask one thing: who should own the final response?^[1]

Both are a few lines. The difference is the field you populate - handoffs=[...] transfers control; tools=[...as_tool()] keeps it.

from agents import Agent

billing = Agent(name="Billing", instructions="Answer billing questions.")
refunds = Agent(name="Refunds", instructions="Process refund requests.")

# --- Handoff: control transfers; the specialist replies to the user ---
triage = Agent(
    name="Triage",
    instructions="Route the user to the right specialist.",
    handoffs=[billing, refunds],          # transfer + conversation history
)

# --- Agents-as-tools: the manager keeps control and composes the reply ---
manager = Agent(
    name="Manager",
    instructions="Gather each specialist's answer, then write ONE reply.",
    tools=[
        billing.as_tool(tool_name="ask_billing", tool_description="Billing help"),
        refunds.as_tool(tool_name="ask_refunds", tool_description="Refund help"),
    ],
)

The two models also differ in state. Handoffs persist the conversation, so repeat requests are cheaper - roughly 40-50% fewer calls than re-invoking fresh. Agents-as-tools are stateless: every call starts clean, which is better for parallel, independent sub-tasks but wasteful for repeated back-and-forth in one domain.^[7]

What the sub-agent actually sees

Here is the trap that sinks most multi-agent projects. Delegation feels like handing a colleague a ticket - but a colleague shares your hallway, your standup, your history. A sub-agent shares only the bytes you put in its context window. Cognition's two rules of context engineering are the whole lesson.^[5]

The canonical cautionary tale: split "build a Flappy Bird clone" across two parallel writers. One is told "build the background" and makes a Super Mario-styled world; the other is told "build the bird" and makes art and collision assumptions that clash. Neither saw the other's decisions, so the final agent cannot reconcile them.^[5] Sharing the task description is not sharing context.

Aggregation, scaling, and where it breaks

Fan-out is only half the pattern; fan-in is where quality is won or lost. In Anthropic's research system the lead synthesises worker outputs and, when the report is complete, a dedicated citation agent maps every claim back to its exact source - a final aggregation pass, not an afterthought.^[4] Two hard-won rules for the aggregation stage follow.

And the systematic failures are organisational, not just model weakness. The Berkeley MAST study annotated 200+ multi-agent traces across 7 frameworks and found gains over single-agent baselines are often marginal, with failures clustering into three buckets: specification/design (41.8%), inter-agent misalignment (36.9%), and weak verification (21.3%). The single most common failure was plain step repetition (17.1%) - agents redoing each other's work because no one owned the boundary.^[9] Nearly all of these trace back to the two questions we opened with: unclear ownership and leaky context. Instrument the boundaries - tracing is how you catch them.

Check yourself