You're wiring agents together and MQTT keeps coming up. It's the default answer to "how do my things talk to each other" — battle-tested, tiny footprint, works on a Raspberry Pi. So you evaluate MQTT for AI agent communication, and it looks great on paper. Then you hit the moment where it stops being the right shape: one agent needs to talk to one specific peer, directly, and the broker is sitting in the middle of a conversation that was always point-to-point.
This post is an honest comparison. MQTT is excellent at what it was designed for — many-to-many event fan-out. But broker-based messaging and peer-to-peer overlays solve different problems, and knowing which one you actually have saves you from building a system that's fragile in the exact places agents are most sensitive.
MQTT for AI Agent Communication: What It's Actually Good At
MQTT is a publish/subscribe protocol that runs over TCP. Clients don't talk to each other; they connect to a broker (Mosquitto, EMQX, HiveMQ, AWS IoT Core) and exchange messages on topics. A publisher sends to agents/fleet-1/status, the broker fans it out to every subscriber.
That model is genuinely great for several agent workloads:
- Fan-out. One agent publishes an event, a hundred agents receive it. The broker handles the copy fan-out for you. This is the killer feature — nothing peer-to-peer does this as cleanly.
- Decoupling. Publishers don't know who's listening. An agent can publish to a topic without caring whether the consumer is up, on the same cloud, or even written yet.
- Delivery semantics. QoS 0/1/2 give you at-most-once, at-least-once, and exactly-once delivery. Retained messages let a new subscriber immediately see the latest state. Last-will messages tell the rest of the fleet when an agent died.
- NAT friendliness (the one people forget). Clients dial out to the broker, so agents behind NAT connect without any inbound holes. If you have a reachable broker, your agents don't need public addresses.
If your pattern is "many agents emit events, many agents consume them," MQTT is a legitimately good choice and this post isn't arguing otherwise.
Where the Broker Model Stops Fitting
The problems start when agent communication is actually point-to-point — which, in practice, is most of it. A task handoff, a file transfer, a tool call, a negotiation: these are one-to-one conversations wearing a topic name.
The broker is a single point of failure in every conversation. All traffic crosses it, even between two agents on the same machine. Broker down, agents down. You can cluster brokers, but now you operate infrastructure — and the cluster itself is still a shared dependency every agent trusts.
Identity is broker-scoped. An MQTT client ID only means something to that broker. Two agents on different brokers can't address each other at all without bridges. There's no notion of "this agent, wherever it lives, reachable by this name" — the identity dies with the connection.
NAT help becomes a NAT requirement. Yes, clients dial out — but only to your broker. If agents are split across clouds, a partner's network, a laptop at home, the broker must be reachable from all of them. You've traded per-agent port forwarding for one big, always-on, publicly reachable component that everything depends on.
Trust is centralized and coarse. The broker authenticates clients, and that's it. Agent A doesn't verify Agent B; both just trust the broker's ACLs. For autonomous agents that need to make their own trust decisions about peers, that's the wrong trust boundary — it's "joined the network" = "trusted," which is exactly the conflation that breaks agent security.
The Direct-Link Case: One Agent, One Peer, No Middleman
The alternative shape is a peer-to-peer overlay: every agent gets a permanent virtual address, and agents talk over encrypted tunnels directly, with NAT traversal (STUN + hole punching, relay fallback) handling reachability instead of a central broker.
This maps cleanly onto the point-to-point reality:
- Direct links. Agent A sends to Agent B's address. No broker in the path, no shared component to operate, no single point of failure for the conversation.
- Permanent identity. The address survives restarts, IP changes, and moving between clouds. Peer A can reach peer B tomorrow by the same name — no reconnecting to a broker, no re-subscribing.
- Per-peer trust. Each pair does a mutual handshake. Agent A decides whether to trust Agent B directly, rather than inheriting trust from a broker. Membership and trust are decoupled — "on the network" no longer implies "trusted by me."
- Reachability without infrastructure. STUN + hole punching gets agents behind NAT talking directly; when a NAT defeats punching, a relay fallback carries the traffic. No inbound ports, no public broker.
That's the model Pilot Protocol implements: an open-source overlay network (Go, zero external dependencies, AGPL-3.0) giving agents a permanent address, encrypted UDP tunnels (X25519 + AES-GCM), NAT traversal, and an explicit mutual-handshake trust model — plus an app store where agents install capabilities with pilotctl appstore install. It's built for the case MQTT explicitly delegates away: one agent reaching one peer directly.
A Quick Comparison
| MQTT (broker) | Peer-to-peer overlay | |
|---|---|---|
| Message pattern | Publish/subscribe, topic-based | Direct address-to-address |
| Fan-out | Excellent — broker copies | Manual per-peer sends |
| Point-to-point | Through the broker (extra hop) | Direct tunnel |
| Single point of failure | The broker | None in the data path |
| NAT handling | Clients dial out to broker | Hole punching + relay fallback |
| Identity | Broker-scoped client ID | Permanent virtual address |
| Trust | Broker authenticates clients | Mutual per-peer handshake |
How to Choose
Ask what the traffic actually looks like.
If agents mostly emit events others consume — telemetry, status feeds, result broadcasts — use MQTT (or NATS, or Kafka; the broker family is right for fan-out). MQTT is mature, tiny, and does this better than any overlay.
If agents mostly talk one-to-one — task handoffs, file transfers, tool calls between specific peers — the broker is an extra hop that adds a failure point and a shared dependency. A peer-to-peer overlay gives you the direct link, stable identity, and per-peer trust that broker routing can't express.
Most multi-agent systems are a mix, and that's fine: the two aren't mutually exclusive. Run MQTT for the event streams where fan-out earns its keep, and put the point-to-point conversations on an overlay where they belong. The trick is not picking a winner — it's refusing to force one architecture to carry both patterns.
The interesting write-up of this tradeoff is on the Pilot Protocol blog, which covers overlay networking for agents, NAT traversal, and trust. If you want to see the direct-link model in action:
curl -fsSL https://pilotprotocol.network/install.sh | sh
pilotctl daemon start
pilotctl send-message <peer-address> --data 'hello from agent one'
