Multi-Agent: Subagents, Handoffs, Orchestrators

By the Syncfusion DevTutorials team · Last updated October 27, 2026

When one AI helper has too many tools and a long chat, a front desk can split the work between specialists. Learn handoff notes, lost facts and the scorecard rule.

Multi-Agent: Subagents, Handoffs, Orchestrators

Asha has chatted with Shop Helper all day. Most of it was about a new delivery address.

Now she writes, "Where is my rain jacket, order 1044? Then send me an email about it."

Shop Helper reads the whole long chat. It sees six tool cards. It picks "Change address", twice.

Asha never learns her jacket is late. No email goes out.

This lesson shows a different way to build the helper: a small team. A front desk splits the work, and specialists each do one part.

It also shows when a team is worth the extra cost, and when it is not.

Simple lesson: split the work only when one helper gets overloaded.

A Real-World Example

Think about a big hotel.

• A guest walks up to the front desk with three requests.
• The desk clerk writes a short note for each one.
• One note goes to housekeeping. One goes to the kitchen. One goes to the bell desk.

Each team does one kind of job, so it does that job well.

But a tiny guest house with three rooms has no front desk. The owner does everything, because a team there would only cost more.

An AI helper works the same way. A team helps with busy, mixed work. It wastes money on simple work.

Simple lesson: a team pays off only when there is enough work to split.

What You Will Learn

In this lesson, you will learn:

1. Why one helper with many tools and a long chat picks the wrong tool.
2. How a front desk splits the work between specialists.
3. What a good handoff note carries.
4. How a fact gets lost in a handoff.
5. How to read a scorecard and decide: one helper or a team.

One Helper, Too Many Tools

So far, Shop Helper has been one helper with all six tools. That works well for short, simple chats.

Remember how the pretend model picks a tool. It picks the card whose description best matches the words it reads.

One helper reads the whole chat for every pick. Old messages stay in the chat, so their words count too.

In Asha's chat, the old messages talk about addresses and deliveries. Those words match "Change address" better than anything she asks for now.

Press Play and watch the six tool cards.

• The earlier messages badge: the helper reads all of them on every call.
• The word counts: the wrong card wins because of old words.
• The second pick: the same wrong card wins again.
• The bill: every call carried the whole long chat.

A real model understands meaning far better than this word match. But real models do get confused by long chats and long tool lists. More cards means more ways to pick the wrong one.

Simple lesson: many tools plus a long chat give one helper many ways to go wrong.

The Front Desk and the Specialists

A team splits the job into smaller jobs.

Orchestrator (front desk) = the helper that splits the chat into asks and sends each ask to a specialist. It does not use shop tools itself.

Subagent (specialist) = a helper with one kind of job, a few tools and a short chat of its own.

Shop Helper's team has three specialists:

• Orders looks up orders and changes addresses.
• Billing gives refunds and sends emails.
• Help pages searches the shop's rules.

Press Play and follow the notes from the desk to the windows.

• The split: two asks become two notes.
• Each window: it shows only two or three tool cards.
• The picks: each specialist picks the right card for its one ask.
• The bill: the team makes more model calls than one helper.

Simple lesson: the front desk decides who does what, and each specialist does one thing.

Why Specialists Pick Better

A specialist has two advantages.

First, it sees fewer tool cards. Billing never sees "Change address", so it cannot pick it by mistake.

Second, it reads less. It never sees the long old chat. It reads only a short note about one ask.

So the old words about addresses cannot pull it the wrong way. Each call is also smaller, because the note is short.

The front desk still reads the long chat. But it only has three desk cards, and its one job is to split and send.

Simple lesson: fewer cards and less to read mean fewer wrong picks.

The Handoff Note

A specialist never sees the chat. Everything it knows comes from one note.

Handoff note = a short message from the front desk to a specialist. It carries every fact the specialist needs to do its part.

A good handoff note has four lines:

