Building AI agentsMiddleLesson 2026 min read

Orchestrating several agents

One agent can hand parts of a job to others. Learn the orchestrator-worker pattern and handoffs, and when more agents help or just add cost and confusion.

✦ Ask the tutor 🧪 Lab · 30 min 📝 Lesson test

Speed

Lesson in motion

In 60 seconds

Orchestrating several agents

One agent can hand parts of a job to others. Learn the orchestrator-worker pattern and handoffs, and when more agents help or just add cost and confusion.

1/4

In simple words

In a cricket team, the captain does not bowl every over. He decides who bowls, who fields where, and changes plans as the match goes. But a team of eleven for a game of carrom would be silly. More players only help when the job is big enough.

When agents work in teams explained why people split work between agents. Here we look at how to build it. A "multi-agent system" is usually just several model calls, each with its own instructions, tools and context, connected by your code.

Two common patterns

Pattern	How it works	Good for
Orchestrator-worker	A lead agent splits the task, sends parts to worker agents (often in parallel), then combines their results.	Research across many sources, reviewing many files, work that splits into independent parts.
Handoff (routing)	One agent passes the whole conversation to a more suitable agent, like a phone call transferred to the right department.	Customer support with separate billing, delivery and technical agents.

Orchestrator-worker in code

Workers get a small, focused context: just their sub-task, not the whole history. They return short results. The orchestrator only sees those summaries, which keeps its own context clean.

orchestrator.py: split, run workers in parallel, combinepython

from concurrent.futures import ThreadPoolExecutor

def call_model(prompt: str) -> str:
    # Placeholder. Plug in your provider here.
    return "[model answer to: " + prompt[:50] + "...]"

def worker(sub_task: str) -> str:
    # Each worker could run its own agent loop with its own narrow tools.
    return call_model("You are a research worker. Do only this, and reply "
                      "in at most 5 bullet points with sources: " + sub_task)

def orchestrate(goal: str) -> str:
    sub_tasks = [   # in real code, ask the model for this list as JSON
        "Price and validity of plan A",
        "Price and validity of plan B",
        "Price and validity of plan C",
    ]
    with ThreadPoolExecutor(max_workers=3) as pool:
        results = list(pool.map(worker, sub_tasks))
    notes = "\n".join(t + ": " + r for t, r in zip(sub_tasks, results))
    return call_model("Goal: " + goal + "\nWorker notes:\n" + notes +
                      "\nCombine into one short comparison. Say if anything is missing.")

print(orchestrate("Compare three mobile plans for a student"))

Handoffs

A handoff is often built as a tool: transfer_to_billing(reason). When the model calls it, your code switches to the billing agent's instructions and tools, and passes a short summary of the case. Decide carefully what travels with the handoff: the full conversation, a summary, or only the facts the next agent needs.

When more agents help, and when they hurt

More agents tend to hurt when

The task is short or strictly step-by-step
Every step depends on the one before
Agents must share lots of detailed context
You cannot yet make one agent work reliably

More agents tend to help when

The work splits into independent parts
Parts can run in parallel to save time
Different parts need different tools or permissions
One context would be too full for a single agent

Multi-agent systems usually use more tokens in total, because each agent needs its own instructions and context, and results are summarised again. They are also harder to debug: a mistake can start in one worker and show up in the final answer. Start with one agent, and split only when you can point to the problem splitting solves.

Design rules

Give each worker a clear sub-task, a done-test and an output format.
Give each worker only the tools its sub-task needs. A research worker does not need the email tool.
Limit the number of workers and the depth: workers should not spawn workers without limits.
Trace every agent's calls under one run id, so you can follow a problem across agents.
Have the orchestrator check results, for example for missing parts or contradictions, before combining.

Watch out

A worker's output is untrusted input for the orchestrator. If a worker read a poisoned web page, its summary can carry the attack onward. Keep write tools with the agent closest to the user's approval, not with workers that read outside content. See Attacks that spread between agents.

Try this. Think of a task you might give an agent. Could it be split into 3 independent parts? If each part needs the result of the previous one, a single agent is probably better.

Watch and read more

Lab

A written design for a two-level agent system, with a clear argument for why it needs more than one agent.

~30 min

The problem

A newspaper wants a system that, every morning, reads 10 regional news websites and produces a one-page summary of farm-related news in simple language.

Decide: one agent, or orchestrator plus workers? Write three sentences explaining why.
If you choose workers: list each worker's sub-task, tools and output format. If not, write the single agent's steps.
Write the rule for what the orchestrator does when a worker fails or returns nothing.
Mark which agent, if any, may publish, and what approval it needs.

You are done when

The choice between one agent and several is justified by the task shape
Workers (if any) have narrow tools and a fixed output format
Failure of a worker is handled without inventing content
Publishing needs a person's approval and is not given to agents that read raw websites

Hard questions

Try to answer before you reveal. If you can answer these, you understood the lesson.

Q1Two workers return facts that contradict each other. What should the orchestrator do?Reveal

It should not quietly pick one. It can check the sources each worker gave, ask a worker to re-check, or report both versions with their sources and mark the conflict for a human editor. Hiding conflicts makes a summary look confident while being wrong.

Q2Why can adding a "reviewer" agent that checks another agent's work still miss errors?Reveal

The reviewer often uses a similar model with similar blind spots, sees only what it is shown, and may be too easily convinced by a confident answer. It helps most when it has a different view: access to the sources, a checklist of concrete tests, or tools that verify facts. Code-based checks and human review are still needed for important outputs.

Please sign in to continue.

Questions people ask

Is a multi-agent system smarter than a single agent?

Not automatically. It can cover more ground in parallel and keep each context focused, which can improve results on broad tasks. But it also adds cost, delay in combining results, and more places for errors. Measure on your own tasks.

Should all agents use the same model?

They do not have to. Some teams use a stronger model for the orchestrator and cheaper ones for simple workers. Test whether the cheaper workers are still good enough.

How do agents share information?

Through your code: arguments passed to a worker, results returned, or a shared store such as a notes file. Keep the shared data structured and small, and record which agent wrote each item.

What about agent-to-agent protocols?

There are protocols for agents from different systems to talk to each other. They bring their own trust questions: who is the other agent, and what can it ask for? See Agent-to-agent protocols and trust.

Lesson test

5 questions. Get 3 right (60%) to pass and complete this lesson.