Multi-Agent Systems: Orchestrator, Workers, and Handoffs

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.Voir la définition complète → (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.Voir la définition complète →, 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 orchestrator-worker pattern

The most reliable structure for multi-agent work looks like a small company:

• Orchestrator (the manager): breaks the task into pieces, assigns them, and assembles the results. It does not do the detailed work itself.
• Workers (the specialists): each receives one clear assignment, does it, and hands the result back.

Here is our research report as an org chart:

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.

What each agent actually gets

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.

Handoffs: passing the baton cleanly

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:

Each .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.

The failure mode: letting agents talk freely

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.Voir la définition complète → 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.Voir la définition complète → 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.Voir la définition complète →.)

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.

Designing your own multi-agent system

You do not need five agents to start. Use this checklist.

1. Can one agent do it well enough?

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.

2. Split by clear, separable jobs

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.

3. Decide the shape

• Sequential (A then B then C): good for pipelines like research → write → edit.
• Parallel (A, B, C at once, then merge): good for independent chunks like our three researchers.
• Orchestrator-worker: a manager coordinates both of the above. This is your default.

4. Write narrow prompts and explicit handoffs

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.

5. Add a stop condition

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.

A quick reality check on cost

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."

Key Takeaways

• Split hard tasks into narrow jobs. One orchestrator plans and delegates; workers each own one clearly separable piece. If you cannot describe an agent's job in a sentence, the split is wrong.
• Route everything through the orchestrator. Do not let workers talk freely to each other. Free-for-all setups cause chatter loops, ballooning context, and errors you cannot trace.
• Design handoffs to pass only what the next agent needs. The writer gets the research summaries, not the orchestrator's planning notes.
• Always add a stop condition. Cap retries and turns so no agent spins forever and burns your budget.
• Start with one agent, split only when you hit a real limit. More agents means more cost and more moving parts, so earn the complexity.