A virtuoso violinist can play a sonata. But a symphony? You need forty musicians — and above all a conductor: someone who plays no instrument, yet sets the tempo, cues the entrances, and turns forty talents into a single work.

This afternoon, we saw what one agent can do alone: loop until the goal. But what happens when the task is too big for a single agent — too long, too wide, too varied? You bring in several. And immediately, a question pops up: who coordinates? The answer is called agent orchestration. Take your seats — it’s not rocket science.

Why not one giant agent?

First legitimate objection: instead of ten agents, why not one agent ten times stronger? Three reasons, all met before in this series:

  • The desk overflows. An agent works inside a context window: auditing forty files, reading all the docs and keeping the thread doesn’t fit on one desk — and whatever overflows gets diluted.
  • The generalist spreads thin. An agent briefed “watch out for security, performance, style, tests and accessibility” skims everything. Five agents with one obsession each dig deep.
  • Time flies. Ten independent tasks run by one agent = ten times the time. By ten agents = the time of the slowest one.

You don’t get a symphony by asking the violinist to play louder. You get it by adding sections — and a conductor.

The conductor, precisely

Orchestration is the role that produces nothing itself but makes everyone else produce:

  1. decompose the score into sections (the big task into subtasks);
  2. distribute — the right agent, the right brief, the right slice of context;
  3. collect the results as they come in;
  4. synthesize — make it a work, not a pile.

A detail that matters: the conductor can be code (a script chaining the steps — reliable, predictable, testable) or an agent itself (dynamically deciding what to delegate — flexible, but fallible). Good systems mix both: determinism for the structure, judgment for the content.

The five patterns to know

1. The pipeline — the chain of sections

Each agent takes the previous one’s output: draft → proofread → fix → lay out. Dev flavor: write the code → generate the tests → run the review. Simple, readable — entry-level orchestration, and it already covers a lot.

2. The fan-out — all bows at once

A task that splits into independent pieces, distributed in parallel. The canonical example: multi-dimensional code review — a security agent, a performance agent, a readability agent read the same diff at the same time, each with its own obsession. Another classic: migrating forty files, forty workers, each with its own workbench.

3. Orchestrator-workers — the conductor improvising the score

Here, the split isn’t known in advance: a lead agent explores first (“what is this repo made of?”), draws up the list of work sites, then distributes to workers — and adjusts based on what comes back. It’s the pattern of audits and research: the score gets written while playing.

4. The handoff — the soloist stepping aside

An agent recognizes the next part isn’t for them and passes the whole file to a specialist: triage hands off to billing, billing to engineering. Key difference from the pipeline: nobody orchestrates from above — the handoff is decided in the flow, file in hand.

5. The judge panel — playing the same score twice

Several agents tackle the same question independently, then a judge compares, votes, decides. Expensive but precious when mistakes are costly: three agents hunt for bugs, and every finding goes to an adversarial verifier tasked with refuting it. What survives is solid — the principle of evals, applied live.

And concretely, with what?

You already own the instruments. Microsoft Agent Framework turns multi-agent workflows into C# code objects — pipelines, fan-outs, handoffs. Claude Code orchestrates parallel subagents from a session. And GitHub Copilot has its subagents — as it happens, we dissect them tomorrow morning in the CLI series. Today’s vocabulary is the reading grid for everything that follows.

A word of honesty

The orchestra costs more than the soloist — and not just in fees:

  • The bill is multiplied. Ten agents = ten contexts to fill, ten outputs to pay for in tokens. Comfort fan-out — parallelizing what one agent would do perfectly well alone — is the most common waste.
  • Coordination is the real problem. Two agents editing the same file, one worker contradicting another, a result arriving too late: everything software engineering knows about distributed systems applies — with wrong notes on top.
  • Debugging changes nature. When the symphony sounds off, which section do you blame? Without per-agent traces (who received what, who returned what), you’ll be debugging by ear.

The golden rule: start with one agent. Orchestrate when the task objectively overflows — the context, the clock, or the number of independent perspectives needed. A one-musician orchestra is a ridicule no demo forgives.

In short

Pattern The move When Example
Pipeline one after another dependent steps draft → proofread → publish
Fan-out all at once independent pieces multi-dimensional review
Orchestrator-workers explore then distribute split unknown upfront repo audit
Handoff the file changes hands successive skills triage → specialist
Judge panel same question, N answers mistakes are costly bugs + adversarial check
  • Orchestrating = decompose, distribute, collect, synthesize — the conductor doesn’t play, they make others play.
  • The conductor can be code (reliable structure) or an agent (flexibility) — good systems dose both.
  • Multiplying agents multiplies the bill and the coordination problems: one agent first, the orchestra when it overflows.
  • The five patterns cover the essentials — learn to recognize them: every current tool is a variation on them.

Tomorrow, double bill: in the morning, Copilot’s subagents — orchestration seen from inside a tool. And in the afternoon, we connect this week’s two worlds: what happens when the score becomes a graph? Hint: everything you read today fits into nodes and arrows. And that, honestly… is not rocket science.