Orchestration topologies

Peer-to-peer and swarm patterns

Decentralized agent coordination.

No supervisor

Every topology so far has had a central authority: the pipeline's coupling, the supervisor in supervisor/worker, the top orchestrator in a hierarchy. Swarm patterns drop the central authority entirely. Agents are peers. They coordinate by exchanging messages directly, by reading shared state, or by reacting to events. There is no single "decider."

This is the most exotic topology in the catalog and the rarest one to actually need. But understanding it is useful both because some workloads genuinely fit it and because the failure modes of swarms teach you a lot about why centralization is usually worth the cost.

What a swarm looks like

# Each agent is a peer; no orchestrator.
class Agent:
    def __init__(self, name, peers, bus):
        self.name = name
        self.peers = peers
        self.bus = bus
 
    def step(self):
        msg = self.bus.recv(self.name, timeout=0)
        if msg is None:
            return
        action = self.decide(msg)
        if action.send_to:
            self.bus.send(action.send_to, action.message)
 
 
def swarm_run(agents, ticks=10):
    for _ in range(ticks):
        for a in agents:
            a.step()

The pattern is round-robin or event-driven. Each agent inspects its inbox, decides what to do, possibly sends a message to a peer, and yields. Over time, work emerges from the pattern of message exchanges.

When swarms actually fit

There are a small number of legitimate use cases:

1. Truly decentralized problem domains

Some problems have no natural "decider." A multiplayer simulation, a multi-tenant marketplace, a research environment where you want different agents to argue different positions and let one another's arguments propagate. There is no obvious one-supervisor design because the problem has no privileged viewpoint.

2. Resilience-driven systems

If you genuinely need the system to keep working when any one agent dies (the orchestrator is a single point of failure), peer-to-peer can be the right shape. This is rare in practice; most agent systems can tolerate orchestrator failure with a retry.

3. Emergent search / debate

Some research patterns intentionally use swarms: spawn N agents with different priors, let them argue, see which positions survive. The lack of central coordination is a feature, not a bug.

For 95% of production agent systems, none of these apply. Use a supervisor.

Why swarms are hard

Three problems that swarms make worse than centralized topologies:

Termination

Without a supervisor to declare "we're done," swarms have no obvious stopping condition. Common fixes are time-based (run for N ticks), quorum-based (when M agents agree, we stop), or an explicit "stop" message that propagates. None of these are as clean as the supervisor's "synthesis is complete" exit.

Cycles

Agent A messages B. B replies to A. A replies to B. With no orchestrator to break the cycle, you get infinite loops. Detecting cycles in a swarm requires either explicit message-history tracking or strict "do not reply to a sender if you have already replied to them about this topic" rules. Both add complexity.

Coherence

In a supervisor system, the synthesis prompt produces one coherent final answer. In a swarm, the "answer" is whatever state the system has converged to, which may not exist or may not be coherent. You usually have to add a synthesizer agent at the end, which is a supervisor in disguise.

Swarm safety: the byzantine corner

If any peer can become unreliable or adversarial, you have a coordination problem with deep theoretical pedigree (byzantine fault tolerance). Most agent systems do not need to worry about this because all peers are trusted, but: if your swarm includes agents from third parties or untrusted sources, you cannot blindly trust their messages. Treat anything from an untrusted peer as untrusted input and validate it the same way you would untrusted user input.

A simple coordination protocol: contract net

A useful pattern that sits between supervisor/worker and pure swarm: contract net. Any agent can post a "task offered" message; other agents bid for it; the poster picks a bidder and assigns the task. There is no permanent supervisor, but at any moment a poster is acting as a temporary one for a single task.

# 1. agent_a needs help with task T
bus.publish("offer", {"task": T, "from": "agent_a"})
 
# 2. peers that can help bid
bus.subscribe("offer", lambda e: bus.publish("bid", {
    "task": e["task"],
    "from": me,
    "score": estimate_fit(e["task"]),
}))
 
# 3. agent_a picks the best bid and assigns
best = max(received_bids, key=lambda b: b["score"])
bus.publish("assign", {"task": T, "to": best["from"]})

Contract net handles dynamic specialization without a fixed assignment table. New agents joining the swarm just start bidding; old agents that can't help anymore stop bidding. It is a useful intermediate point if you need some of the flexibility of swarms without the chaos.

Swarms vs centralized topologies

The right answer for production is overwhelmingly the right column. The left column is a tool for specific problem shapes, not a general-purpose pattern.

Wrapping up topologies

You have now seen the main topologies in roughly increasing order of complexity:

• Single agent (Module 1): the baseline. Often enough.
• Sequential pipeline (this module, lesson 1): fixed stages, easy to build.
• Supervisor/worker (this module, lesson 2): the workhorse pattern.
• Hierarchical (this module, lesson 3): supervisor/worker recursed.
• Swarms (this lesson): rarely the right answer.

A useful design heuristic: start with the simplest topology that handles your workload. Move up only when you can name the specific failure mode that the next-level topology fixes. Reach for swarms only when none of the others fit the problem shape, which is rare.

Key takeaway

Swarms are peer-to-peer agent systems with no central orchestrator. They fit a small set of genuinely decentralized problems and produce more headaches than benefits in most production scenarios. Termination, cycles, and coherence all need explicit design that supervisors give you for free. Useful to know exists; rarely the right tool. The next module shifts from topology to state: how the conversation between agents stays consistent over time and what to do when you need agent runs to survive crashes.