Skip to content
ArchitectureIntermediate

Multi-Agent Orchestration Patterns: Supervisor, Pipeline, and Swarm Architectures Compared

TG
Tijo Gaucher

April 18, 2026·16 min read

One agent can do a lot. Two agents need a plan. This guide walks through the three canonical multi-agent orchestration architecture patterns — supervisor, pipeline, and swarm — with working OpenClaw and Hermes Agent code, plus a decision matrix for picking the right one.

TL;DR

Three patterns cover ~90% of production multi-agent systems. Supervisor: one coordinator delegates to specialists — best for structured workflows with audit needs. Pipeline: sequential stages, each a specialist — best for predictable, staged work like content production or ETL. Swarm: peers collaborate, no central authority — best for exploration and parallelism. Mix OpenClaw (computer-use) and Hermes Agent (reasoning) inside any of them. Rapid Claw runs all three patterns out of the box.

Multi-Agent Orchestration Architecture — Supervisor, Pipeline, and Swarm patterns compared

Want multi-agent orchestration managed for you?

Try Rapid Claw

Why Orchestration Architecture Matters

A single agent with a bloated tool list and a 40-page system prompt is an architecture decision — usually a bad one. As soon as you have more than one job-to-be-done, you either split the work across specialized agents or you accept degraded quality, longer context, and higher token cost. Which pattern you use to split the work is the multi-agent orchestration architecture.

The three patterns below aren’t competing — they solve different problems. In production on OpenClaw and Hermes Agent deployments, most teams end up with hybrids: a supervisor that dispatches to a pipeline for predictable steps and a swarm for open-ended subtasks. Understanding each pattern in isolation is the prerequisite for combining them well.

For each pattern we’ll cover: the shape, when to use it, when to avoid it, and a runnable code sketch with OpenClaw and Hermes agents working together.

Pattern 1: Supervisor (Delegation)

The shape

One coordinator agent holds the plan. It inspects the incoming task, decides which specialist can do each sub-step, dispatches the call, collects the result, and decides what to do next. Specialists don’t talk to each other — every message passes through the supervisor.

Mixed OpenClaw + Hermes supervisor

The supervisor is a reasoning-heavy agent — it’s a good fit for Hermes. The specialists are a mix: a Hermes reasoning agent for analysis, and an OpenClaw agent for computer-use tasks (browsing, downloading, file handling).

supervisor.py
from hermes_agent import Agent as HermesAgent
from openclaw import Agent as OpenClawAgent

# Specialists — each owns a narrow capability
browser      = OpenClawAgent(name="browser",    tools=["goto", "click", "screenshot", "read_dom"])
file_worker  = OpenClawAgent(name="file_worker", tools=["read_file", "write_file", "list_dir"])
analyst      = HermesAgent(name="analyst",     system="You analyze structured data and return JSON findings.")
writer       = HermesAgent(name="writer",      system="You produce polished written output from findings.")

SPECIALISTS = {a.name: a for a in [browser, file_worker, analyst, writer]}

# Supervisor — reasoning model with ONE tool: dispatch
supervisor = HermesAgent(
    name="supervisor",
    system=(
        "You are the supervisor of a multi-agent team. Decompose the user's task, "
        "then call dispatch(specialist, instruction) one step at a time. "
        f"Available specialists: {list(SPECIALISTS)}. "
        "Return a final answer only when all sub-steps are complete."
    ),
)

@supervisor.tool
def dispatch(specialist: str, instruction: str) -> dict:
    if specialist not in SPECIALISTS:
        return {"error": f"unknown specialist: {specialist}"}
    result = SPECIALISTS[specialist].run(instruction)
    return {"specialist": specialist, "result": result}

# Usage
final = supervisor.run(
    "Pull the top 5 HN posts, summarize each, and write a 200-word briefing."
)

Use when

  • You need a clear audit trail of who did what
  • Policy enforcement (rate limits, permissions) must be centralized
  • Task structure is reasonably known up-front
  • You want predictable cost — one coordinator, bounded fan-out

Avoid when

  • Supervisor becomes the bottleneck — every message routes through it
  • Task is genuinely open-ended with no good decomposition
  • Latency matters and specialists could run in parallel
  • You want emergent behavior — supervisors suppress it by design

Pattern 2: Pipeline (Sequential Processing)

The shape

Work flows through fixed stages. Each stage is owned by a specialist agent. The output of stage N is the input of stage N+1. No dynamic routing — the graph is a straight line (or a DAG with parallel branches that merge).

Content pipeline with OpenClaw + Hermes

A common example: produce a weekly market briefing. Stage 1 scrapes sources (OpenClaw — needs a browser). Stage 2 extracts facts (Hermes — reasoning). Stage 3 drafts the piece (Hermes — generation). Stage 4 publishes to the CMS (OpenClaw — computer use).

