Multi-Agent Orchestration: Prompt Patterns That Scale

One agent can only hold so much in front of the model before it gets confused, expensive, or both. Split the work across several agents and a new problem appears: who decides what, who talks to whom, and how the pieces come back together. Multi-agent orchestration patterns are the rules that answer those questions, and the choice between them shapes cost, latency, and how often the whole thing wanders off.

The topologies are named everywhere. What's rarely shipped is the pasteable part: an orchestrator prompt that splits a goal into scoped subtasks with budgets and merges the results under a contract.

The three patterns, and which to start with

Three orchestration shapes cover most production systems, and they trade control for autonomy.

Orchestrator-worker is the workhorse, and it's where most deployments land. A single orchestrator receives the task, breaks it into subtasks, hands each to a worker, and aggregates the results. Workers don't talk to each other; all coordination flows through the orchestrator. Workers stay focused on one capability, which keeps each prompt small.

Supervisor or hierarchical adds levels. A coordinator dispatches to sub-coordinators that dispatch to workers. It buys oversight and scoped budgets per branch, at the cost of latency. A three-level hierarchy with a slow model call at each level can burn several seconds before any worker starts.

Swarm drops the central control entirely. Peer agents coordinate directly. It's flexible and hard to debug, because there's no single place the decision was made.

The hidden cost: coordination, not compute

The thing that surprises teams is latency. Every coordination hop is a model call. A supervisor that thinks for two seconds, dispatches, waits, and synthesizes adds real time before and after the work that matters. The strength of a hierarchy, scoped budgets and the ability to cancel a wandering sub-tree, is paid for in that coordination overhead.

This is why the orchestrator prompt should assign a budget per branch. A worker that's allowed unlimited tokens will happily consume them. A worker capped at a budget either finishes within it or reports back that it couldn't, which the orchestrator can act on. Scoped budgets turn "the agents are slow and expensive" into a number you control.

What you can do with an orchestrator prompt

• Split one goal into independent subtasks a coordinator can dispatch
• Give each worker a scoped tool set and a token budget it can't exceed
• Run independent subtasks in parallel instead of one long chain
• Cancel a branch that wanders without killing the whole run
• Merge worker outputs under a synthesis contract, not ad-hoc gluing
• Keep an audit trail of who was assigned what and why

Anatomy of the orchestration contract

The reusable piece is the orchestrator prompt. It assigns, then it synthesizes.

Variables → {{goal}}, {{available_workers}}, {{total_budget}}

Prompt → Split {{goal}} into independent subtasks.
         Assign each to a worker with a scoped budget and tools.
         After workers return, synthesize one result.

Output contract (locked):
  assignments: [ { subtask, worker, tool_scope, budget } ]
  parallel:    [ which assignments can run at once ]
  synthesis:   { how results merge, conflict_rule }

The parallel block is what earns the multi-agent cost: it tells the runtime which subtasks don't depend on each other and can run together. The conflict_rule in synthesis is the part people forget, and it's what decides what happens when two workers return contradictory results. Without it, the orchestrator picks one at random.

Where models differ

Orchestration leans hard on instruction-following, and models vary. Claude is reliable as an orchestrator: it keeps the assignment contract intact and respects per-branch budgets stated as rules. GPT-4o synthesizes well but tends to over-decompose, spawning more subtasks than the task needs, so cap the count in the prompt. Gemini is fast and good at the parallel-detection step but can blur the conflict_rule unless it's a clearly separate section. Name your orchestrator model and test the assignment contract before scaling out workers.

An opinionated take: most multi-agent systems should be one agent. Teams reach for orchestration because it sounds sophisticated, then spend their reliability budget on coordination bugs instead of the actual task. Add a second agent only when a subtask genuinely needs its own context or tool scope and can run in parallel. The Multi-Repo Change Orchestration Pack shows the disciplined version: a {{goal}} variable drives scoped assignments with per-branch budgets and a synthesis contract, built for the case where the parallelism is real.

Step-by-step: standing up an orchestrator

1. Confirm the task actually splits

If the subtasks are sequential and share context, you want one agent, not three. Multi-agent earns its cost only when parallelism is real.

2. Define the workers

Each worker gets one capability and a tool scope. A worker that can do everything is just the orchestrator again.

3. Set per-branch budgets

Cap each assignment in {{total_budget}} terms. A branch that overruns gets cancelled and reported, not allowed to run away.

4. Mark what's parallel

The orchestrator should declare which assignments are independent. That declaration is where the speedup comes from.

5. Write the conflict rule

Decide upfront what happens when workers disagree. Latest wins, highest-confidence wins, or escalate. Don't leave it to chance.

Variables you'll set

The failure mode of orchestration

The orchestrator's failure isn't usually a worker getting something wrong. It's the orchestrator decomposing badly: subtasks that overlap, dependencies it missed, or a synthesis that drops a worker's result. A bad split produces confident nonsense, because each worker did its job on the wrong slice. Guard it by making each subtask independently verifiable, the same discipline a single-agent planner needs, and by logging the assignments block so a bad split is visible after the fact. And pin your orchestrator's model version, since decomposition behavior shifts across updates more than most agent jobs.

The decomposition step underneath orchestration is the same job a single agent does for itself; see task decomposition prompt for coding agents. For the reasoning loop each worker runs inside its slice, see ReAct vs plan-and-execute agent prompts.

Getting started

1. Confirm the task splits into parallel subtasks.
2. Define each worker with one capability and a tool scope.
3. Set per-branch budgets in the assignment contract.
4. Mark which assignments run in parallel.
5. Write the conflict rule before the first run.
6. Log assignments and review bad splits.
7. Reach for the pack below when the orchestration is real.

When workers need to ground their work in a real codebase, see RAG for a codebase prompt patterns, and pair this with the Agent Task Decomposition System Prompt for the split step.