Mesh Topology

One-Line Summary: A mesh topology lets every agent talk to every other agent directly, with no central coordinator — useful when peers genuinely need to negotiate, but expensive in tokens and hard to debug, so it is rarely the right default.

Prerequisites: Topology as a design decision, sub-agents as primitives

What Is Mesh Topology?

In a mesh, there is no boss. Every agent can read messages from any other agent and emit messages anyone can read. Agreement comes from negotiation rather than authority. The classical analogy is a peer-to-peer network: any node can talk to any other; routing is the network's responsibility, not the application's.

Mesh is what most beginners reach for when they hear "multi-agent" because it sounds more egalitarian and agent-y. In practice, mesh is mostly the wrong choice. It is appropriate when peers genuinely need to negotiate without a single arbiter — collective decision-making, multi-party simulations, federated agents from different organizations — and inappropriate for the routine case where one agent could just supervise the others.

How It Works

In a mesh implementation, the harness provides a shared message bus — a scratchpad, a Pub/Sub channel, a shared graph state — that all agents read from and write to. Each agent's prompt includes the message-bus contents. Every agent observes everyone else's outputs.

The trickiest part of a mesh is termination. Without a queen, who decides when the task is done? Common answers: a separate "moderator" role (which makes it not really a mesh), unanimous agreement, a quorum, a budget exhaustion, or a voting round.

Why It Matters

The reason to teach mesh is that it makes the coordination cost of multi-agent systems unmistakable. Three workers in a mesh produce 9 potential pairwise interactions per turn (worker→worker), versus 3 in a queen-led topology (queen→worker). Token cost scales with that number. Latency scales with the longest negotiation chain. Debuggability scales inversely.

Mesh is also the topology that becomes necessary at scale, when no single agent has the bandwidth to be the queen for a large peer group. Federated agent systems are inherently mesh-like.

Key Technical Details

Token cost grows quadratically with peer count. Five-agent mesh is borderline; ten-agent mesh is almost always wrong.
State sharing strategies: append-only log (every message visible to everyone), shared key-value (peers read each other's named state), CRDT (for federated mesh).
Termination is the hardest problem: budget exhaustion is the common pragmatic answer.
Loop detection is critical: Mesh agents can ping-pong forever (A asks B, B asks C, C asks A). Some maximum-turn cap is mandatory.
Trust is symmetric: Every peer has the same access. This is fine inside one trust boundary; inappropriate when peers are from different organizations (that is federation, see Module 06).
Mesh + voting often becomes "consensus": When peers vote on outcomes rather than negotiate them, you have moved into consensus protocols (Raft, Byzantine, gossip — see Module 06).

How Harnesses & Frameworks Implement This

Harness / Framework	Mesh support	How
Claude Code	DIY — no first-class peer bus	Shared file as bus
Claude Agent SDK	DIY	Programmatic
ruflo	First-class	`ruflo-swarm` mesh mode
LangGraph	Multi-agent graphs with full edges	DIY but natural
AutoGen	`GroupChat` with round-robin or `auto` speaker selection	Closest thing to mesh out of the box
CrewAI	Limited — sequential or hierarchical only	DIY
OpenAI Agents SDK	Handoffs make star/chain topologies easier than mesh	DIY mesh
Codex CLI	✗	N/A
Cursor	✗	N/A

Connections to Other Concepts

queen-led-hierarchy.md — The opposite default.
hive-mind-pattern.md — Mesh's emergent-behavior cousin.
consensus-in-multi-agent-systems.md — Voting/consensus protocols often replace mesh negotiation.
topology-selection-decision-tree.md — When (rarely) mesh is the answer.