Skip to content
AI-Native PM
8 min · 0 of 8 in Orchestration

Patterns: fan-outs, pipelines, and judge panels

Eleven drafts are finished, the twelfth is still running, and nothing else is moving. You wrote the run as two batches because two loops were easy to script: draft all twelve help-center articles, then tighten all twelve. Eleven finished drafts sit in a folder, each ready for its second stage, all waiting on the slowest item in the set. When the twelfth lands, the tightening batch starts, and the same stall repeats at the end of that stage.

Nothing in the work demands the wait. Tightening article three needs the draft of article three and nothing else. The split was clean, and you cut those seams in Decomposition: split work so agents never collide.

How you split the work and how you run the split are two separate decisions, and the run pattern is the one costing you the wait here.

This chapter covers the patterns real fleets keep returning to, what each one buys you, and how to choose.

Fan-out: the default for uniform work

Take items that pass the independence test, give each its own agent and context, run them all at once, and gather the results at the end. The gather is the run's only synchronization point, and it is one the work genuinely requires, because you cannot assemble the whole before the parts exist.

A fan-out fits when the items are uniform: articles cut from one template, a test file per module, a summary per transcript. Each agent gets the same prompt with its item swapped in, the wall-clock drops from the sum of the items to roughly the slowest one, and the results land together, so you review the stack in one sitting against one rubric. If one item feeds another, that is a seam problem, and it goes back to decomposition.

Pipeline: let each item flow through its stages

Some work is staged. Each article gets drafted, then tightened, then checked, and for any single article those stages must run in order. The opening scene's mistake was promoting that per-item ordering into a fleet-wide one.

In a pipeline, each item moves through its own chain of stages and never waits for the others. Article A can be in the checking stage while article B is still drafting, and the moment a draft lands, the tightening agent for that article starts. The whole set never lines up.

The wall-clock difference is large. With batch barriers you pay for the slowest item of every stage in turn, and a different straggler sets the pace each time. Pipelined, the same work costs only the slowest single item's full chain, and every other item finishes while that one is still running.

A barrier is justified only when a stage genuinely consumes the whole set rather than one item at a time. Deduplication qualifies, because you cannot remove repeats among results that do not exist yet. An early exit qualifies, because when stage one is a scan and a clean scan means stage two never runs, pausing to check beats charging ahead. Almost nothing else qualifies.

One more staged pattern gets the next chapter to itself: give every worker a second agent whose only job is checking that output against the spec, and you have the writer-verifier pair that Verification: make the fleet check its own work is built around.

Judge panel: resolve independent attempts into one verdict

The patterns so far divide one job across agents, but a judge panel runs the same job several times and compares the attempts. Some tasks have a wide solution space, where two well-built attempts can land in genuinely different places: a root-cause diagnosis, a naming decision, a risk call on a contract clause. One attempt tells you little about a space like that, so you run the same task through several agents independently and then reconcile their answers. How you reconcile them depends on what kind of output they produce.

  • Vote when answers are discrete. For classifications, diagnoses, and pass-or-fail calls, the technique called self-consistency established the base result: sampling a model several times on the same problem and taking the majority answer beats the single most likely completion. Later work scaled the ensemble: accuracy climbs as voters are added, then flattens, with the largest gains on the hardest tasks.
  • Synthesize when answers are prose. Three drafts of an onboarding email have no majority, so hand the attempts and your rubric to one synthesis agent for a merge that keeps the strongest part of each, or rank them yourself and ship the winner.

A vote only counts when the attempts are independent. Agents given identical context and identical framing produce near-copies, and a majority of near-copies is one answer counted several times, so vary the outline each attempt starts from, the order of the source material, and the sampling settings.

Orchestrator-worker: a lead agent writes the split

Every pattern so far assumes you wrote the decomposition yourself. Sometimes you cannot, because the right subtasks only become visible once the question has been worked on. Orchestrator-worker hands the split to a lead agent, which reads the goal, writes the subtasks, spawns workers in parallel, and synthesizes what they bring back.

This is the pattern behind the published research systems. A 2025 engineering account of one production multi-agent research product describes it: an orchestrator decomposes the research question, parallel subagents search independently, and a synthesis pass assembles one answer from the findings. The reported improvement over a single agent on internal research evals was large, and the token bill was materially higher.

Reach for this pattern when you could not write the subtask list without doing half the work first. It is also the most expensive pattern here, and Economics: what a fleet costs and when it pays covers when it earns its keep.

Match the pattern to the work

  • Uniform, independent items: run a fan-out. Most fleet work has this pattern.
  • Items that each pass through stages: run a pipeline, and allow no barrier you cannot justify out loud.
  • A wide solution space or a contested call: convene a judge panel, voting on discrete answers and synthesizing prose.
  • A split you cannot write up front: use orchestrator-worker, with a budget attached.

Patterns also compose, an orchestrator running fan-outs underneath or a pipeline ending in a panel, but get fluent with the plain ones first.

Try it now

The drill takes about twenty minutes and runs one real task in two patterns.

Pick a real mini-task. Choose something from your backlog with three uniform sections: three help-center articles, three sections of a README, three screens of a spec. Use real work so the output is something you would ship.

Run it as a fan-out. Tell Claude Code to draft the three sections in parallel subagents, one section per agent with your style rules in each prompt, then gather the results into a single file. Note the wall-clock from kickoff to gathered file, and notice that everything arrives together, ready for one review pass.

Run it again as a pipeline. Same sections, two stages each: one agent drafts, and the moment a draft lands, a second agent tightens it against the same style rules. Do not hold the tightening until all three drafts exist. Note the wall-clock again.

Compare the runs. Write down which pattern finished sooner and which one fit how you wanted to review. The clocks may sit close at this scale, but the feel is the durable lesson, because the fan-out lands as one reviewable batch while the pipeline trickles finished sections to you mid-run.

Scale it down: two agents and two sections give the same comparison at lower cost.

Chapter Summary

  • How you split the work and how you run the split are two separate decisions, and the run pattern is usually what is costing you time.
  • Use a fan-out for uniform, independent items: give each its own agent, run them all at once, and gather the results at the end. This covers most fleet work.
  • Use a pipeline when each item passes through stages, so no item waits on the rest and you pay for the slowest single chain instead of the slowest item at every stage.
  • Allow a barrier that stops the whole set only when a stage truly needs every item together, like removing duplicates or stopping early after a clean scan. Otherwise take it out.
  • Use a judge panel when the solution space is wide or the call is contested: run the same task several times, vote when the answers are discrete, and merge or rank them when the answers are prose.
  • A vote only means something when the attempts are independent, so vary the starting outline, the order of the source material, and the sampling settings.
  • Use orchestrator-worker when you cannot write the split up front and a lead agent has to write the subtasks for you. It is the most powerful pattern and the most expensive, so attach a budget.
  • Patterns can be combined, but get comfortable with each plain one before you nest them.
  • Every pattern ends with a stack of output that nobody has checked yet, which is where Verification: make the fleet check its own work picks up.

Sources

  • Anthropic (2025). How we built our multi-agent research system. Anthropic engineering blog.
  • Li et al. (2024). More Agents Is All You Need.
  • Wang et al. (2022). Self-Consistency Improves Chain of Thought Reasoning in Language Models.
Marks this chapter complete on your course map. Reaching the end does this for you.