Multi-Agent Orchestration Patterns: Supervisor, Router, Pipeline & Swarm Architecture

Building a multi-agent system is not the hard part. Orchestrating it so agents coordinate without deadlocks, redundant LLM calls, or cascading failures — that is the engineering challenge that separates demos from production systems.

Most teams start with a single agent, hit a complexity wall, add a second agent, and immediately discover that the orchestration layer is the real product. How do agents communicate? Who decides what runs next? What happens when one agent fails? How do you trace a decision chain across four agents to find why the output was wrong?

There are four dominant orchestration patterns in production multi-agent systems in 2026: Supervisor, Router, Pipeline, and Swarm. Each one encodes a different assumption about control flow, fault tolerance, and agent autonomy. Choosing the wrong pattern does not just add complexity — it creates architectural debt that compounds with every new agent you add.

This guide is a technical deep-dive. It covers the architecture, code, performance characteristics, and failure modes of each pattern. Every example is drawn from Groovy Web's experience building 50+ production agent systems across industries. If you have already read our guide to building multi-agent systems with LangChain or our CrewAI vs LangGraph vs AutoGen framework comparison, this post goes one level deeper — from "which framework" to "which orchestration topology."

The Four Orchestration Patterns at a Glance

Before diving into each pattern, here is the mental model. These four patterns sit on a spectrum from centralised control (Supervisor) to fully decentralised autonomy (Swarm). The right choice depends on how predictable your workflow is, how many agents you need, and how much failure tolerance you require.

Control Spectrum:

  Centralised                                              Decentralised
  |-----------|-----------|-----------|-----------|
  Supervisor    Router      Pipeline      Swarm

  One boss      Classifier   Chain of      Autonomous
  delegates     routes to    transforms    agents with
  all work      specialist   (A -> B -> C) shared memory

Supervisor — A single controller agent decides which specialist agent to invoke next. Think of a project manager assigning tasks to team members.

Router — An intent classifier examines the input and routes it to the single most appropriate agent. Think of a switchboard operator connecting your call.

Pipeline — Agents run in a fixed sequence where each agent transforms the output of the previous one. Think of a manufacturing assembly line.

Swarm — Agents operate autonomously, share a common memory store, and claim tasks dynamically based on their capabilities. Think of a swarm of drones coordinating via shared telemetry.

Pattern 1: Supervisor — Central Controller Delegation

The Supervisor pattern places a single orchestrator agent at the centre. This agent receives the user request, decides which specialist agent should handle it (or which sequence of agents), dispatches the work, collects results, and decides whether to route to another agent or return the final output.

Architecture

                    +------------------+
                    |    Supervisor    |
                    |  (LLM-powered)  |
                    +--------+---------+
                             |
              +--------------+--------------+
              |              |              |
     +--------v---+  +------v-----+  +-----v------+
     | Researcher |  |   Writer   |  |  Reviewer  |
     |   Agent    |  |   Agent    |  |   Agent    |
     +------------+  +------------+  +------------+
              |              |              |
              +--------------+--------------+
                             |
                    +--------v---------+
                    |   Shared State   |
                    +------------------+

The Supervisor makes routing decisions using an LLM call. This means it can handle ambiguous requests — "research this topic and then write a blog post" — by decomposing them into steps and assigning each step to the right specialist.

LangGraph Implementation

from langgraph.graph import StateGraph, MessagesState, START, END
from langgraph.prebuilt import create_react_agent
from langchain_openai import ChatOpenAI
from langchain_core.messages import HumanMessage
from typing import Literal

llm = ChatOpenAI(model="gpt-4o", temperature=0)

# Define specialist agents
researcher = create_react_agent(
    llm, tools=[web_search, arxiv_search],
    state_modifier="You are a research specialist. Find accurate, cited information."
)
writer = create_react_agent(
    llm, tools=[grammar_check, readability_score],
    state_modifier="You are a technical writer. Produce clear, structured prose."
)
reviewer = create_react_agent(
    llm, tools=[fact_checker, plagiarism_detector],
    state_modifier="You are a quality reviewer. Verify accuracy and originality."
)

