Orchestration Patterns

When a single agent isn’t enough — because the task is too large, requires parallel work, or needs specialized expertise — you need multi-agent orchestration.

Pattern Comparison

Our experiments compared three orchestration approaches:

Pattern	Token Efficiency	Quality	Context Purity	Best For
Single Agent	1x (baseline)	Degrades with complexity	Low	Simple, well-scoped tasks
Hierarchical	0.7x (30% savings)	High, consistent	High	Complex features, research-heavy work
Pipeline	0.5x (50% savings)	Highest	Highest	Large features, multi-phase work

Pattern 1: Single Agent (Baseline)

All phases run in a single context window that fills progressively.

Strengths: Simple, no coordination overhead, full context continuity.

Weaknesses: Context pollution from exploration, quality degrades on complex tasks, can’t parallelize.

Use when: Task is small, well-scoped, and touches fewer than 5 files.

Pattern 2: Hierarchical (Lead + Workers)

Strengths: Context isolation for exploration, lead agent maintains clean decision context, enables parallel research.

Weaknesses: Coordination overhead, some information loss in summaries.

Use when: Task requires significant research, spans multiple domains, or benefits from parallel investigation.

Implementation:

Phase 1 — Research (parallel sub-agents):
Use sub-agents to simultaneously research:
1. How the payment system processes orders
2. What webhook patterns exist in the codebase
3. How we handle idempotency in existing integrations

Phase 2 — Plan (lead agent):
Based on the research summaries, create a detailed plan
for adding PayPal webhook support.

Phase 3 — Implement (worktree agent):
Use the feature-implementer agent to execute the plan
in an isolated worktree.

Phase 4 — Review (review agent):
Use the reviewer agent to check the implementation
against the spec.

Pattern 3: Pipeline (Sequential Specialization)

Each agent starts with a fresh context — only the structured output from the previous stage is passed forward.

Strengths: Maximum context purity (each agent starts fresh), clear separation of concerns, highest quality for complex tasks.

Weaknesses: Information loss between stages, highest coordination overhead, no backtracking.

Use when: Large features, critical implementations where quality is paramount, tasks where context purity directly impacts output.

Implementation:

# Stage 1: Research (new session)
Research the payment integration landscape for our project.
Save comprehensive findings to .sdlc/research/payment-v2.md.

# Stage 2: Planning (new session)
Read .sdlc/research/payment-v2.md and create a detailed
implementation plan. Save to .sdlc/plans/payment-v2.md.

# Stage 3: Implementation (new session, worktree)
Follow .sdlc/plans/payment-v2.md step by step.
Use TDD for each step. Commit after each verified step.

# Stage 4: Review (new session)
Review the payment-v2 branch against the spec in
.sdlc/specs/payment-v2.md. Flag deviations.

Choosing a Pattern

Is the task simple and well-scoped?
├── Yes → Single Agent
└── No
    ├── Does it require significant research?
    │   ├── Yes → Hierarchical (parallel research)
    │   └── No → Single Agent with sub-agent review
    ├── Is quality critical (production, security)?
    │   └── Yes → Pipeline (maximum context purity)
    └── Does it span multiple independent components?
        └── Yes → Hierarchical with parallel worktrees

Tip

Start with the simplest pattern that might work. Escalate to more complex patterns only when the simpler one fails. Over-orchestration wastes more time than it saves.

Real-World Evidence

AgentOrchestra’s hierarchical framework consistently outperformed flat-agent architectures at 95.3% accuracy on complex benchmarks. However, for simple tasks, the single-agent baseline was faster and equally accurate.

The key insight: match orchestration complexity to task complexity.