Orchestration Patterns

Module 1 ended with a decision map: most tasks stay with one agent, and the ones that split do so because they have genuinely independent zones, parallel deadlines, or distinct expertise. This module assumes that decision has been made and answers the next question — what shape the split takes and who runs it.

Keep the framing modest. There are only three patterns worth teaching because, in practice, almost every multi-agent design setup reduces to one of them or a mix: fan-out when the work is parallel and independent, a pipeline when it is staged, and a critic pair when the point is independent review rather than parallel production. Resist the temptation to present orchestration as an architecture discipline with a dozen topologies; the extra patterns you see in vendor material are mostly these three with marketing names.

The other thing to set up front is that orchestration is mostly writing. The artifacts that decide the outcome — the orchestration brief, the worker briefs, the shared constraints, the merge log — are plain files. The product surfaces that schedule and message between agents change quarterly; the files transfer across all of them. That is also why this module's worked example is quoted from real run artifacts rather than described from memory.

Fan-out is the pattern people picture when they hear multi-agent: many workers running at once, each on its own slice. The orchestration article on this site calls the underlying decomposition spatial — split by place: pages, bands, dashboard panels, canvas regions, component folders. Each worker gets one zone and one owned output file, which is what keeps the merge tractable. The merge point is singular on purpose; multiple partial merges are how inconsistencies survive into the final artifact.

The clearest production example is the design-system audit workflow: one agent per component folder, each comparing its folder against the documented tokens and returning structured findings, with an orchestration script collecting results outside the conversation context. In the workflow's traced case, 64 agents covered a 60-component system in about 70 minutes and returned 312 findings — work that takes weeks by hand. That case also shows where fan-out earns its keep: the per-zone work is reading and comparison, the judgment work is concentrated in the report review afterwards.

The cost is the seams. Spacing rhythm drifts between zones, and two zones express the same signal two different ways — in the five-surface run traced later in this module, two workers proposed two different treatments for the same last-reviewed signal, both individually defensible. Fan-out does not remove that class of problem; it converts it into something the merge review is explicitly looking for, which is why the merge gates are written before any worker runs.

The pipeline is the least glamorous pattern and often the most useful one for design work that ends in a deliverable: a spec stage, an implementation stage, a verification stage, each handing a concrete artifact to the next. It barely parallelises, because stages wait on each other, but it merges almost for free — there are no competing versions of the same decision, only the question of whether each stage's output is good enough to feed the next.

What it buys is gates. Every handoff is a place where a human or an executable check can look at the artifact before more work is stacked on top of it. The traced production example from this school's case-study article is a book pipeline with thirteen agent roles defined in one configuration file — architect, researcher, drafter, reviewer, reviser, consistency checker, designer roles, assembler, exporter — with the review threshold and iteration cap in config. Its fix commits concentrated almost entirely at the export and publication boundary: PDF rendering, pagination, publish guardrails. The drafting stages, protected by their review loop, were never the problem. That is the general lesson: in pipelines, defects enter at the handoffs and at the boundary where the artifact leaves the pipeline, so that is where the gates belong.

The failure mode is propagation. A weak early stage feeds every later stage, and if the gates rubber-stamp — approve because the artifact arrived, not because it met criteria — the pipeline becomes a slow way to produce the same mistakes a single agent would have made faster. Module 5 takes this pattern to its full length as the canvas-to-production pipeline; here the goal is just to recognise when staged work is the honest shape of the task.

The critic pair is the smallest orchestration pattern and the one most teams should try first, because it works inside a single session as easily as across two. The producer drafts against the brief; the critic reads the output, the brief, and the constraints, and returns findings — severity, the constraint violated, the evidence — without editing anything. The producer revises against the findings, and the loop runs until the criteria pass or a cap is reached.

