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)

┌───────────────────────────────┐
│         Single Agent          │
│                               │
│  Research → Plan → Implement  │
│  → Test → Review → Commit    │
│                               │
│  Context: ████████████████░░  │
│  (fills rapidly)              │
└───────────────────────────────┘

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)

┌──────────────────────────────────────┐
│          Lead Agent (Orchestrator)    │
│  Clean context: plan + decisions     │
│  Context: ████░░░░░░░░░░░░░░░░░░░░  │
├───────────┬───────────┬──────────────┤
│           │           │              │
│  ┌────────▼─────┐ ┌──▼──────────┐   │
│  │Research Agent│ │Research Agent│   │
│  │(sub-agent)   │ │(sub-agent)  │   │
│  │Explores auth │ │Explores API │   │
│  │Returns 800tk │ │Returns 600tk│   │
│  └──────────────┘ └─────────────┘   │
│           │                          │
│  ┌────────▼──────────────────────┐   │
│  │  Implementation Agent          │   │
│  │  (worktree isolation)          │   │
│  │  Clean context: plan + code    │   │
│  └────────────────────────────────┘   │
│           │                          │
│  ┌────────▼──────────────────────┐   │
│  │  Review Agent                  │   │
│  │  (separate context)            │   │
│  │  Unbiased code review          │   │
│  └────────────────────────────────┘   │
└──────────────────────────────────────┘

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)

┌─────────────┐    ┌─────────────┐    ┌─────────────┐    ┌─────────────┐
│  Agent 1     │    │  Agent 2     │    │  Agent 3     │    │  Agent 4     │
│  RESEARCH    │───▶│  PLANNING    │───▶│ IMPLEMENT    │───▶│  REVIEW      │
│              │    │              │    │              │    │              │
│ Input: task  │    │ Input:       │    │ Input:       │    │ Input:       │
│ Output: .md  │    │ research.md  │    │ plan.md      │    │ code diff    │
│              │    │ Output: .md  │    │ Output: code │    │ Output:      │
│ Context:     │    │ Context:     │    │ Context:     │    │ feedback     │
│ ████░░░░░░░  │    │ ███░░░░░░░  │    │ █████░░░░░  │    │ ███░░░░░░░  │
└─────────────┘    └─────────────┘    └─────────────┘    └─────────────┘
  Fresh context      Fresh context      Fresh context      Fresh context

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.