Orchestrator and Workers

Fan out, gather back

In the last lesson the router handed each task to one specialist. But some jobs aren't one task — they're a list. Imagine a security agent asked to "alert, scan, and report" on an incident. One agent grinding through all three in a single pass is slow, and if it stumbles on step two the whole answer is lost — and you can't even see which part failed, because the work happens in one opaque breath.

The orchestrator/workers pattern splits the job up. The orchestrator decomposes the goal into subtasks, fans out by handing each subtask to a fresh worker, then gathers the results back and combines them into one answer. The orchestrator never does the work itself — it delegates and assembles. Each worker is small and focused, so it's easy to reason about, easy to retry, and (in a real system) the fan-out can run in parallel.

The discipline is order. Say the subtasks are ["alert", "scan", "report"]. You dispatch them in that order; worker 1 returns ALERT (5), worker 2 returns SCAN (4), worker 3 returns REPORT (6). When you stitch the final line you must preserve that sequence — ALERT-5 | SCAN-4 | REPORT-6 — because the answer is meaningless if "report" shows up before "alert." In a parallel system the fastest worker finishes first, so you can't append results as they arrive; you slot each into the position it was dispatched from.

Fan-out is how multi-agent systems get both speed and traceability. The per-worker trace (worker 1: ...) is your audit log: when one step is wrong you see exactly which worker produced it, instead of debugging a single blob.

Below, the worker is written for you — give it one subtask, it returns one result. The starter cheats by doing everything inline in a single line. Replace that with a real dispatch: loop over the subtasks, call worker() for each, push results into an array in dispatch order, print worker <i>: <result> as you go (i starting at 1), then print the combined final: line.