Multi-Agent Systems: Orchestrators, Handoffs and When One Agent Is Enough

Why split into multiple agents at all

The honest answer is context. A single agent doing research across twenty sources fills its window with raw search results and loses the thread. A sub-agent that does one search, reads the results, and returns a three-line summary keeps the orchestrator’s context clean. Multi-agent systems are first and foremost a context-management strategy; the "specialist personas" framing is secondary.

The other real reasons: parallelism (independent subtasks run concurrently), permission boundaries (a sub-agent with read-only tools cannot damage anything even if it is prompt-injected), and team ownership (the billing team owns the billing agent). If none of these apply, one agent with good tools beats three agents with a coordination problem.

The three topologies

Supervisor (orchestrator-workers): one agent owns the conversation, delegates subtasks to workers as tool calls, and synthesises their results. The user only ever talks to the supervisor. Predictable, easy to trace, and the default for most tasks.

Handoff (swarm): control of the conversation transfers from one agent to another — a triage agent hands the user to a refunds agent, which may hand back. Each agent has its own instructions and tools, and the user’s messages go to whichever agent currently holds the baton. Good for customer-facing flows with distinct phases; harder to reason about when handoffs bounce.

Parallel fan-out: several agents run concurrently on independent inputs and a merge step combines outputs. Often a stage inside a supervisor design rather than a topology of its own.

The same research team, three ways

Below is one design — an orchestrator that delegates to a searcher and an analyst, then writes a brief — in each provider’s native agent framework. Read them together: the concepts map one-to-one, only the names change. ADK calls them sub_agents, the Claude Agent SDK calls them agents (invoked through its Task tool), and the OpenAI Agents SDK lets you expose an agent as a tool or as a handoff.

# pip install claude-agent-sdk
import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, AgentDefinition

options = ClaudeAgentOptions(
    system_prompt="You are a research lead. Plan the research, delegate each "
                  "sub-question to the searcher, send findings to the analyst, "
                  "then write a 200-word brief.",
    # Sub-agents: the orchestrator invokes them via the built-in Task tool.
    # Each runs in its own context window and returns only its final message.
    agents={
        "searcher": AgentDefinition(
            description="Searches the web for one question and returns ≤5 sourced bullets.",
            prompt="Search for the question you are given. Return ≤5 bullet findings "
                   "with source URLs. No commentary.",
            tools=["WebSearch", "WebFetch"],
            model="haiku",
        ),
        "analyst": AgentDefinition(
            description="Turns findings into the 3 key insights and one open risk.",
            prompt="Given findings, identify the 3 most decision-relevant insights "
                   "and one open risk. Be terse.",
            tools=[],           # no tools → cannot wander
            model="sonnet",
        ),
    },
    allowed_tools=["Task"],  # orchestrator may only delegate
)

async def main():
    async for msg in query(prompt="Research: state of on-device LLMs in 2026",
                           options=options):
        print(msg)

asyncio.run(main())

Handoffs done properly

A handoff is a tool call whose result is "you are no longer the agent". The receiving agent needs enough context to continue — but not the entire transcript, which defeats isolation and leaks unrelated data. The pattern that works: the handing-off agent writes a structured summary (who the user is, what they want, what has been tried), and the receiving agent gets that plus the last few user turns.

Always design the return path. If the refunds agent cannot help, where does the user go? Loops between two agents that keep handing off are a real production failure mode; cap the number of handoffs per conversation and route to a human when it is hit.

Failure modes interviewers probe

Multi-agent systems fail in ways single agents cannot. Know these and their mitigations.

• •Telephone-game degradation: each hop summarises and loses detail. Mitigation — pass structured objects (JSON with required fields), not prose; let workers return citations the orchestrator can verify.
• •Cost multiplication: a supervisor that calls five workers that each call three tools is fifteen model calls per user turn. Mitigation — cheap models for workers, an explicit token budget per run, and a governor that refuses new delegation past the budget.
• •Inconsistent world state: two parallel workers both "book the meeting". Mitigation — side-effecting tools live only with one agent; workers are read-only.
• •Orchestrator laziness: the lead delegates everything, including thinking. Mitigation — instructions that require the orchestrator to write the plan before delegating, and evals that check the plan exists.
• •Untraceable failures: a bad answer and six agents to blame. Mitigation — one trace ID per user request propagated through every hop; every framework here supports this natively.