pipeline.py
from dataclasses import dataclass
from typing import Callable, Any
from hermes_agent import Agent as HermesAgent
from openclaw import Agent as OpenClawAgent

@dataclass
class Stage:
    name: str
    run: Callable[[Any], Any]

# Stage 1 — scrape (OpenClaw browser)
scraper = OpenClawAgent(name="scraper", tools=["goto", "read_dom"])
def scrape(sources: list[str]) -> list[dict]:
    return [scraper.run(f"Go to {url} and return the article text as JSON.") for url in sources]

# Stage 2 — extract facts (Hermes)
extractor = HermesAgent(name="extractor", system="Extract factual claims from articles as structured JSON.")
def extract(articles: list[dict]) -> list[dict]:
    return extractor.run({"articles": articles, "instruction": "Return facts[]"})

# Stage 3 — draft (Hermes)
drafter = HermesAgent(name="drafter", system="Write a 400-word briefing from extracted facts.")
def draft(facts: list[dict]) -> str:
    return drafter.run({"facts": facts})

# Stage 4 — publish (OpenClaw CMS)
publisher = OpenClawAgent(name="publisher", tools=["goto", "click", "type"])
def publish(briefing: str) -> dict:
    return publisher.run(f"Open the CMS, create a new post, paste: {briefing}, save as draft.")

PIPELINE = [
    Stage("scrape",  scrape),
    Stage("extract", extract),
    Stage("draft",   draft),
    Stage("publish", publish),
]

def run_pipeline(seed: Any, stages: list[Stage] = PIPELINE) -> Any:
    state = seed
    for stage in stages:
        print(f"[pipeline] {stage.name}")
        state = stage.run(state)
    return state

# Usage
result = run_pipeline(["https://hn.example.com", "https://news.example.com"])

Use when

  • Work has clear, ordered stages (scrape → extract → draft → publish)
  • You want each stage to be independently cacheable and restartable
  • Debugging should be as simple as reading logs top-to-bottom
  • Failure handling can be per-stage (retry stage 2, don’t re-run stage 1)

Avoid when

  • Later stages need to feed back into earlier ones — that’s a graph, not a pipeline
  • The set of stages isn’t known until runtime
  • You need dynamic decisions based on intermediate output
  • Stages are so short that orchestration overhead dominates

Pipelines checkpoint naturally

Persist the output of each stage. If stage 4 fails, you don’t re-scrape and re-extract — you resume from stage 3’s cached output. This alone is why pipelines beat supervisors for staged, expensive work: the recovery story is trivial. See our agent state management guide for persistence patterns.

Pattern 3: Swarm (Peer-to-Peer Collaboration)

The shape

No central coordinator. Agents operate as peers over a shared blackboard (message bus, shared memory, or both). Each agent watches for messages it can act on, posts results, and the group reaches a solution collectively. Termination is a separate concern — typically a stop condition evaluated by a quorum or an elected leader.

Swarm with a shared message bus

Here a research swarm explores a topic. A researcher Hermes agent posts findings, a critic Hermes agent pokes holes, a verifier OpenClaw agent independently checks facts by visiting sources. Any agent can contribute at any time.

swarm.py
import asyncio
from collections import deque
from hermes_agent import Agent as HermesAgent
from openclaw import Agent as OpenClawAgent

class Blackboard:
    """Shared message bus — every agent reads and writes here."""
    def __init__(self):
        self.messages: deque[dict] = deque()
        self.subscribers: list[asyncio.Queue] = []

    def post(self, sender: str, kind: str, content):
        msg = {"from": sender, "kind": kind, "content": content}
        self.messages.append(msg)
        for q in self.subscribers:
            q.put_nowait(msg)

    def subscribe(self) -> asyncio.Queue:
        q = asyncio.Queue()
        self.subscribers.append(q)
        return q

bb = Blackboard()

researcher = HermesAgent(name="researcher", system="Propose claims about the topic with sources.")
critic     = HermesAgent(name="critic",     system="Find flaws or contradictions in proposed claims.")
verifier   = OpenClawAgent(name="verifier", tools=["goto", "read_dom"])

async def run_agent(agent, acts_on: list[str], emits: str):
    q = bb.subscribe()
    while True:
        msg = await q.get()
        if msg["from"] == agent.name or msg["kind"] not in acts_on:
            continue
        if msg["kind"] == "halt":
            return
        output = await asyncio.to_thread(agent.run, msg["content"])
        bb.post(agent.name, emits, output)

async def terminator(max_rounds: int = 12):
    # Simple halt: stop after N messages
    while len(bb.messages) < max_rounds:
        await asyncio.sleep(0.5)
    bb.post("system", "halt", None)

async def main(topic: str):
    bb.post("user", "claim_request", topic)
    await asyncio.gather(
        run_agent(researcher, ["claim_request", "critique"], "claim"),
        run_agent(critic,     ["claim"],                     "critique"),
        run_agent(verifier,   ["claim"],                     "verification"),
        terminator(max_rounds=12),
    )
    return list(bb.messages)