Two production examples ground this. In the five-surface orchestration run traced later in this module, the fifth worker was a read-only QA agent whose brief explicitly forbade proposing fixes; it caught both cross-worker conflicts as P1 findings, plus the gaps no brief had assigned. In the book pipeline, the producer-critic loop is parameterised in configuration: a chapter must score at least seven from the reviewer, with at most three revision passes. Putting the threshold and the cap in config makes the editorial standard a reviewable diff rather than a vibe.

The discipline that makes the pattern work is the read-only restriction. The moment the critic starts editing, you have two producers and no reviewer, and the independence that justified the second agent is gone. The other discipline is criteria: a critic told to review for quality produces essays; a critic given the design system's rules, the brief's review criteria, and a severity scale produces findings you can act on. And the critic's pass is never the ship decision — it is evidence presented at the human gate, the same way executable checks are.

Walk the diagram left to right and keep the comparison honest rather than promotional. Fan-out: one orchestrator contract at the top, parallel workers in the middle, one merge review at the bottom. Point out that the merge card is green — it is a decision step, not a collation step — and that the failure strip names the two ways it goes wrong: seams and duplicated signals on the work side, and merge-by-concatenation on the review side.

The pipeline column is deliberately vertical and slow-looking. The gates between stages are ink-coloured because they are the same kind of human-or-check gate the fundamentals course introduced; the point of the pattern is that every handoff gets one. The critic-pair column shows the loop: draft across, findings back, criteria and an iteration cap underneath, and a human gate before anything ships. The green output cards in all three columns make the same point — every pattern ends at a human decision, whatever the topology above it looks like.

Close on the mixing note. Real runs combine these: the five-surface case study is spatial fan-out for its four surface workers plus a functional, read-only critic across all of them, and a canvas-to-production pipeline often contains a critic pair inside its verify stage. The patterns are vocabulary for designing a run, not boxes a run must fit inside.

This table compresses the decomposition guidance from the orchestration article into a slide-sized decision aid. The split-by row is the one to anchor on: the right pattern is usually obvious once you can name where the natural boundaries of the task are. If the boundaries are places — pages, components, canvas regions — fan-out. If the boundaries are stages — something has to be specified before it can be built before it can be verified — pipeline. If there is really only one artifact and the question is whether it meets the bar, critic pair.

Be explicit about the merge-cost row, because it is the one people underestimate. Fan-out's merge is a real design review with conflicts to resolve; budget for it the way the worked example later does — it took roughly a fifth of the run's total time. The pipeline's merge cost is near zero but its wall-clock cost is the highest, because nothing overlaps. The critic pair has no merge at all but pays in rounds, which is why the iteration cap exists.

The last row doubles as a sanity check on the Module 1 decision. Tasks that resist every row — tightly coupled taste work, one shared file, no clear owner — are the tasks that should not have been split in the first place. The functional decomposition variant from the article, splitting by skill rather than place, is deliberately absent as a column: it merges worst of all and is best used the way the case study uses it, as a single read-only critic layered over a fan-out rather than as a team of writing specialists.

The orchestrator is closer to a design lead than to a prompt writer. It decides the decomposition, writes the contract every worker reads, sets the gates work must pass, and runs the merge review where separate outputs become one coherent design again. That is true whether the role is played by a person in one session or delegated to a lead agent on a team surface — the artifacts are identical, which is what makes the role portable across platforms.

Walk the four deliverables. The orchestration brief states the user job once so no worker reinvents it, points everyone at the same shared constraints file, and gives each worker a one-sentence boundary. Named overlaps matter more than they look: the five-surface run deliberately left one in — every surface needed a position on the same freshness signal — so the merge arrived expecting that conflict instead of being surprised by it. The merge log is the durable output: decisions, rejected options with reasons, and gaps logged as open questions rather than answered on the spot. Stop conditions include the fallback path — if workers keep colliding or the merge starts looking like a rescue, hand the briefs, constraints, surviving outputs, and merge log to a single agent and let it finish in one context.