1. Customer: who is asking, so the tool can check the order is theirs.
2. Order: the exact order number, because tools need it.
3. What they want: the ask, in the customer's words.
4. Already done: what other helpers have done, so nothing is done twice or skipped.

Here is a real note from the team, for Asha's new address. It goes to Orders:

Customer: Asha (C-101)
Order: 1042
What they want: Send order 1042 to 9 Oak Road instead
Already done: Nothing yet

Press Play and watch the note get written, line by line.

• Lines 1 to 4: each line fills in, with the reason it is needed.
• The slide: the note moves to the Billing window.
• The pick: Billing uses each line to do its job.

Two Kinds of Handoff

The word "handoff" means two different things. Say which one you mean.

• Handoff note: the front desk sends one task to a specialist, and the specialist reports back. The front desk stays in charge of the chat. This lesson teaches this kind.
• Full handoff: the whole chat passes to another agent, which takes over and talks to the customer from then on. Some frameworks use "handoff" for this kind (see Framework Tour: The Same Agent, Five Ways).

Send Only What Is Needed

Send each specialist the handoff note, not the whole chat. It does its job better with less to read.

It also keeps personal data contained. Billing does not need Asha's old chat about her office address, so it never sees it.

Simple lesson: the note is all the specialist knows, so it carries every fact it needs and no more.

A Fact Lost in a Handoff

Teams add a new way to fail. A fact can drop out between the front desk and a specialist.

Look at Asha's message again. The order number is in her first ask. The second ask just says "send me an email about it."

Now picture a small bug. The front desk copies the order number only from the ask it is sending. The second note goes out with no order number.

Rule 2 says the pretend model fills in missing inputs with a guess, unless the tool card says to ask. It may grab any number it saw. So Billing guesses an order.

The same rule explains the exercise below. Say an ask names "5 Elm Street" and the note has no order number. The specialist may grab the 5 as the order number.

Press Play and read the Order line on each note.

• Note 1: it has the order number.
• Note 2: the order line is missing.
• The guess: Billing emails about a different order.
• The result: the same team that worked before now gets it wrong.

Simple lesson: every handoff is a place where a fact can get lost.

The Price of a Team

A team is not free.

One helper makes one call per tool, plus one for the reply. A team makes a call at the front desk, two calls per specialist, and one more for the reply.

So you need proof that a team is worth it. That proof is a scorecard.

Run the same test chats through both builds. For each build, count two things:

• how many chats it solved,
• how many coins it spent.

Press Play and compare the two columns.

• The hard set: mixed asks and long chats. The team solves more.
• The simple set: one short ask each. Both solve them all.
• The coins: on the simple set, the team just costs more.
• The verdict: it changes with the chats, not with the idea.

A team can even cost less. With very long chats and many asks, one helper sends the whole chat on every call. Specialists send only short notes.

Simple lesson: a team costs extra calls, so let the scorecard decide.

One Helper or a Team?

Here is the rule this course uses.

Build a team only when the scorecard shows one of these:

• the team solves more test chats,
• or the team solves the same number for fewer coins.

In every other case, keep one helper. It is cheaper, and it has no handoffs to break.

Start with one helper. Add a specialist only when your test chats show one helper getting overloaded.

Simple lesson: the team must win on the scorecard, not just sound smarter.

Where This Is Used

Many real products use some kind of team:

• Support apps often have a triage step that sends billing questions to a billing helper.
• Coding helpers may send a search job to a helper that only reads files.
• Research helpers may split a big question into parts and send each part to a separate helper.

Tools and papers call these "subagents", "multi-agent systems" or "handoffs". Each tool sets them up in its own way.

Simple lesson: real teams follow the same idea: split the job, pass clear notes, check the cost.

In Code

Here is the team in TypeScript, with the Shop Helper names you know: Asha, order 1044, lookup_order, send_email.