asyncio.run(main("Are serverless GPUs economical for 24/7 agent workloads?"))

Use when

  • Problem is open-ended — research, ideation, generative design
  • You want parallel exploration of solution space
  • Emergent debate (propose → critique → refine) improves quality
  • No single agent has complete knowledge of the task

Avoid when

  • You need deterministic, auditable behavior
  • Token cost is tightly constrained — swarms are chatty
  • Task is well-defined and a pipeline would finish faster
  • You don’t have a good termination condition — swarms can loop forever

Decision Matrix: Which Pattern Fits?

The patterns trade off along four axes: latency, cost, debuggability, and flexibility. Start with your constraint, not your architectural preference:

If your priority is…PickBecause
Auditability & policy controlSupervisorEvery call routes through one agent — a single logging/enforcement point.
Predictable latency & costPipelineFixed stages → predictable token budget, trivial caching, clean restarts.
Fault tolerance & resumabilityPipelineCheckpoint per stage. Failure in stage 4 doesn’t blow away stage 1 work.
Open-ended explorationSwarmPeer debate surfaces options a central planner wouldn’t generate.
Solution quality over speedSwarmPropose/critique loops produce higher-quality outputs — at higher cost.
Dynamic routing at runtimeSupervisorCoordinator decides the next step — pipelines can’t, swarms do it implicitly.
Easiest to debugPipelineLinear logs. Swarms produce the hardest-to-trace failures in AI systems.

Hybrids: Where Real Systems Live

In practice, production systems blend patterns. Three hybrids worth stealing:

Supervisor-of-pipelines

Top-level supervisor dispatches to one of N pre-built pipelines. Used for multi-tenant agents where each tenant has different workflows but policy enforcement needs to be centralized.

Pipeline with embedded swarm stage

Deterministic pipeline for ingest + publish; a swarm stage in the middle for the creative/research step where exploration matters. Gives you the fault tolerance of pipelines and the quality of swarms.

Supervisor over a swarm

Supervisor sets up the swarm, defines the termination condition, then reads the final blackboard and writes a structured output. The swarm does the thinking; the supervisor does the reporting.

Production Concerns Across All Patterns

Whichever pattern you pick, the same production concerns show up. None of them are optional if you’re running agents for actual users:

production_concerns.md
1. Termination
   - Supervisor: max_steps + explicit "final_answer" tool
   - Pipeline:   stage count is finite by definition — easy
   - Swarm:      REQUIRES an explicit halt condition (quorum, max_msgs, leader vote)

2. Error handling
   - Supervisor: one retry policy in the coordinator
   - Pipeline:   per-stage retries + dead-letter queue for poison inputs
   - Swarm:      per-agent retries; watch for cascading failures across peers

3. Cost controls
   - Supervisor: rate-limit the dispatch tool itself
   - Pipeline:   token budget per stage, hard cap per run
   - Swarm:      token budget per agent AND per blackboard round

4. Observability
   - Supervisor: trace tree rooted at the supervisor — cleanest
   - Pipeline:   one span per stage — linear, easy to read
   - Swarm:      structured blackboard log + per-agent spans; hardest to follow

5. State persistence
   - Supervisor: persist the supervisor's conversation
   - Pipeline:   persist after each stage (this is the whole point)
   - Swarm:      persist the blackboard; replaying requires event sourcing

The managed alternative

Building termination logic, checkpointing, cost controls, and multi-agent observability from scratch for each pattern is weeks of work before you write a single line of application logic. Rapid Claw ships all three orchestration patterns with built-in checkpointing, per-agent rate limits, and distributed tracing across OpenClaw and Hermes agents. Pick a template, plug in your specialists, ship.

Picking Agents: OpenClaw vs Hermes for Each Role

The pattern tells you the shape. Picking which framework fills each role in the shape is a separate decision. A rough heuristic after running both in production:

  • OpenClaw →computer-use specialists: browsing, file system, desktop automation, anything requiring a screen. The role is “do things in the world.”
  • Hermes →reasoning specialists: analysis, drafting, planning, critique, the supervisor role itself. The role is “think about things.”
  • Either →API-tool agents (database, email, search). Pick whichever framework owns more of your existing code.

For a deeper framework comparison, see Hermes Agent vs OpenClaw. For cost implications of running a multi-agent setup, token cost math for agentic systems is a good follow-up — multi-agent amplifies token consumption, and without smart routing the bill scales quickly.

Frequently Asked Questions

Skip the orchestration plumbing

Rapid Claw ships supervisor, pipeline, and swarm templates with checkpointing, rate limits, and tracing already wired in — for OpenClaw and Hermes Agent. Plug in your specialists, go.

Deploy a multi-agent system