# Supervisor routing function
def supervisor_router(state: MessagesState) -> Literal["researcher", "writer", "reviewer", "__end__"]:
    response = llm.invoke([
        {"role": "system", "content": """You are a supervisor managing a research team.
        Based on the conversation state, decide who should act next:
        - researcher: needs information gathering
        - writer: needs content creation
        - reviewer: needs quality check
        - __end__: task is complete
        Respond with ONLY the agent name."""},
        *state["messages"]
    ])
    return response.content.strip().lower()

# Build the supervisor graph
graph = StateGraph(MessagesState)
graph.add_node("researcher", researcher)
graph.add_node("writer", writer)
graph.add_node("reviewer", reviewer)
graph.add_conditional_edges(START, supervisor_router)
graph.add_conditional_edges("researcher", supervisor_router)
graph.add_conditional_edges("writer", supervisor_router)
graph.add_conditional_edges("reviewer", supervisor_router)

supervisor = graph.compile()

# Execute
result = supervisor.invoke({
    "messages": [HumanMessage("Write a technical analysis of vector database indexing strategies")]
})

Performance Characteristics

Latency: Every routing decision requires an LLM call (150-800ms depending on model). A 4-step task with a supervisor adds 600-3,200ms of pure routing overhead. In production systems we have measured, the supervisor's routing calls account for 15-30% of total execution time.

Cost: Routing calls are cheap individually ($0.001-$0.01 each) but add up. A system handling 10,000 daily requests with an average of 3 routing decisions per request generates 30,000 additional LLM calls per day — roughly $30-$300/day in routing costs alone.

Throughput: The supervisor is a bottleneck. All work funnels through a single decision point. Under load, the supervisor becomes the queue. Systems we have built typically max out at 50-80 concurrent requests before supervisor latency degrades.

Failure Modes

• Routing loops: The supervisor sends work to Agent A, which returns output, and the supervisor routes it back to Agent A. Without a loop counter or visited-set, this runs forever. Always implement a max_iterations guard.
• Ambiguous delegation: The supervisor cannot decide between two agents and alternates between them. Fix this with explicit routing rules in the system prompt and a tie-breaking default.
• Single point of failure: If the supervisor's LLM call fails or times out, the entire pipeline stalls. Wrap the routing function in retry logic with exponential backoff.

Pattern 2: Router — Intent Classification Dispatch

The Router pattern uses a classifier — either an LLM or a lightweight ML model — to examine the incoming request and dispatch it to exactly one specialist agent. Unlike the Supervisor, the Router makes a single routing decision and does not re-route after the specialist responds. It is a one-hop dispatch.

Architecture

            +------------------+
            |   User Request   |
            +--------+---------+
                     |
            +--------v---------+
            |     Router       |
            | (Classifier LLM  |
            |  or ML model)    |
            +--------+---------+
                     |
     +---------------+---------------+
     |               |               |
+----v----+    +-----v-----+   +-----v-----+
| Billing |    | Technical |   |   Sales   |
|  Agent  |    |  Support  |   |   Agent   |
+---------+    +-----------+   +-----------+

The Router pattern is the most common orchestration topology in customer-facing applications. Every AI chatbot that handles "billing", "technical support", and "sales" queries uses some form of Router — even if the team does not call it that.

CrewAI Implementation

from crewai import Agent, Task, Crew
from langchain_openai import ChatOpenAI

llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# Define specialist agents
billing_agent = Agent(
    role="Billing Specialist",
    goal="Resolve billing inquiries accurately and empathetically",
    backstory="Expert in subscription management, invoicing, and payment processing.",
    llm=llm,
    tools=[billing_api, invoice_lookup, refund_processor],
    verbose=False
)

tech_support_agent = Agent(
    role="Technical Support Engineer",
    goal="Diagnose and resolve technical issues efficiently",
    backstory="Senior engineer with deep product knowledge and debugging expertise.",
    llm=llm,
    tools=[log_search, config_checker, knowledge_base],
    verbose=False
)

sales_agent = Agent(
    role="Sales Consultant",
    goal="Convert inquiries into qualified opportunities",
    backstory="Solution seller who maps prospect pain to product capabilities.",
    llm=llm,
    tools=[crm_lookup, pricing_engine, calendar_booking],
    verbose=False
)