The first cell is a front desk. It writes a typed HandoffNote for each ask. Each specialist gets the note and only its own tools.

Front desk, notes and specialists

interface HandoffNote {
  customer: string;
  orderId: string | undefined;
  ask: string;
  alreadyDone: string[];
}

type Tool = (orderId: string) => string;

// Each specialist owns only its own tools.
const shippingTools: Record<string, Tool> = {
  lookup_order: (id: string) =>
    id === "1044" ? "rain jacket, shipped, late, arrives Monday 3 Nov" : "not found",
};
const billingTools: Record<string, Tool> = {
  send_email: (id: string) => `email sent about order ${id}`,
};

function specialist(name: string, tools: Record<string, Tool>, note: HandoffNote): string {
  const tool: string = Object.keys(tools)[0];
  if (note.orderId === undefined) return `${name}: no order id in the note`;
  return `${name} ran ${tool}: ${tools[tool](note.orderId)}`;
}

function show(n: HandoffNote): string {
  const done: string = n.alreadyDone.length ? n.alreadyDone.join(", ") : "nothing";
  return `${n.customer} | order ${n.orderId} | ${n.ask} | done: ${done}`;
}

// The front desk splits the message and writes one note per ask.
const message: string = "Where is my rain jacket, order 1044? Then send me an email about it.";
const orderId: string | undefined = (message.match(/order (\d{4})/) || [])[1];
const n1: HandoffNote = {
  customer: "Asha C-101", orderId, ask: "Where is the rain jacket?", alreadyDone: [],
};
const r1: string = specialist("Shipping", shippingTools, n1);
const n2: HandoffNote = {
  customer: "Asha C-101", orderId, ask: "Email about the order",
  alreadyDone: ["looked up order 1044"],
};
const r2: string = specialist("Billing", billingTools, n2);

console.log("Note 1:", show(n1));
console.log(r1);
console.log("Note 2:", show(n2));
console.log(r2);

Expected output:

Note 1: Asha C-101 | order 1044 | Where is the rain jacket? | done: nothing
Shipping ran lookup_order: rain jacket, shipped, late, arrives Monday 3 Nov
Note 2: Asha C-101 | order 1044 | Email about the order | done: looked up order 1044
Billing ran send_email: email sent about order 1044

• The note type: four fields. The type checker makes the front desk fill each one. orderId may be missing, so the type says so.
• The tool lists: Shipping cannot send email. Billing cannot look up orders. Each one only gets its own list.
• The note is all it knows: the specialist never sees Asha's full message.

The second cell breaks the note. The order id is dropped. Then it compares one helper and the team on two chats.

A lost order id, and a tiny scorecard

interface HandoffNote {
  customer: string;
  orderId: string | undefined;
  ask: string;
  alreadyDone: string[];
}

// Rule 2: a missing input is guessed from any number seen, unless told to ask.
function billing(note: HandoffNote, askWhenMissing: boolean): string {
  if (note.orderId !== undefined) return `email sent about order ${note.orderId}`;
  if (askWhenMissing) return "asks: Which order is this about?";
  const guess: string = (note.ask.match(/\d+/) || ["1042"])[0];
  return `guessed order ${guess}, email sent about order ${guess} (wrong)`;
}

// Bug: the note keeps only the second ask, which names an address, not the order.
const note: HandoffNote = {
  customer: "Asha C-101", orderId: undefined,
  ask: "Email me, I moved to 5 Elm Street", alreadyDone: [],
};
console.log("Unsafe Billing:", billing(note, false));
console.log("Safe Billing:  ", billing(note, true));

