TL;DR
Delegation comes in three shapes — router (one router picks one specialist), sequential (a chain, each feeding the next), and parallel (fan independent work out at once, then merge) — chosen by the dependencies between sub-tasks. The harder half is what each agent sees: the orchestrator must pass just enough context down, and assemble results carefully on the way back.
Three ways agents hand off
Once you have a router and specialists, there are three common ways they work together — and picking the right one is most of the design.
Router picks one specialist; Sequential chains them so each feeds the next; Parallel fans work out at once and merges the results.
Router pattern
One router classifies each request and sends it to one specialist. This is what your lab builds: a billing question goes to the billing agent, a technical question to the technical agent. The router makes a single choice per turn. Use it when each request belongs to exactly one specialty — it's the simplest pattern and the easiest to trace: one hop, one specialist, one answer.
Sequential pattern
The request flows through specialists in order, each building on the last: research → draft → edit, or extract → transform → validate. The output of one specialist is the input to the next. Use it when the work has stages that must happen in sequence. The trace reads as a chain, and a failure at any stage stops the pipeline.
Parallel pattern
The router fans the work out to several specialists at once and combines their results. Summarize three papers? Hand each paper to its own summarizer simultaneously, then merge the three summaries. Use it when the sub-tasks are independent — none needs another's output — and you want them done concurrently. It's the fastest for independent work, but the trace branches and you pay for every branch. (Don't run dependent steps this way: if stage B needs stage A's output, fanning them out means B runs on missing input — that's a sequential job, not a parallel one.)
Picking a pattern
The question to ask is about the dependencies between sub-tasks:
- One request → one specialty? Router.
- Stages that depend on each other in order? Sequential.
- Independent sub-tasks you want done at once? Parallel.
A research assistant summarizing three independent papers is the parallel case — the summaries don't depend on each other, so fan them out and merge. If it then had to write one combined report from those summaries, that final step is a sequential stage tacked on after the parallel fan-out. Real systems compose patterns.
Analogy
Router is a switchboard operator connecting you to one department. Sequential is an assembly line — each station adds to the work in order. Parallel is handing copies of a task to a whole team at once, then collecting their answers. Same workers; the choreography is what differs.
The orchestrator owns the context
Choosing a shape is the easy half. The hard part isn't who runs — it's what each agent sees. A sub-agent only knows what the orchestrator (the router/parent) hands it, which makes the orchestrator's real job context management, in two directions:
- Down (the hand-off). What slice of the request, history, and data does this specialist need to do its job?
- Up (the return). The specialist returns a result; the orchestrator has to integrate it — use it as the final answer, feed it to the next stage, or merge it with siblings.
Pass just enough context
The amount of context you forward is a real dial, and both extremes hurt:
| You pass… | Result |
|---|---|
| Too little (just "help this user") | The specialist is blind — missing the account id, the actual question, the relevant history |
| Just enough (the question + the ids/data it needs) | Focused, cheap, fast — the specialist can concentrate on the task |
| Too much (the entire conversation + every tool result) | You've re-created the mega-agent's bloat inside every sub-agent — cost climbs and focus is lost again |
That's the checkpoint: the router should forward the question and the account id — the specialist's job is this billing request, not the whole chat history. Passing the entire conversation re-bloats the context you split the agent up to avoid (Lesson 1's context isolation). Pass the minimum the specialist needs; nothing more.
Analogy
Delegating is like handing off a ticket to a specialist colleague. You don't forward them your entire inbox — you write a focused brief: "customer #4821 wants a refund on order ORD-99; here's the order." Too vague ("a customer needs help") and they can't act; your whole inbox and they drown. A good brief is just the task and its facts.
Assembling results on the way back
What the orchestrator does with returned results is exactly what distinguishes the three patterns:
- Router — pass the specialist's answer straight through; the orchestrator barely transforms it.
- Sequential — feed each result as the input context to the next stage, so context accumulates deliberately down the chain.
- Parallel — collect all branches and merge them into one answer, handling the case where one branch failed while others succeeded.
The merge step is where parallel earns its keep and its complexity: combining three summaries into a coherent whole is itself a task — often one more model call.
Common mistake
Forwarding the full conversation history to every sub-agent "so it has context." This quietly undoes delegation: each specialist now carries the mega-prompt you split apart, paying for context it doesn't need. Brief each specialist narrowly — context isolation is the point of sub-agents, not an obstacle to work around.
Key takeaways
Key takeaways
- Router (one specialty per request), sequential (ordered stages), parallel (independent work, fan out and merge) — pick by dependencies; real systems compose them.
- The orchestrator owns context: what to pass down, how to assemble what comes back.
- Pass just enough context — too little blinds the specialist; too much re-bloats it.
- Return-handling defines the pattern: pass-through (router), feed-forward (sequential), merge (parallel).
Optional — the cost and trace shape of each pattern
Each pattern trades latency, cost, and trace legibility differently:
- Router — cheapest and simplest: one extra hop, a linear trace. The router call itself is small (classify only), so the overhead over a flat agent is minimal.
- Sequential — latency adds up: total time ≈ the sum of every stage, because each waits for the previous. The trace is a clean chain, but a slow middle stage delays everything after it.
- Parallel — latency is the slowest single branch, not the sum, so it's fastest for independent work. But cost is still the sum of all branches (you pay for every specialist), the trace branches, and you must handle one branch failing while others succeed (partial results).
Rule of thumb: parallel buys speed at no extra token cost over sequential (same work, just concurrent) but adds orchestration complexity; sequential buys simplicity at the cost of latency; router is the cheap default when one specialist suffices.
Optional — agent-to-agent as a protocol
In this lab, sub-agents are functions you call inside one system. As multi-agent systems span organizations and vendors, the same ideas are being standardized into an open agent-to-agent (A2A) protocol — much as MCP (Module 5) standardized tool access:
- Agents as services. Instead of importing a sub-agent, you call a remote agent over a network the way you'd call any service — so a specialist could be built and run by a different team or company entirely.
- Capability discovery. An agent publishes what it can do (akin to MCP's
tools/list), so an orchestrator can discover and delegate to agents it didn't hard-code. - Structured hand-offs. The brief down and the result up become a defined message format, so independently-built agents can interoperate without bespoke glue.
The throughline: MCP standardizes how an agent reaches tools; A2A standardizes how an agent reaches other agents. The orchestration discipline here — pass just enough context, integrate results carefully — is exactly what those protocols formalize.