Your Fleet Is a Mesh

I have three machines running agents right now. A Mac mini under my desk that handles local computer-use stuff and interacts with the desktop. A harbormaster pod on Fly.io that runs the gateway and dashboard. A cron-runner pod in us-east that wakes up every few hours, does some batch work, and goes back to sleep. And they all need to talk to each other.

The way I connect them is embarrassing. There are SSH tunnels with autossh keepalives that break when my home IP changes. There are REST endpoints with API keys I rotate by hand on a schedule I keep in my head. There is a shared Redis instance that I swear I will replace with something more robust next month. It is 2026 and I am duct-taping my agents together like it is 2015.

If you run agents across more than one machine, you probably have the same pile of hacks. You might call it your "integration layer" to feel better about it. The problem is that every agent-to-agent integration is bespoke. You write a connector for Claude's MCPs, another connector for Codex, another for whatever LangChain agent is running this week. The integration surface grows with every new agent type you introduce.

Google released something that addresses this directly.

What SAM Actually Is

SAM stands for Sovereign Agent Mesh. It is a peer-to-peer network for autonomous agents. You run a lightweight node on each machine. The nodes find each other automatically using libp2p, the same protocol that powers IPFS and Filecoin. Every packet is authenticated with cryptographic keys. Your agents plug into the local node and can discover tools across the whole mesh.

Three moving parts: the control plane handles identity registration and policy across the mesh. The routers provide bootstrap connectivity and relay traffic between nodes that can't talk directly. The node is the local client you run on each machine, exposing an MCP server your agents talk to.

Google already has its own Agent-to-Agent protocol (A2A), which is a client-server model over HTTP. A2A says agents should communicate by calling each other's endpoints. SAM says something different. It puts the abstraction at the transport layer instead of the application layer. You do not write integration code. You join a mesh and agents find each other.

The tweet that made this click for me came from hasantoxr: "Think of it like BitTorrent, but for your agents." That is the right image. BitTorrent does not have a central server that tells peers where the files are. Peers discover each other. They negotiate directly. They form and leave swarms based on what they need. SAM applies that model to agent communication.

Networking Problem, Not an API Problem

The agent framework space churns through integration strategies fast. Every framework builds its own layer. Claude has MCPs. Codex has its own tool pipeline. LangChain has its tool registry. The industry response so far has been A2A and MCP, which say "standardize the API and everything will work."

That approach works until you have more than a few agents. Now you are maintaining API versions, managing authentication across services, debugging timeout issues between endpoints, and wondering why your mesh needs five YAML files to describe one connection. Every new agent type adds another integration surface. The complexity grows with the topology.

The P2P approach changes the question. Instead of "how do I connect agent A to agent B," you ask "how does my agent discover and authenticate the services it needs." The network handles the rest. One is infrastructure you maintain. The other is a property of the network.

This shift matters philosophically because it changes where the complexity lives. In the API model, complexity lives in the connectors, the middleware, the orchestration layer you write and maintain. In the P2P model, complexity lives in the protocol itself, once, and every agent benefits from it. The same pattern played out with HTTP versus message queues, with REST versus gRPC, with databases versus blockchains. The network model always wins when the topology is unpredictable.

What This Means for Our Fleet

Our fleet architecture already assumes agents are distributed. The Mac mini runs local agents that interact with the desktop. The harbormaster pod exposes a gateway for remote coordination. The cron-runner acts on schedule. Each one works independently and coordinates when needed.

The missing piece has been the connection layer. Right now I use HTTP calls between pods with hardcoded addresses. It works but gets brittle past a handful of nodes.

SAM validates the direction. A mesh architecture says you do not need a central broker. The network IS the integration layer. Every node carries its own identity. Move a node from one machine to another and it brings its keys with it. That is the kind of portability a distributed fleet needs.

Our agents already behave like mesh nodes. They just need the protocol to match.

The Next Six Months

A2A has momentum as a standard for agent-to-agent communication over HTTP. It is backed by Google, has implementations in multiple languages, and people are building on it. But it stays in the client-server model. You call endpoints. You manage routing. You deal with the same problems REST brought twenty years ago, applied to agents instead of microservices.

SAM is a different bet. It says agent networks are more like human networks than API networks. They form, dissolve, and reform based on need rather than configuration.

A2A works in controlled environments where you know every agent and capability ahead of time. SAM works where agents come and go, where you want discovery without configuration, where topology changes faster than you can update a deployment file.

Our fleet is the second kind. I plan to start running SAM nodes alongside our existing setup. The transition does not have to happen all at once. Run a node, let the mesh form, point some agents at it.

Get on the Mesh Early

The patterns are visible early. People who get value from a new infrastructure model adopt it before it is polished. By the time SAM has a managed cloud offering and a KubeCon talk, the early users will have already built their workflows around it.

The direct agent-to-agent approach is live now. The testnet is running. The code compiles. The nodes connect.

Your fleet is a mesh. Now you have the protocol to match.