// Scorecard: made-up coin prices, same idea as the lesson's scorecard.
interface Row { chat: string; build: string; calls: number; coins: number; solved: boolean }
const rows: Row[] = [
  // a long, mixed chat: one helper rereads all of it on every call
  { chat: "long", build: "One helper", calls: 3, coins: 12, solved: false },
  { chat: "long", build: "Team", calls: 6, coins: 6, solved: true },
  // a short, single ask: the team's extra calls buy nothing
  { chat: "short", build: "One helper", calls: 2, coins: 2, solved: true },
  { chat: "short", build: "Team", calls: 4, coins: 4, solved: true },
];
for (const r of rows) {
  const solved: string = r.solved ? "yes" : "no";
  console.log(`${r.chat} chat, ${r.build}: ${r.calls} calls, ${r.coins} coins, solved ${solved}`);
}

Expected output:

Unsafe Billing: guessed order 5, email sent about order 5 (wrong)
Safe Billing:   asks: Which order is this about?
long chat, One helper: 3 calls, 12 coins, solved no
long chat, Team: 6 calls, 6 coins, solved yes
short chat, One helper: 2 calls, 2 coins, solved yes
short chat, Team: 4 calls, 4 coins, solved yes

• The guess: rule 2 says a missing input is guessed. The unsafe specialist grabs the 5 from "5 Elm Street".
• The safe specialist: it asks for the order instead of guessing.
• The scorecard: the coin prices are made up. On the long chat the team wins. On the short chat it only costs more.

In a Real App

In a real app, each specialist is its own model call. It has its own system prompt and a short tool list. The front desk is a model call too, and it hands over a note, not the chat.

This sketch is simplified. It uses a small model interface instead of one vendor's SDK, because names differ between providers and SDK versions.

// Simplified. Your model SDK will name things differently.
interface ToolDef { name: string; description: string; inputSchema: object }
interface ModelClient {
  run(req: { system: string; tools: ToolDef[]; userText: string }): Promise<string>;
}
interface HandoffNote { customer: string; orderId?: string; ask: string; alreadyDone: string[] }

interface Specialist { system: string; tools: ToolDef[] }

const specialists: Record<"billing" | "shipping", Specialist> = {
  billing: {
    system: "You handle refunds and receipts. "
      + "If the order id is missing, ask for it. Never guess.",
    tools: [/* issue_refund, send_email */],
  },
  shipping: {
    system: "You answer where an order is. Use lookup_order. "
      + "If the order id is missing, ask for it.",
    tools: [/* lookup_order */],
  },
};

export async function handOff(
  model: ModelClient, to: keyof typeof specialists, note: HandoffNote,
): Promise<string> {
  const s = specialists[to];
  // The specialist reads only the note, never the whole chat.
  return model.run({ system: s.system, tools: s.tools, userText: JSON.stringify(note) });
}

The front desk often gets one tool per specialist, such as ask_billing. Its input is the note. A zod or JSON Schema check on that note catches a missing field before the handoff.

Some frameworks also offer a full handoff, where another agent takes over the chat with the customer. Framework Tour: The Same Agent, Five Ways shows what that looks like.

Simple lesson: a specialist is a model call with its own prompt, its own short tool list and one typed note.

TL;DR

1. Orchestrator (front desk) = the helper that splits the chat into asks and sends each one to a specialist.
2. Subagent (specialist) = a helper with one kind of job, a few tools and a short chat.
3. Handoff note = the message to a specialist with every fact it needs: customer, order, the ask and what is already done.
4. Lost fact = a fact the note leaves out. The specialist guesses instead.
5. The cost rule = a team makes more model calls than one helper.
6. The scorecard rule = a team only if it solves more, or the same for fewer coins.

Common mistakes

Check Your Understanding

Exercises

What to Remember

• One helper with many tools and a long chat can pick the wrong tool.
• A front desk splits the work. Each specialist has a few tools and reads only its note.
• A handoff note carries the customer, the order, the ask and what is already done.
• Every handoff is a place where a fact can get lost. A lost fact becomes a guess.
• A team makes more model calls. Build one only when the scorecard says it solves more, or the same for fewer coins.

Next: MCP: Tools from Outside the App, how the helper plugs in tools from other services.