The canonical failure is documented in the agent-teams guidance and reproduced in the traced run: the lead starts implementing instead of delegating. In the run, the orchestrating session caught itself drafting the hero spec before the worker pass had run and discarded the text. The fix is structural: the orchestrator's outputs are the contract and the log, full stop. As of June 2026, Claude Code's experimental Agent Teams surface adds product support for this role — a shared task list, messaging, and plan approval — but the role exists with or without it.

The anatomy of a worker brief does not grow with the team — only the count does. Scope with explicit exclusions, the inputs the worker may read, one task, one owned output file, and acceptance criteria the orchestrator can check in a minute or two without redoing the work. At two workers a boundary violation is an awkward overlap; at five, a worker that wanders re-decides things three other workers own and the merge inherits a tangle, which is why most of this brief's text is exclusions.

Point out what is missing: design direction. The brief does not say what the card should look like or which fields matter most. Taste lives in DESIGN.md and in one shared constraints file every brief points at and no brief restates — duplicating constraints into each brief is how drift starts, because one copy gets edited and four do not. That separation also keeps briefs cheap; the five briefs in the traced run took roughly a quarter of an hour between them, and cheap briefs matter because the alternative is skipping them.

Two more notes from production. First, shared constraints reduce violations but do not eliminate them: one worker in the run introduced an off-token tint anyway and was sent back at the gate, which is what the acceptance check is for. Second, a critic worker's brief has a behavioural boundary rather than a spatial one — it owns nothing, reads everything, and is forbidden from proposing fixes — and that restriction is what keeps its review independent. On platforms with subagent definitions, the worker brief and the worker type are where the same restrictions get enforced mechanically: read-only tools for critics, one writable path for producers.

The merge is the part of the run you cannot delegate away, and at team scale it has a shape worth following in order. First the ownership audit, which is mechanical: list every place a worker specified another worker's surface. Second, classification, because conflicts at this scale fall into recognisable classes — token-semantics conflicts, where two surfaces use the system's colours or type roles to mean different things; seam conflicts, where spacing or band order breaks where two owned regions meet; duplicated-signal conflicts, where the same information is expressed twice in competing ways; and unowned gaps, the decisions nobody was assigned and therefore nobody made. Third, resolution against the constitution rather than the contributors. Fourth, a written record of what was rejected and why.

In the traced run the merge log resolved both conflicts in about fourteen minutes, and the reasoning is worth quoting because it shows what resolving against the system means: the lab-green freshness pill was rejected on token semantics — the design system reserves green for workflow and proof cues and assigns badges to yellow — not on quality. The hero's card strip was kept as a placement decision but stripped of its own card anatomy, because a component definition has exactly one owner. Both rejected options are recorded with reasons, which is what stops the next session relitigating them.

The mechanical parts of this can move into automated gates: a completion hook or CI check can verify that a worker touched only its owned file, grep for raw colour values, and require the do-not section. What cannot be automated is the resolution itself — choosing between the green pill and the yellow badge is a design decision with a reason attached, and the reason is the deliverable. Automate detection and discipline; keep judgment in the merge log, with a name on it.

Run through these as a pre-flight checklist rather than a horror list, because each one maps to an artifact already covered in this module. Racing edits are prevented mechanically: one owned output per worker at spec scale, and git worktrees — an isolated checkout per worker — once outputs become edits to shared code or canvas files. Briefs decide who may change what; isolation makes sure even a worker that ignores its brief cannot quietly overwrite someone else's work.

Divergent assumptions are the conflict class the traced run manufactured deliberately: two workers each proposed a freshness treatment, both defensible, jointly incoherent. Naming the overlap in the orchestration brief converts that from a surprise into an expected comparison. Silent scope growth is the hero worker specifying card anatomy that belonged to the grid worker — caught because the QA critic was reading for exactly that. The lead doing the work is documented in the agent-teams guidance and reproduced in the run; the structural fix is that the orchestrator's only outputs are the contract and the log.