# Router function — classify and dispatch
def route_request(user_message: str) -> dict:
    classification = llm.invoke([
        {"role": "system", "content": """Classify this customer message into exactly one category:
        - billing: payment, invoice, subscription, refund, charge
        - technical: bug, error, not working, setup, integration
        - sales: pricing, demo, features, comparison, upgrade
        Respond with ONLY the category name."""},
        {"role": "user", "content": user_message}
    ])

    category = classification.content.strip().lower()

    agent_map = {
        "billing": billing_agent,
        "technical": tech_support_agent,
        "sales": sales_agent
    }

    selected_agent = agent_map.get(category, tech_support_agent)

    task = Task(
        description=f"Handle this customer request: {user_message}",
        expected_output="A complete, actionable response to the customer",
        agent=selected_agent
    )

    crew = Crew(agents=[selected_agent], tasks=[task], verbose=False)
    result = crew.kickoff()
    return {"category": category, "response": result.raw}

# Execute
response = route_request("I was charged twice for my March subscription")

Performance Characteristics

Latency: One classification call (100-400ms with gpt-4o-mini) plus one specialist execution. Total latency is typically 1.5-4 seconds for the complete request — significantly faster than the Supervisor pattern because there is no iterative routing loop.

Cost: The classification call uses a small, fast model (gpt-4o-mini at $0.15/1M input tokens). At 10,000 daily requests, routing costs roughly $1.50-$5.00/day. The specialist calls dominate cost.

Throughput: No bottleneck — each request is independent. Router systems we have deployed handle 500+ concurrent requests with horizontal scaling of the specialist agents.

Classification accuracy: In production systems with well-defined categories, LLM-based routers achieve 94-97% classification accuracy. For systems where misrouting is expensive, add a confidence threshold — if the classifier is below 80% confident, route to a general-purpose agent or escalate to a human.

Failure Modes

• Misclassification: "I want to cancel my subscription" could be billing (cancel the payment) or sales (retention opportunity). Ambiguous inputs need a fallback strategy — either a general agent or a two-stage classifier that asks a clarifying question.
• Category drift: As your product evolves, new query types emerge that do not fit existing categories. Monitor unclassified or low-confidence queries weekly and add new specialist agents when a pattern emerges.
• No re-routing: If the specialist agent cannot handle the request, the Router does not know. Add a "hand-back" mechanism where the specialist can signal the router to try a different agent.

Pattern 3: Pipeline — Sequential Transformation Chain

The Pipeline pattern connects agents in a fixed sequence. Agent A processes the input and passes its output to Agent B, which processes it and passes to Agent C. Each agent performs a specific transformation — extraction, enrichment, formatting, validation — and the final output is the cumulative result of all transformations.

Architecture

+-------+     +----------+     +-----------+     +----------+     +--------+
| Input | --> | Extract  | --> |  Enrich   | --> |  Format  | --> | Output |
|       |     |  Agent   |     |   Agent   |     |  Agent   |     |        |
+-------+     +----------+     +-----------+     +----------+     +--------+
                  |                  |                  |
                  v                  v                  v
              Structured         Augmented          Final
              Data               Data               Document

Pipelines are the workhorse of data processing systems. They are simple to reason about, easy to test (each stage has a defined input/output contract), and naturally parallelisable when stages do not depend on each other.

Python Implementation

from dataclasses import dataclass, field
from typing import Any
from langchain_openai import ChatOpenAI
import json
import time

llm = ChatOpenAI(model="gpt-4o", temperature=0)

@dataclass
class PipelineState:
    raw_input: str
    extracted: dict = field(default_factory=dict)
    enriched: dict = field(default_factory=dict)
    formatted: str = ""
    validated: bool = False
    errors: list = field(default_factory=list)
    stage_timings: dict = field(default_factory=dict)

class PipelineAgent:
    def __init__(self, name: str, system_prompt: str, tools: list = None):
        self.name = name
        self.system_prompt = system_prompt
        self.tools = tools or []

    def execute(self, state: PipelineState) -> PipelineState:
        start = time.time()
        try:
            result = self._process(state)
            state.stage_timings[self.name] = round(time.time() - start, 3)
            return result
        except Exception as e:
            state.errors.append({"stage": self.name, "error": str(e)})
            state.stage_timings[self.name] = round(time.time() - start, 3)
            return state

    def _process(self, state: PipelineState) -> PipelineState:
        raise NotImplementedError

