One-Line Summary: Consensus protocols — Raft, Byzantine, gossip — are how multiple agents agree on state, decisions, or outputs in the presence of disagreement, latency, or untrusted peers, and they are increasingly first-class primitives in modern multi-agent harnesses.
Prerequisites: Multi-agent architectures, agent-to-agent communication, topology as a design decision
Status: Module 06 anchor concept — first draft. Authoring backlog: bespoke
ExplorerAHOConsensusInMultiAgentSystems(Raft vs Byzantine vs Gossip simulator) per the plan file.
What Is Consensus in a Multi-Agent System?
When multiple agents work on the same task, they will produce different outputs. Even three sub-agents reading the same diff will catch different bugs, miss different ones, and disagree about severity. Consensus is the protocol by which the system arrives at one answer — by majority vote, by weighted vote, by an arbiter, by a leader, or by a more sophisticated agreement protocol borrowed from distributed systems.
The reason this is no longer just an academic concern: federated agent platforms (notably ruflo) now run agents across machines with potentially adversarial peers, and the classical distributed-systems vocabulary — Raft, Byzantine fault tolerance, gossip — is the right vocabulary for that setting.
How It Works
A consensus protocol has three components: a proposal mechanism (how does an agent suggest an outcome), an agreement rule (how do peers respond), and a commit rule (when is the outcome final). Raft adds a leader who serializes proposals; Byzantine protocols tolerate up to f malicious peers among 3f+1 total; gossip protocols spread information probabilistically and converge over time. Each has different latency, throughput, and trust requirements.
Why It Matters
Single-agent systems do not need consensus. Multi-agent systems within one trust boundary often get away with a designated arbiter. The moment agents cross trust boundaries — different machines, different users, plugins of unknown provenance — protocol-level consensus is the only way to keep the system honest.
How Harnesses & Frameworks Implement This
| Harness / Framework | Consensus support |
|---|---|
| Claude Code | None — single trust boundary |
| Claude Agent SDK | None natively — DIY |
| ruflo | First-class: Raft, Byzantine, gossip selectable per swarm |
| LangGraph | DIY via state-graph design |
| AutoGen | Voting and group-chat agreement patterns |
| CrewAI | None natively |
| OpenAI Agents SDK | Handoffs, no built-in consensus |
| Codex CLI | N/A |
| Cursor | N/A |
Connections to Other Concepts
raft-for-agents.md,byzantine-fault-tolerant-agents.md,gossip-protocols-for-agents.md— Each protocol expanded.cross-machine-agent-federation.md— The setting in which Byzantine assumptions actually matter.behavioral-trust-scoring.md— The reputation layer that often sits on top of consensus.../../ai-agent-concepts/05-multi-agent-systems/consensus-and-voting.md— Foundational coverage.
Further Reading
- Diego Ongaro and John Ousterhout, "In Search of an Understandable Consensus Algorithm" (2014) — The Raft paper.
- Castro and Liskov, "Practical Byzantine Fault Tolerance" (1999) — The PBFT paper.
- ruvnet, ruflo federation documentation — How consensus is wired into a real harness.