# Multi-Agent Systems: Orchestrator, Workers, and Handoffs
Ask a single AI agent to "write me a competitive research report on the top 3 electric vehicle makers," and watch it flail. It researches Tesla, forgets to compare pricing, starts writing before it has the data, and runs out of context halfway through. One agent trying to hold the whole job in its head is the problem.
Now split the job. One agent plans. Three agents each research one company at the same time. One agent writes the final report. Suddenly the hard problem is a set of easy problems.
That is a multi-agent system: several AI agentsAI agentsAgentic AI refers to AI systems that pursue goals autonomously by planning, taking actions through tools, and adapting based on results, with minimal step-by-step human direction.View full definition →, each with a narrow job, coordinated to finish one larger task.
A single agent has real limits:
Quick definition: an agent here means an LLMLLMA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.View full definition → (large language modellarge language modelA Large Language Model is an AI system trained on vast text data to predict and generate language, enabling tasks like writing, summarizing, and answering questions.View full definition →, the AI behind tools like ChatGPT or Claude) that can take actions in a loop, calling tools like web search, then deciding what to do next based on the results.
The most reliable structure for multi-agent work looks like a small company:
Here is our research report as an org chart:
┌─────────────────┐
│ ORCHESTRATOR │ plans + delegates
└────────┬────────┘
┌───────────────┼───────────────┐
▼ ▼ ▼
┌────────────┐ ┌────────────┐ ┌────────────┐
│ Researcher │ │ Researcher │ │ Researcher │ run in parallel
│ (Tesla) │ │ (Rivian) │ │ (BYD) │
└──────┬─────┘ └──────┬─────┘ └──────┬─────┘
└───────────────┼───────────────┘
▼
┌─────────────────┐
│ WRITER │ produces final report
└─────────────────┘Notice the shape: everything flows through the orchestrator. Workers do not chat with each other. They report up. This is the single most important design choice in the lesson, and we will return to why.
The magic is in the instructions. Each worker gets a tight prompt.
Orchestrator prompt (simplified):
> You are a research manager. Break the user's request into one research task per company. Send each task to a researcher. When all results return, send them to the writer. Do not research or write yourself.
Researcher prompt:
> You research exactly one company. Find: current pricing, 2025 sales figures, and one key strategic move. Return a short bullet summary with sources. Do not compare to other companies.
Writer prompt:
> You receive research summaries for several companies. Write a 500-word comparison report with a recommendation. Use only the provided research.
Each agent's job is small enough to describe in three sentences. That is the sign of a good split.
A handoff is the moment one agent passes control (and information) to another. Get handoffs right and the system hums. Get them wrong and information leaks or vanishes.
Two things travel in a handoff:
1. The task: what to do next.
2. The context: the information needed to do it.
The common mistake is handing over too much or too little. If the orchestrator forwards each researcher the entire conversation history, you waste context and confuse the worker. If it forwards nothing, the worker guesses.
The fix: hand off only what the next agent needs. The writer needs the three research summaries, not the orchestrator's internal planning notes.
Here is a vendor-neutral sketch of the orchestrator loop in Python. This is pseudocode-flavored but shows the real shape:
def run_report(user_request):
# 1. Orchestrator plans: one task per company
companies = orchestrator.plan(user_request) # -> ["Tesla", "Rivian", "BYD"]
# 2. Workers run in parallel, each with a narrow task
results = run_in_parallel([
researcher.run(f"Research {c}: pricing, 2025 sales, one strategic move")
for c in companies
])
# 3. Handoff: pass ONLY the summaries to the writer
report = writer.run(
task="Write a 500-word comparison with a recommendation",
context=results
)
return reportEach .run() call is itself an agent doing its own tool-call loop (search the web, read results, decide, repeat) before returning. The orchestrator does not care *how* a researcher finds pricing. It only cares that a clean summary comes back.
Every major provider ships tooling for exactly this pattern: the OpenAI Agents SDK has built-in "handoffs," the Claude Agent SDK supports subagents, and Google's ADK (Agent Development Kit) has sequential and parallel agent types. The core idea transfers across all of them. See the provider deep-dive blocks for the exact syntax.
For a clear written breakdown of these patterns, Anthropic's Building Effective Agents guide is free, vendor-honest, and worth 15 minutes.
Here is the tempting idea: what if we skip the orchestrator and let all the agents just talk to each other? The Tesla researcher chats with the Rivian researcher, the writer jumps in with questions, everyone collaborates.
In practice, this "free-for-all" (sometimes called a fully-connected or conversational multi-agent setup) breaks down fast. The failure modes are consistent:
Chatter loops. Two agents get stuck being polite. "Should I include pricing?" "Yes, and should I include sales?" "Good idea, should you also...?" They burn tokenstokensA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition → and money going in circles. (A tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition → is a chunk of text the model processes; you pay per tokentokenA token is the basic unit of text that language models process, often a word fragment, whole word, or punctuation mark rather than a single character.View full definition →.)
Context explosion. When every agent sees every other agent's messages, the shared conversation balloons. Each agent now reads five times more text than it needs, gets slower, costs more, and loses the thread.
No single source of truth. If three agents all edit the report, who owns the final version? Conflicting edits pile up and nobody is accountable.
Untraceable errors. When something goes wrong in a free-for-all, you cannot tell which agent caused it. With an orchestrator, you can inspect each handoff and see exactly where the pricing number went bad.
The rule of thumb for 2026: prefer structure over conversation. Let the orchestrator be the only one who talks to everyone. Workers stay in their lane. You lose a little "creativity" and gain a lot of reliability, cost control, and debuggability.
When *do* you let agents converse? Rarely, and only for genuinely open-ended tasks (like a brainstorm or a debate) where you want divergent ideas and you have a hard stop on the number of turns. For task completion, the orchestrator wins.
Knowledge check
1. What best defines a multi-agent system as described in the lesson?
2. In the orchestrator-worker pattern, what is the orchestrator's primary role?
3. Why does running three research agents in parallel matter for a task like a competitive report?
4. Select ALL correct answers about why splitting work across multiple agents helps overcome single-agent limits.
Select all the correct answers.
5. Select ALL correct answers describing what an 'agent' means in this lesson's sense.
Select all the correct answers.
You do not need five agents to start. Use this checklist.
If a single agent handles the task reliably, stop. Multi-agent adds cost and moving parts. Only split when you hit a real limit: too much context, too many distinct skills, or a need for parallel speed.
Good splits have crisp boundaries. "Research one company" is separable. "Make the report good" is not. If two workers keep needing each other's information, they should probably be one agent.
For each agent, answer: What is your one job? What information do you receive? What exactly do you return? If you cannot answer in a sentence each, the split is too fuzzy.
Always cap the loop. "Try at most 3 times, then return what you have." Without limits, agents can spin forever. This one line prevents the runaway-cost horror stories.
Multi-agent systems run more model calls, so they cost more per task than a single agent. That is the tradeoff for reliability and speed. For our EV report, three parallel researchers plus a writer plus an orchestrator might be five to eight model calls instead of one. Worth it for a report you actually trust. Not worth it for "summarize this email."