class ExtractAgent(PipelineAgent):
    def _process(self, state: PipelineState) -> PipelineState:
        response = llm.invoke([
            {"role": "system", "content": self.system_prompt},
            {"role": "user", "content": f"Extract structured data from: {state.raw_input}"}
        ])
        state.extracted = json.loads(response.content)
        return state

class EnrichAgent(PipelineAgent):
    def _process(self, state: PipelineState) -> PipelineState:
        response = llm.invoke([
            {"role": "system", "content": self.system_prompt},
            {"role": "user", "content": f"Enrich this data: {json.dumps(state.extracted)}"}
        ])
        state.enriched = json.loads(response.content)
        return state

class FormatAgent(PipelineAgent):
    def _process(self, state: PipelineState) -> PipelineState:
        response = llm.invoke([
            {"role": "system", "content": self.system_prompt},
            {"role": "user", "content": f"Format into final document: {json.dumps(state.enriched)}"}
        ])
        state.formatted = response.content
        return state

class ValidateAgent(PipelineAgent):
    def _process(self, state: PipelineState) -> PipelineState:
        response = llm.invoke([
            {"role": "system", "content": self.system_prompt},
            {"role": "user", "content": f"Validate this output: {state.formatted}"}
        ])
        state.validated = "PASS" in response.content.upper()
        return state

# Build and execute pipeline
pipeline = [
    ExtractAgent("extract", "Extract entities, dates, amounts from raw text. Return JSON."),
    EnrichAgent("enrich", "Add industry context, company data, risk scores. Return JSON."),
    FormatAgent("format", "Create a structured executive summary from the enriched data."),
    ValidateAgent("validate", "Check for factual consistency and completeness. Reply PASS or FAIL with reasons.")
]

state = PipelineState(raw_input="Acme Corp signed a $2.4M contract for AI integration...")

for agent in pipeline:
    state = agent.execute(state)
    if state.errors:
        print(f"Pipeline failed at stage: {state.errors[-1]['stage']}")
        break

print(f"Stage timings: {state.stage_timings}")
print(f"Validated: {state.validated}")

Performance Characteristics

Latency: The sum of all stage latencies. A 4-stage pipeline with 1-2 second stages runs in 4-8 seconds total. This is the main trade-off — pipelines are inherently sequential unless you introduce parallel branches.

Cost: Predictable and linear. Each stage makes exactly one LLM call (or a fixed number of tool calls). A 4-stage pipeline on gpt-4o costs roughly $0.02-$0.08 per execution depending on input/output size.

Throughput: Individual pipelines are sequential, but multiple pipeline instances can run in parallel. Production systems we have built process 200-500 documents per hour with 10 parallel pipeline workers.

Testability: The strongest advantage of pipelines. Each stage has a defined input schema and output schema. You can unit test every stage independently and integration test the full chain. Our teams achieve 95%+ test coverage on pipeline agents — far higher than any other pattern.

Failure Modes

• Cascading failures: If Stage 2 produces malformed output, Stage 3 fails, Stage 4 fails, and debugging starts at the end rather than the source. Validate output schemas between stages.
• Bottleneck stages: One slow stage throttles the entire pipeline. Profile each stage independently and cache or pre-compute where possible.
• Data loss between stages: Passing data through LLM calls means information can be dropped or hallucinated. Use structured outputs (JSON mode) and validate completeness at each handoff.

Pattern 4: Swarm — Autonomous Agents with Shared Memory

The Swarm pattern gives each agent autonomy to claim tasks, execute them, and write results back to a shared memory store. There is no central controller. Agents coordinate through the shared state — reading what other agents have done and deciding what to do next based on what remains.

Architecture

     +----------+    +----------+    +----------+
     |  Agent A |    |  Agent B |    |  Agent C |
     | (Search) |    | (Analyze)|    | (Report) |
     +----+-----+    +----+-----+    +----+-----+
          |               |               |
          +-------+-------+-------+-------+
                  |               |
          +-------v---------------v-------+
          |        Shared Memory          |
          |  (Task Queue + Result Store)  |
          |  - pending tasks              |
          |  - claimed tasks              |
          |  - completed results          |
          |  - agent capabilities         |
          +-------------------------------+

