Consensus Between Three or More AI Agents Without a Leader: How Peer Agreement Works

When you have three or more AI agents that need to reach consensus without a leader — deciding task ordering, settling a value, or converging on shared state — the default move is to appoint a coordinator. One agent owns the decision, everyone else asks it. That works until the coordinator disappears, falls behind, or becomes the bottleneck every message has to route through. Leaderless consensus is the alternative, and it is far more practical than the theory makes it sound. This post is an explainer of what "without a leader" really demands, which existing tools fit, and where most peer consensus attempts actually fail.

Why "No Leader" Is a Different Problem

Leader-based consensus (Raft, Paxos) is well understood. The catch: election itself is a consensus problem, and it assumes a topology that stays put. Autonomous agents violate that assumption constantly — they restart, move across clouds, change IPs, and drop off the network mid-conversation. If your consensus protocol depends on a stable leader, you have just re-imported the failure mode you were trying to avoid.

Leaderless agreement quietly assumes three substrate properties:

1. Stable identity. A participant you can name today is the same participant tomorrow, even after a restart.
2. Reachability. Messages actually arrive, including for agents behind NAT or firewalls.
3. Verified trust. You know who is sending you a vote, and they know you.

Most write-ups on agent consensus skip straight to the algorithm. In practice, the substrate is where these systems fall apart.

The Existing Toolkit: Quorums, CRDTs, BFT

You do not need to invent an algorithm. The pieces exist; the job is picking the right one for the kind of agreement you need.

Quorum voting — the default shape

Each agent broadcasts a proposal, peers respond with signed acks or counter-proposals, and the proposal applies once a threshold of the group has agreed. No agent is special; the quorum is a property of the group, not of any single member. This is the right shape for task ordering and value settlement between agents that already trust each other.

CRDTs — agreement by merging

For state convergence, you can skip consensus entirely. Convergent replicated data types let every agent apply updates locally and merge with peers; as long as everyone eventually exchanges deltas, the state converges without any vote. This is the cheapest form of "agreement" and the right default when the question is what is the current state, not whose proposal wins.

BFT — only when you expect adversaries

Byzantine fault-tolerant protocols (PBFT, HotStuff) handle malicious participants, and they cost accordingly — extra rounds, extra messages, and a minimum group size that grows with the number of tolerated faults. Worth it for open networks with untrusted actors. Overkill for a closed set of collaborating agents.

The honest summary: for the common cases — ordering work, settling values, converging state among agents you know — you need a quorum loop, a merge function, and the substrate properties above. You rarely need Byzantine tolerance, and you never need a coordinator.

The Layer That Kills Peer Consensus Before It Starts

Here is the part that rarely shows up in the algorithm papers. To run any of the above, every agent needs an address that survives restarts, a path to peers behind NAT, and a way to verify who it is agreeing with. If those three things are bolted on as an afterthought, your consensus loop will spend most of its time failing to deliver messages, not failing to agree.

This is the gap Pilot Protocol fills, and it is an honest fit rather than a stretch: it is a networking layer built specifically so agents can talk to each other as peers. Each agent gets a permanent virtual address that survives restarts and IP changes. Transport is encrypted UDP tunnels (X25519 key exchange, AES-GCM) with STUN, hole punching, and relay fallback, so agents behind NAT are reachable. Trust is an explicit per-peer handshake where both sides approve — membership and trust are decoupled, which is exactly the pairwise-trust property a quorum needs. The network carries 243k+ agents, and it is open source under AGPL-3.0 with zero external dependencies.

The commands are the substrate in practice:

pilotctl handshake <peer-address> "collaborating on shared task state"
pilotctl peers          # who you can actually reach, and how
pilotctl send-message <peer> --data '<message>'

The handshake detail matters for consensus specifically: joined does not imply trusted. Each agent approves who it will accept messages — and votes — from, so your quorum is made of relationships the participants chose, not the network's default. And because addresses are permanent, the agent that voted in round one is the same agent in round ten. The Pilot Protocol docs cover the addressing and trust model in detail.

A Minimal Leaderless Agreement Loop

Putting it together, a leaderless agreement loop for three or more agents looks like this:

1. Propose — an agent broadcasts {proposal, seq, signature} to every peer.
2. Collect — each peer replies with a signed ack or a counter-proposal.
3. Apply — the proposer applies once it holds acks from a simple majority of the group.
4. Converge — for shared state, merge CRDT deltas instead of voting on a single winner.

A sketch of the loop:

QUORUM = 2  # simple majority of a 3-agent group

def propose(msg, peers):
    acks = {me: msg}
    for p in peers:
        if p.ack(msg):          # signed, delivered over the peer tunnel
            acks[p] = msg
    if len(acks) >= QUORUM:
        return apply(msg)       # durable, ordered, attributed
    return backoff_and_retry(msg)

The transport here is whatever your peers speak; the loop is the point. What the transport must give you is addressing that survives restarts and verified sender identity. That is the substrate layer — and it is the part you should not have to build yourself.

Consensus Between Three or More AI Agents Without a Leader: What to Reach For First

If you are designing a multi-agent system that needs leaderless agreement, the order of operations is:

1. Give every agent a stable identity and address that survives restarts and NAT.
2. Establish trust pairwise and explicitly — no ambient "everyone on the network is trusted."
3. Then pick the mechanism: quorum for ordering and settlement, CRDTs for state convergence, BFT only when you genuinely expect malicious actors.

If the loop is stuck, check the substrate before the algorithm. Nine times out of ten the failure is a message that never arrived or a sender that could not be verified — not a flaw in the agreement logic.

Where to Start

Leaderless consensus between agents is mostly a substrate problem wearing an algorithm costume. Once addressing, reachability, and trust are real, the agreement layer reduces to a quorum loop and a merge function. If you want to see the substrate part working before you build on it, install Pilot, handshake a couple of peers, and look at who you can actually reach:

curl -fsSL https://pilotprotocol.network/install.sh | sh

Then run a quorum loop over direct peer messages and watch how much of the hard part was already handled for you. The docs at pilotprotocol.network/docs are the reference for the addressing and trust model behind it.