The last two are operational. Merge by concatenation was covered on the previous slide. Leaving the team running matters on hosted surfaces because, per the platform cost guidance as of June 2026, token use scales with team size and idle teammates keep consuming until the team is shut down. Add the quiet one from the article: no baseline, so nobody can say afterwards whether the orchestration bought anything. The worked example next exists precisely because the run kept one.

This run is quoted from the orchestration article, which executed it on scratch files specifically so it could be traced honestly. The shape: four spatial workers — home hero, articles card grid, article header, newsletter band — plus a fifth functional worker, the read-only QA critic, and an orchestrator that wrote the contract, the shared constraints, the five briefs, and then ran the merge. One overlap was left in deliberately: every surface needed a position on the same last-reviewed signal.

Be upfront about the two honesty notes the article itself carries. The worker passes ran sequentially because the drafting environment could not spawn parallel workers, so the 46-minute parallel figure is an estimate of what the middle phase would compress to, not a measurement. And token figures are estimates, because per-pass accounting was not available; the published external figure for scale — Anthropic reporting multi-agent research systems at roughly fifteen times the tokens of a single chat — is a research-workload number quoted for context, not a design benchmark.

What the extra cost bought is the substance of the comparison. The baseline produced a perfectly usable combined spec faster, and decided the freshness rule implicitly along the way — but it surfaced no conflicts, graded its own work, thinned out state coverage on two surfaces, and left no record of rejected options. The orchestrated run produced two conflicts resolved on the record, an independent QA pass, two unowned gaps logged for a human, one worker revision caught at the gate, and a set of briefs reusable next time these surfaces change. Whether that is worth three to four times the tokens depends on how much the surfaces matter and how many people touch them next — which is exactly the Module 1 question, now with numbers attached.

The exercise is paper-only on purpose, like the Module 1 classification exercise it builds on. The expensive mistakes in orchestration are decomposition mistakes, and they are all visible before any agent runs: a boundary that cannot be stated in one sentence, an overlap nobody named, a merge rule that does not exist yet. Sketching the run costs twenty to thirty minutes; discovering the same problems mid-run costs the coordination tax plus the rework.

Steer participants towards tasks with real surface area — a multi-surface refresh, a system-wide audit, a canvas-to-code push — because small tasks make every pattern look unnecessary, which is the correct conclusion for small tasks. The most common gap to watch for in review: people write thorough worker briefs and skip the merge rules entirely, which is the written equivalent of merge by concatenation. The second most common: the orchestration brief quietly contains design direction, which means the author is planning to do the workers' jobs while pretending to delegate them.

If running this live, have people swap sketches and attack each other's boundaries — can you find a file, component, or decision two workers would both touch? That review takes ten minutes and reliably finds the racing-edit and divergent-assumption failures before they cost anything. The sketch carries forward: Module 3 takes one of these runs and wires real tools into it over MCP, and the boundaries drawn here become tool scopes there.

Recap by connecting the slides rather than re-reading them: the three patterns are arrangements of the same building blocks — bounded workers, written contracts, gates — and the comparison table turns the choice into a question about where the task's boundaries are. The orchestrator role and the worker brief are the human side of the system; the merge protocol and the failure-mode checklist are what keep the parallel work coherent; and the worked example is the honest accounting that stops anyone selling this as free speed.

If participants take one habit from the module, make it the order of writing: contract before briefs, briefs before any worker runs, gates before any output exists. Every failure in the checklist slide traces back to skipping one of those, and every artifact involved is a plain file that survives whichever orchestration product is fashionable this quarter.

Preview Module 3 concretely. So far the workers have been agents working on files. Real design runs need them to reach tools: a canvas server to read and write design files, a browser to capture screenshots, a ticketing system to file the follow-ups, analytics to ground decisions. MCP is how those tools join the run, and chaining them raises the same questions this module answered for workers — what each connection may see, what it may change, and what happens when one link in the chain fails. The boundaries drawn in this module's exercise become tool scopes there.