The Swarm is the most complex pattern and the most powerful. It can handle workloads that are unpredictable in size (agents scale dynamically), partially ordered (some tasks depend on others), and heterogeneous (different task types require different capabilities). OpenAI's experimental Swarm framework and Anthropic's multi-agent research both use variants of this topology.

Python Implementation (OpenAI Swarm-Style)

from dataclasses import dataclass, field
from typing import Callable, Optional
from langchain_openai import ChatOpenAI
import json
import uuid
import time

llm = ChatOpenAI(model="gpt-4o", temperature=0)

@dataclass
class Task:
    id: str
    type: str
    payload: dict
    status: str = "pending"  # pending, claimed, done, failed
    result: Optional[dict] = None
    claimed_by: Optional[str] = None
    depends_on: list = field(default_factory=list)
    created_at: float = field(default_factory=time.time)

class SharedMemory:
    def __init__(self):
        self.tasks: dict[str, Task] = {}
        self.results: dict[str, dict] = {}
        self.agent_registry: dict[str, list[str]] = {}

    def add_task(self, task_type: str, payload: dict, depends_on: list = None) -> str:
        task_id = f"task-{uuid.uuid4().hex[:8]}"
        self.tasks[task_id] = Task(
            id=task_id, type=task_type,
            payload=payload, depends_on=depends_on or []
        )
        return task_id

    def claim_task(self, agent_id: str, capabilities: list[str]) -> Optional[Task]:
        for task in self.tasks.values():
            if task.status != "pending":
                continue
            if task.type not in capabilities:
                continue
            # Check dependencies are complete
            deps_met = all(
                self.tasks[dep].status == "done"
                for dep in task.depends_on
                if dep in self.tasks
            )
            if not deps_met:
                continue
            task.status = "claimed"
            task.claimed_by = agent_id
            return task
        return None

    def complete_task(self, task_id: str, result: dict):
        self.tasks[task_id].status = "done"
        self.tasks[task_id].result = result
        self.results[task_id] = result

    def fail_task(self, task_id: str, error: str):
        self.tasks[task_id].status = "failed"
        self.tasks[task_id].result = {"error": error}

    def get_dependency_results(self, task: Task) -> dict:
        return {
            dep: self.results.get(dep, {})
            for dep in task.depends_on
        }

    def all_done(self) -> bool:
        return all(t.status in ("done", "failed") for t in self.tasks.values())

class SwarmAgent:
    def __init__(self, agent_id: str, capabilities: list[str], system_prompt: str):
        self.agent_id = agent_id
        self.capabilities = capabilities
        self.system_prompt = system_prompt
        self.tasks_completed = 0

    def run_loop(self, memory: SharedMemory, max_idle: int = 3):
        idle_count = 0
        while idle_count < max_idle:
            task = memory.claim_task(self.agent_id, self.capabilities)
            if task is None:
                if memory.all_done():
                    break
                idle_count += 1
                time.sleep(0.5)
                continue

            idle_count = 0
            dep_results = memory.get_dependency_results(task)

            try:
                result = self.execute(task, dep_results)
                memory.complete_task(task.id, result)
                self.tasks_completed += 1
            except Exception as e:
                memory.fail_task(task.id, str(e))

    def execute(self, task: Task, dep_results: dict) -> dict:
        context = json.dumps({
            "task_type": task.type,
            "payload": task.payload,
            "dependency_results": dep_results
        })
        response = llm.invoke([
            {"role": "system", "content": self.system_prompt},
            {"role": "user", "content": f"Execute this task: {context}"}
        ])
        return {"output": response.content, "agent": self.agent_id}

# Initialize shared memory and seed tasks
memory = SharedMemory()
t1 = memory.add_task("search", {"query": "vector database benchmarks 2026"})
t2 = memory.add_task("search", {"query": "embedding model comparison MTEB"})
t3 = memory.add_task("analyze", {"focus": "performance vs cost"}, depends_on=[t1, t2])
t4 = memory.add_task("report", {"format": "executive summary"}, depends_on=[t3])

# Create swarm agents
agents = [
    SwarmAgent("search-1", ["search"], "You are a web researcher. Return factual data with sources."),
    SwarmAgent("search-2", ["search"], "You are a web researcher. Return factual data with sources."),
    SwarmAgent("analyst-1", ["analyze"], "You are a data analyst. Synthesize findings into insights."),
    SwarmAgent("reporter-1", ["report", "analyze"], "You are a report writer. Create clear executive summaries."),
]

