🤖 AI Tools
· 3 min read
Last updated on

Agent Orchestration Patterns — Sequential, Parallel, and Hierarchical


When you move beyond a single AI agent, you need orchestration — deciding which agent does what, when, and how they communicate. Three patterns cover 90% of use cases.

Pattern 1: Sequential pipeline

Agent A → Agent B → Agent C → Output

Each agent processes the output of the previous one. The simplest pattern.

When to use

  • Content generation: research → draft → edit → publish
  • Data processing: extract → transform → validate → load
  • Code workflows: plan → implement → test → review

Implementation

async def sequential_pipeline(task):
    # Step 1: Research (cheap model)
    research = await call_agent("deepseek-chat", f"Research: {task}")
    
    # Step 2: Draft (medium model)
    draft = await call_agent("claude-sonnet-4.6", f"Write based on: {research}")
    
    # Step 3: Review (best model)
    final = await call_agent("claude-opus-4.6", f"Review and improve: {draft}")
    
    return final

Cost optimization: Use cheap models for early stages, expensive models only for the final step. See our model routing guide.

Pros and cons

✅ Simple to implement and debug ✅ Each step is independently testable ✅ Easy to add/remove steps ❌ Slow (each step waits for the previous) ❌ Errors cascade forward ❌ No parallelism

Pattern 2: Parallel fan-out

                → Agent B1 ─┐
Task → Agent A  → Agent B2 ─┤→ Agent C (merge)
                → Agent B3 ─┘

A coordinator splits work across parallel agents, then merges results.

When to use

  • Batch operations: refactor 50 files simultaneously
  • Multi-source research: search 5 databases in parallel
  • Testing: run tests across multiple environments
  • Kimi’s Agent Swarm uses this pattern

Implementation

import asyncio

async def parallel_fanout(files, instruction):
    # Fan out: process files in parallel
    tasks = [
        call_agent("claude-sonnet-4.6", f"{instruction}\n\nFile: {f}")
        for f in files
    ]
    results = await asyncio.gather(*tasks)
    
    # Merge: combine results
    merged = await call_agent("claude-opus-4.6", 
        f"Merge these changes, resolve conflicts:\n{results}")
    
    return merged

Pros and cons

✅ Fast (N agents work simultaneously) ✅ Scales linearly with parallelizable work ❌ Merge step can be complex ❌ Higher cost (N parallel API calls) ❌ Conflict resolution between agents

Pattern 3: Hierarchical delegation

Manager Agent
  ├── Specialist A (research tools)
  ├── Specialist B (coding tools)
  └── Specialist C (communication tools)

A manager agent decides which specialist to delegate to based on the task. Each specialist has its own MCP tools.

When to use

  • Complex workflows with different tool requirements
  • Customer support: route to billing, technical, or sales specialist
  • Development: route to frontend, backend, or DevOps agent

Implementation

async def hierarchical(task):
    # Manager decides who handles it
    routing = await call_agent("claude-sonnet-4.6", 
        f"Classify this task: {task}\nOptions: research, coding, communication")
    
    if "research" in routing:
        return await research_agent(task)  # Has web search MCP
    elif "coding" in routing:
        return await coding_agent(task)    # Has filesystem MCP
    else:
        return await comms_agent(task)     # Has email/Slack MCP

Pros and cons

✅ Each specialist is optimized for its domain ✅ Manager can use a cheap model, specialists use appropriate models ✅ Maps well to MCP (each specialist has its own tools) ❌ Manager can misroute tasks ❌ More complex to set up ❌ Manager is a single point of failure

Connecting to protocols

PatternMCPA2A
SequentialEach agent has its own MCP toolsNot needed (internal pipeline)
ParallelShared MCP tools with conflict resolutionNot needed (same system)
HierarchicalEach specialist has dedicated MCP toolsUseful for cross-vendor specialists

Managed background workflows versus delegation

Claude Managed Agents dynamic workflows are beta, using the managed-agents-2026-04-01 header and the agent’s multiagent.workflows setting. The agent writes a program that starts agents and combines results; the server runs it in the background using session threads. Follow workflow states, phase events and usage on the session event stream. Ordinary subagent delegation does not enable this engine, and a completed parent turn does not prove a background workflow has finished. Set budgets, permissions and monitoring explicitly.

Which pattern to start with

Start with sequential. It’s the simplest, easiest to debug, and handles most use cases. Only move to parallel when you have genuinely parallelizable work, and hierarchical when you need specialized tool access.

See our multi-agent guide for the full implementation guide and our tool calling patterns for how individual agents use tools.

Related: How to Build Multi-Agent Systems · Tool Calling Patterns · Kimi Agent Swarm · MCP Complete Guide

Infrastructure example: Google AX turns agent tasks, workspaces, network gateways and model configuration into Kubernetes-like resources. It is useful context for fleet orchestration, but the project is still pre-stable.