Lesson 05 · Workflows · 12 min

Orchestrator-workers

Sectioning fixes the sub-tasks in advance: facts, tone, risks, every time. Orchestrator-workers lets the model decide what the sub-tasks are, from the input, and then dispatches a worker to each. The difference is flexibility, and it costs one planning call to buy it.

On the compound message — a cracked table, a double charge, an address change — the orchestrator finds three questions and sends each to a worker in parallel. On a message with one question, it finds one and the pattern collapses to a chain. That adaptivity is exactly what sectioning cannot do.

The orchestrator reads the input and decides what the sub-tasks are; workers handle them in parallel; the orchestrator combines the results. It differs from sectioning in one way: the sub-tasks are not known until the input arrives.

orchestrator · plan   -> {"questions": ["cracked leg?", "charged twice?", "change address?"]}
worker 1, 2, 3        -> run at the same time
orchestrator · merge  -> one reply

One implementation detail is worth more than it looks. The planner is asked for JSON, and JSON mode on most endpoints forces an object. Ask for a bare array and a model will obligingly return an object with the questions as its keys — which parses, and is useless. Ask for an object containing the array.

That exact bug was in the first version of this lab. The orchestrator reported finding one sub-question in a message with three, and the pattern silently degraded into a single call with extra steps. Nothing errored. The lesson's own advice — run the simplest thing and watch what it does — is how it was caught.

Reach for this when tasks genuinely vary in structure. If the sub-tasks are always the same, sectioning is cheaper and more predictable, and the planning call is pure overhead.

Checkpoint

Show the orchestrator dispatching a different number of workers for two different tasks.