Skip to content
Multi-agent orchestration

07.04 · Concept

Orchestrator and workers

Fan work out and merge it back without losing track of what failed.

No video curated for this lesson yet

This lesson is written, ordered and part of the path - the video slot is the only thing still open. We are working through Agents & MCP lesson by lesson; 56 of 60 have their video so far.

The written notes below cover this idea in full - you lose nothing by reading instead of watching.

Orchestrator-worker fan-out splits one agent run into identifiable worker runs, then joins their outputs with explicit success and failure accounting. The important parts are stable worker IDs, a manifest of expected work, per-worker retry tracking, trace metadata, and a merge step that reports missing or failed inputs rather than hiding them.

What this lesson answers

  • how to fan out agent work safely
  • how to merge worker results with failures
  • how to trace orchestrator worker agent runs

Notes

Orchestrator and workers — An orchestrator-worker pattern exists to split one agent run into tracked sub-runs, because without explicit fan-out, join, and failure accounting, one failed worker can disappear inside a long trace and the final answer may silently omit work.

Key Concepts: - Fan-out creates worker tasks from one orchestrator turn, e.g. `worker_count=5` for 5 documents, 5 tickets, or 5 tool-call batches. - Each worker should carry a stable ID such as `worker_id="doc_003"` so the merge step can map results to inputs with .

Common questions

Why do worker agents need stable IDs?
Stable IDs let the orchestrator match every result or failure back to the original input. Without them, the merge step can only combine whatever came back, which makes missing work hard to detect and even harder to explain in a trace or final response.
What should the orchestrator record before fan-out?
It should record a manifest of the intended work: the input IDs, the kind of worker being used, and the expected result count. That gives the join step something concrete to compare against when workers return, fail, time out, or retry.
Does parallel worker fan-out reduce cost?
Parallel fan-out mainly reduces elapsed time when workers can run concurrently. It does not remove the cost of each worker call, and the merge step can become expensive if it receives full transcripts instead of compact structured outputs.