# Run swarm (in production, each agent runs in its own thread/process)
import threading
threads = [threading.Thread(target=a.run_loop, args=(memory,)) for a in agents]
for t in threads:
    t.start()
for t in threads:
    t.join()

# Collect results
for task_id, result in memory.results.items():
    print(f"{task_id}: {result['agent']} -> {result['output'][:100]}")

Performance Characteristics

Latency: Depends on the critical path through the task dependency graph. Independent tasks run in parallel. The 4-task example above completes in ~3 seconds (two parallel searches + one analysis + one report) versus 8+ seconds if run sequentially.

Cost: Higher variance than other patterns. Agents may claim tasks they are not optimal for, and retry/requeue logic adds overhead. Production swarms we have measured cost 20-40% more per task than equivalent pipelines — the trade-off for dynamic scaling and fault tolerance.

Throughput: Swarms scale horizontally by adding more agents. In one production deployment, we scaled from 4 agents to 16 agents to handle a 10X traffic spike with no architectural changes — just more agent instances reading from the same task queue.

Fault tolerance: If an agent crashes, its claimed task times out and is requeued for another agent. No single point of failure. This is the primary advantage over the Supervisor pattern.

Failure Modes

• Task starvation: If all agents are busy with long-running tasks, new tasks queue indefinitely. Set maximum task age and alert when tasks exceed it.
• Duplicate work: Two agents claim the same task due to a race condition. Use atomic claim operations (database transactions or Redis SETNX).
• Memory bloat: Shared memory grows unbounded as tasks accumulate. Implement TTL-based cleanup for completed tasks.
• Dependency deadlocks: Task A depends on Task B, and Task B depends on Task A. Validate the dependency graph for cycles before adding tasks.

Head-to-Head Comparison: 4 Patterns Across 10 Dimensions

This table compresses the architectural trade-offs into a single reference. Use it as a decision matrix — score each dimension by how important it is for your system, then see which pattern wins.

Decision Framework: Choosing the Right Pattern

Do not choose an orchestration pattern because it is interesting. Choose it because your workflow's constraints make it the only sensible option. Here is the decision framework we use at Groovy Web when architecting multi-agent systems for clients.

Choose Supervisor if:
- Your workflow requires dynamic multi-step reasoning where the next step depends on intermediate results
- You need a single agent to decompose ambiguous requests into subtasks
- The workflow has fewer than 5 specialist agents and latency under 15 seconds is acceptable
- You want a natural observability root — the supervisor's decision log is your trace
- Examples: research pipelines, multi-source analysis, automated content creation

Choose Router if:
- Incoming requests can be cleanly classified into 3-10 distinct categories
- Each category is handled by exactly one specialist agent with no cross-agent dependencies
- You need the lowest possible latency — one classification call plus one execution
- High throughput matters — hundreds or thousands of concurrent requests
- Examples: customer support chatbots, help desk automation, multi-channel query handling

Choose Pipeline if:
- Your workflow is a fixed sequence of transformations (extract, enrich, format, validate)
- Each stage has a well-defined input schema and output schema
- Testability is a priority — you need unit tests on every stage and integration tests on the chain
- You are processing documents, data records, or any workload with a predictable shape
- Examples: invoice processing, contract analysis, data ETL, report generation

Choose Swarm if:
- The workload is unpredictable in size — some requests spawn 3 tasks, others spawn 30
- You need horizontal scaling — add agents to handle traffic spikes without redesigning
- Fault tolerance is critical — no single agent failure should stop the system
- Tasks have complex dependency graphs with parallelisable branches
- Your team has distributed systems experience (message queues, concurrency, state machines)
- Examples: large-scale web research, autonomous monitoring, multi-source data aggregation

Anti-Patterns: Orchestration Mistakes That Compound

The wrong orchestration choice does not just slow you down — it creates technical debt that grows with every agent you add. These are the mistakes we see most often when teams build multi-agent systems without understanding the pattern trade-offs.

Using a Supervisor When a Router Would Suffice

