Part 1 · When and How

Multi-Agent Systems · ~9 min

The Orchestrator and Its Workers

The canonical multi-agent shape. One agent decomposes and synthesizes; the others run bounded subtasks in parallel and never talk to each other.

Why this, for you: orchestrator-worker is the pattern you'll reach for most. But the two halves that actually determine whether it pays off — decomposition at the front and synthesis at the back — are the two most people get wrong. The middle (parallel workers) is the easy part.

You may have met the bare shape already. Here we go deeper: the orchestrator's prompt is the highest-leverage component in the whole system, and synthesis is a reasoning step, not a concat().

1 Two roles, one coordination point

The pattern has exactly two roles, and a single channel between them:

Workers returning results to the orchestrator is the only coordination point. Any state sharing between workers during execution is a design smell — it creates coupling that undermines the parallelism you went multi-agent to get.

2 Decomposition: scale effort to complexity

The orchestrator should match worker count and tool allocation to task complexity. Anthropic's research system documents explicit effort-scaling rules — and these belong in the orchestrator's system prompt, not hard-coded in the harness:

QueryWorkersTooling
Simple1 agent3–10 tool calls
Moderate2–4 subagentsclearly divided responsibilities
Complex10+ subagentscarefully partitioned search spaces

Hard-coding a fixed agent count removes the flexibility to match scale to complexity — and over-spawning workers on simple queries is the most common failure of the pattern. The orchestrator needs the freedom to send one worker when one will do.

The orchestrator prompt is the highest-leverage component

Small changes to the orchestrator's prompt can unpredictably shift how subagents behave — its decomposition decisions determine which subtasks every worker receives. Test decomposition behavior explicitly across a range of input queries; one fragile orchestrator routes every worker to the wrong job at once.

3 Synthesis is reasoning, not concatenation

After workers complete, the orchestrator synthesizes. This is the half teams skip — and skipping it turns the pattern into pure latency tax. Synthesis is a reasoning step where the orchestrator:

If the orchestrator simply concatenates worker outputs, the pattern adds latency and token cost without improving quality. The reasoning at synthesis is what justifies the architecture.

And synthesis has a hard ceiling: the orchestrator must hold the task plus every worker's results. Beyond roughly 4+ substantive outputs this routinely overflows practical context budgets — so workers should return distilled findings, not raw transcripts. (More on that contract in Part 2.)

# Orchestrator system prompt — effort scaling lives HERE, not in code "You receive a list of repository paths. For each path, spawn a worker with tool access limited to that repo. Workers run in parallel. When all workers return, SYNTHESIZE into a ranked list by severity — resolve conflicts, do not concatenate raw findings."

↪ Your win: front and back, not just the middle

Retrieval practice — recall, don't peek

Question 1The only legitimate coordination point in the pattern is…

Question 2Effort-scaling rules (1 / 2–4 / 10+ workers) belong in the…

Question 3If the orchestrator merely concatenates worker outputs, it adds…

Question 4The highest-leverage component, where small changes cascade, is the…

Question 5 · spaced recall from Lesson 1You should climb to the multi-agent rung only when…

Ask me anything. Want a worked orchestrator prompt for a real decomposition of yours, or how to keep synthesis under the context ceiling? Next in Part 1: Fan-Out and Synthesis — N agents on the same problem, and how to merge them.
✎ Feedback