Why the Internet of Agents Needs a Shared Networking Layer

AGNTCY, part of the Linux Foundation with a technical steering committee drawn from Cisco, Red Hat, Google Cloud, Dell Technologies and Oracle, is building an open ecosystem for agent discovery and coordination.

Underneath the branding, these projects are all solving the same set of hard problems: how does a peer prove who it is, how does it find other peers without a central directory, how does it route around NAT and firewalls, and how does it broadcast updates efficiently to a large, changing network. None of that is agent specific. It is distributed systems networking, and it has been worked on for over a decade by people building storage networks, blockchains, and other peer to peer infrastructure.

That is the case for not reinventing it.

The build versus reuse problem

Every team that starts an agent network project faces a choice early on. Build peer identity, discovery, routing, and messaging from scratch, or adopt an existing networking layer and spend your engineering time on what actually differentiates your product: agent protocols, orchestration logic, and developer experience.

Building from scratch is tempting because the first version always looks simple. A basic peer list, a bit of gossip, maybe a central registry to bootstrap. It works fine at ten nodes. It starts breaking at a thousand, and by the time you are dealing with NAT traversal edge cases, connection churn, and inconsistent peer state across regions, you have quietly become a networking company instead of an agent company.

What libp2p provides

libp2p is a modular, open source networking framework built specifically to be that reusable layer. It provides:

• Peer identity through cryptographic Peer IDs, stable across changing network conditions
• Secure, encrypted communication between peers
• Peer discovery without centralized infrastructure
• Distributed routing through a Kademlia based DHT
• Publish and subscribe messaging through GossipSub
• NAT traversal and connection management
• Support for multiple transport protocols

It has powered large scale decentralized systems across storage, blockchain, and distributed computing for years. It is not an AI framework and it is not an agent protocol. It sits at the same layer TCP/IP and HTTP sit at for the web: infrastructure that higher level protocols build on top of, not something that competes with them.

AGNTCY as a working example

AGNTCY made this call directly. Its Directory service, the component responsible for agent discovery and metadata exchange, is built on libp2p. Every node in the network becomes a libp2p peer with a cryptographic identity. Agent metadata is content addressed using IPFS style Content Identifiers, advertised through the Kademlia DHT, and retrieved peer to peer through libp2p RPC once a provider is found. Updates propagate through GossipSub instead of every node polling for changes.

None of that required AGNTCY to write its own peer discovery or transport layer. It let the team focus on what actually makes AGNTCY useful: agent identity, protocol interoperability, and the developer experience around publishing and finding agents.

For Spellguard and other teams building on top of AGNTCY, this matters directly. The discovery and networking guarantees you are relying on are not custom, bespoke infrastructure with a single point of failure. They are built on a networking layer that is already battle tested outside the agent space.

A common substrate, not a competing standard

One of the more useful properties of building on libp2p is that it is protocol agnostic. Multiple higher level protocols can run over the same networking layer at once, including AGNTCY's own protocols, SLIM, MCP, A2A, and custom enterprise protocols. That means a shared networking foundation does not force convergence on a single agent protocol. Different ecosystems approaching agent discovery from a different design philosophy can still interoperate at the transport and discovery layer even if they diverge at the protocol layer above it.

That is the real opportunity in front of the Internet of Agents space right now. Not every project needs to agree on how agents describe capabilities or negotiate tasks. But they can share the same proven networking substrate underneath, the same way competing web frameworks all still run on TCP/IP.

What is next

In the next post, we go under the hood of AGNTCY's Directory service and walk through the actual discovery pipeline end to end, from artifact publication through content addressing, DHT advertisement, and peer retrieval. It is a concrete look at what a production agent network built on libp2p looks like in practice, and a useful reference point for any team evaluating the same foundation.

If your team is building or evaluating infrastructure for an agent network, this is exactly the kind of architecture decision worth getting right early. We have spent years working inside the libp2p ecosystem and helping teams apply it to agent discovery and coordination problems, and we are always happy to talk through what that could look like for your project.

---

Working on something in this space? If you are designing, deploying or measuring peer-to-peer or agent networks, we would genuinely like to hear about it. Reach out to Meshworks if you would like to discuss something you are working on — no pitch, just a conversation with people who work on this every day.