The most common over-engineering mistake. If your incoming requests can be classified into distinct categories and each category maps to one agent, you do not need a Supervisor. You are paying for iterative LLM routing calls (3-5 per request) when a single classification call would do. We have seen teams reduce latency by 60-70% and cost by 40-50% by replacing an unnecessary Supervisor with a Router.

Building a Pipeline When Stages Have Conditional Logic

Pipelines assume a fixed sequence. If Stage 2 sometimes needs to skip Stage 3 and jump to Stage 4, you do not have a pipeline — you have a state machine. Forcing conditional logic into a linear pipeline produces spaghetti code with if/else blocks inside stages that should be routing decisions. Switch to a Supervisor or refactor into a LangGraph state graph.

Choosing Swarm Because It Sounds Impressive

Swarm is the most complex pattern with the highest operational overhead. It requires distributed state management, atomic task claiming, dependency resolution, and dead-agent detection. If your workflow has fewer than 10 agents and a predictable task graph, a Supervisor or Pipeline will be simpler, cheaper, and easier to debug. We estimate that 80% of production agent systems should use Supervisor, Router, or Pipeline. Swarm is for the remaining 20% where dynamic scaling and fault tolerance are genuine requirements.

No Inter-Pattern Composition

These patterns are not mutually exclusive. The most effective production systems we have built combine them. A common architecture uses a Router at the entry point to classify requests, a Pipeline inside each specialist branch for multi-step processing, and a Supervisor for the one branch that handles complex, ambiguous queries. This composition gives you the speed of Router, the testability of Pipeline, and the flexibility of Supervisor — each where it adds the most value.

Skipping the State Contract Between Agents

Every handoff between agents is a potential data loss point. If Agent A returns unstructured text and Agent B expects JSON, you will get silent failures that only surface in production. Define explicit input/output schemas (Pydantic models in Python, Zod schemas in TypeScript) for every agent boundary. Validate at every handoff. This one practice eliminates 60-70% of integration bugs in multi-agent systems.

Production Metrics from Real Deployments

These numbers come from Groovy Web's production agent systems across 200+ clients. They represent median values across different workloads and industries.

The Router pattern consistently delivers the lowest latency and highest success rate. Swarm systems have the highest P99 latency variance because concurrent agent execution introduces timing unpredictability. Pipeline systems are the most predictable — the gap between P50 and P99 is the smallest.

Combining Patterns: Hybrid Architectures

Production systems rarely use a single pattern in isolation. The most robust architectures compose patterns at different layers. Here is a reference architecture we have deployed for multiple enterprise clients.

                    +------------------+
                    |     Router       |  <-- Layer 1: Classify & dispatch
                    +--------+---------+
                             |
          +------------------+------------------+
          |                  |                  |
   +------v------+   +------v------+   +-------v-------+
   |  Pipeline   |   | Supervisor  |   |    Swarm      |  <-- Layer 2: Pattern per branch
   | (Invoices)  |   | (Complex Q) |   | (Research)    |
   +------+------+   +------+------+   +-------+-------+
          |                  |                  |
   Extract -> Enrich   Decompose ->       Parallel search
   -> Format -> Valid  Route -> Verify    -> Aggregate -> Report

This hybrid architecture processes three request types:

• Invoice processing — a fixed 4-stage Pipeline (extract, enrich, format, validate). Predictable workload, high testability.
• Complex customer queries — a Supervisor that decomposes multi-part questions and routes to specialists. Handles ambiguity.
• Market research — a Swarm of parallel search agents with dynamic task allocation. Unpredictable workload size.

The Router at the entry point keeps latency low for the 70% of requests that are straightforward invoices or simple queries. Only the 30% of complex or research-heavy requests pay the overhead of Supervisor or Swarm patterns. This architecture reduced our client's average response time by 45% compared to routing everything through a single Supervisor.

If you are evaluating frameworks for these patterns, our CrewAI vs LangGraph vs AutoGen comparison covers which framework maps best to which pattern. For implementation guidance, see our AI code generation guide and AI pair programming workflow.

Related Services

• Agentic AI Development Services
• AI Orchestration Development
• CrewAI and LangGraph Development
• LangChain Development Services
• Hire AI Engineers

Published: April 18, 2026 | Author: Groovy Web Team | Category: AI & Machine Learning