Agent Orchestration Patterns

"Single agent is the default. Multi-agent is an upgrade you earn when the task demands it."

Adding agents adds overhead. Use the simplest orchestration that produces the quality you need.

When one agent is enough

Most tasks do not need multi-agent orchestration. Simple, well-scoped tasks (classification, commit message generation, small patches under 200 lines, single-file changes) work fine with a single agent. Rule of thumb: if the task fits in one context window with room to spare, one agent is enough.

1x

simpler orchestration

$

lower cost per task

Fast

no coordination overhead

When you need multiple agents

Multi-agent orchestration earns its overhead when the task exceeds what one agent can handle well. Watch for these signals:

Signal The task requires more context than one window can hold
Signal The task crosses multiple domains (backend + frontend + infra)
Signal Quality matters enough to justify cross-validation
Signal Research phase produces too much information for one agent to synthesize

Multi-agent adds overhead: coordination cost, potential for conflicting outputs, harder debugging. Use it when the quality or capability gain justifies the complexity.

Three types of parallelism

Parallelism in agentic workflows operates at three distinct levels. Conflating them leads to over-engineering at one level and missing opportunities at another.

Instance-level parallelism

Multiple workflow runs execute simultaneously on different tasks. Each gets its own isolated environment (worktree, ports, state). This is the highest-leverage parallelism; it multiplies throughput without changing workflow complexity.

Instance-level parallelism is an infrastructure concern, not an agent concern. It requires isolation mechanisms (git worktrees, containers, port allocation) but no changes to prompt templates or phase logic.

Phase-level parallelism

Multiple phases run concurrently within a single workflow. For example, running Document and Deploy in parallel after Review completes.

Phase-level parallelism is rarely useful because most phases have sequential dependencies (Build depends on Plan, Test depends on Build). The only common case is Document and Deploy running in parallel, since Document's output doesn't affect the PR.

Agent-level parallelism

Multiple agents (or subagents) work simultaneously within a single phase. For example, three research subagents investigating different parts of the codebase during Plan, or backend/frontend/test specialist reviewers running in parallel during Review.

Agent-level parallelism is handled by the agent runtime, not the workflow engine. Modern agent runtimes support spawning parallel subagents natively. The prompt template triggers this by instructing the agent to delegate work.

Which level matters most?

For most teams: instance-level (run more workflows concurrently) delivers the most throughput gain with the least complexity. Agent-level parallelism is second, since it's free when your agent runtime supports it. Phase-level parallelism is last because the dependency chain between phases limits the opportunity.

The four orchestration patterns

Pattern 1

Sequential handoff

An assembly line. Agent A produces output. Agent B takes that output and validates, refines, or extends it. A linear chain where each step adds quality.

Pros

Simple to implement and debug
Clear accountability per step
Easy to reason about data flow

Cons

No parallelism; bottleneck at slowest agent
Single point of failure per step

Used by: Plan (planner + validator), Build (builder + self-reviewer)

Pattern 2

Parallel fan-out / merge

Multiple inspectors checking a car at the same time: one checks the engine, another the brakes, another the electronics. A coordinator merges their reports. Multiple agents work on the same task (or sub-parts) in parallel, then a merge step synthesizes results.

Pros

Faster for independent subtasks
Diverse perspectives on the same problem
Scales well horizontally

Cons

Merge step is hard (conflicts, redundancy)
Coordinator needs strong instructions

Used by: Review (parallel specialist reviewers), Plan (parallel research agents)

Pattern 3

Hierarchical delegation

A general directing lieutenants. A lead agent decomposes the task and dispatches subtasks to worker agents. Workers report back. The lead synthesizes their outputs into a unified result. This protects the lead agent's context window: workers hold subtask context, the lead holds only summaries.

Pros

Scales to complex, decomposable tasks
Protects lead agent's context window
Workers can be specialized

Cons

Lead must decompose well
Communication overhead between levels
Workers may produce inconsistent outputs

Used by: Build (for large features), Review (main reviewer delegates)

Pattern 4

Adversarial / debate

A courtroom debate. Two agents argue opposing positions or propose competing solutions. A judge agent evaluates and decides. This surfaces hidden risks and reduces confirmation bias. Expensive, but valuable for high-stakes decisions.

Pros

Surfaces hidden risks and edge cases
Reduces confirmation bias
Produces more thorough analysis

Cons

Expensive (3+ agents minimum)
Slower than other patterns
Judge must be well-calibrated

Used by: Plan (major architecture decisions), Review (controversial trade-offs)

Decision Tree: Which Pattern Do I Use?

Click any question to follow the path to a recommendation.

Context window protection

Every agent has a finite context window. In practice, performance tends to degrade as context utilization increases. The agent starts missing details, contradicting itself, losing track of the task. As a guideline, consider delegating to subagents when context exceeds roughly 40% of the model's window. The exact threshold varies by model and task complexity, so monitor output quality and adjust based on your observations. This is why subagent delegation matters.

Context Window Usage

0% 40%: delegate beyond this 100%

The main agent holds the high-level plan and summaries. Worker agents hold only their subtask context. Hierarchical delegation is not just about parallelism. It keeps each agent focused and within its effective capacity. When your workflow artifacts grow large, delegation stops being optional. It becomes a requirement for quality.

Phase-to-pattern mapping

Each workflow phase has a natural fit with one or two orchestration patterns. These are defaults. Your task complexity determines the actual choice.

Phase	Pattern	Why
Plan	Sequential or Adversarial	Planner + validator, or competing approaches for complex features
Build	Hierarchical Delegation	Lead architect + specialist builders for large diffs
Test	Single or Sequential	One agent runs tests; handoff to fixer on failure
Review	Parallel Fan-Out	Security, performance, style reviewers in parallel
Document	Single Agent	Usually simple enough for one agent
Deploy	Single Agent	Mechanical: commits, PR creation
Monitor	Single Agent	Metric collection and threshold checking

Example: Hierarchical Delegation in a Build Prompt

# Build Phase -- Lead Architect

## Role
You are the Lead Software Engineer. You will decompose
the implementation plan into subtasks and delegate each
to a specialist builder agent.

## Subtask Delegation
For each subtask:
1. Create a focused brief (context, files, acceptance criteria)
2. Spawn a subagent with the brief
3. Collect the subagent's output
4. Validate consistency across all subtask outputs
5. Merge into a unified changeset

## Constraints
- Each subagent gets ONLY the files relevant to its subtask
- Never pass the full plan to a subagent -- summarize
- If a subagent's output conflicts with another, YOU resolve it

Related concepts

Self-Healing Loops

loops use sequential handoff between test and build agents

Tool Permission Design

each agent in a pattern inherits its phase's permissions

The Agentic Layer

orchestration patterns are configured in the layer

Artifact Chaining

how artifacts flow between agents in multi-agent patterns

The Agentic Layer Self-Healing Loops