The dominant architecture for multi-agent AI systems in 2026 is centralised coordination. An orchestrator agent holds context and routes work to specialist subagents. The orchestrator is the hub; subagents are spokes. Communication flows through the application layer: HTTP calls, MCP tool invocations, A2A task delegations.
This architecture is functional. It is also a significant constraint on what multi-agent systems can become.
The centralised coordination model has a structural analog in the history of computing: the mainframe era. A central resource managed by administrators, accessed by terminals, with no peer-to-peer capability. The shift to distributed computing — personal computers, local networks, the internet — didn’t just make things faster. It changed what was computable, who could compute, and how knowledge accumulated across the system.
The question worth asking in 2026 is whether multi-agent AI systems are in a mainframe moment — and what the distributed computing equivalent looks like for agents.
The Information-Theoretic Case for Peer Networks
Consider the information economics of the current agent architecture.
When an agent needs to verify an academic citation, it queries an external API or scrapes a web page. The query succeeds or fails based on rate limits, scraping brittleness, and network conditions. The structured result — the parsed, verified citation — is discarded after the task completes. The next agent that needs to verify a similar citation starts from scratch.
This is an enormous amount of redundant work. At the scale of enterprise AI deployment — Gartner projects 40% of enterprise applications incorporating task-specific agents by end of 2026 — the aggregate redundancy is substantial.
The peer network model offers a different information structure. When a specialized agent has already structured and verified a dataset, subsequent queries from peers can retrieve the result directly. The work is done once; the value is shared. The network becomes collectively smarter as agents contribute their specialized outputs back to the mesh.
This is not a novel idea in distributed systems. Content-delivery networks approximate it at the data layer. Distributed hash tables (DHTs) implement it for content-addressable storage. What is novel is applying it to agent-to-agent communication with identity, capability discovery, and trust as first-class concerns.
Addressing as Identity
The most fundamental architectural difference between current multi-agent systems and a true peer network is the addressing model.
Current systems assign agents identifiers at the application layer: IDs in your orchestration code, hostnames if they’re running as services, ARNs if they’re Lambda functions. These identifiers are meaningful within a system but not across systems. An agent built by one team cannot be discovered by an agent built by another team without explicit configuration by a human.
A cryptographic addressing model changes this. If an agent’s address is derived from its public key — a 48-bit or 128-bit identifier that is simultaneously its address and its authentication credential — then identity and discoverability are unified at the network layer. Any agent on the network can find and authenticate any other agent without out-of-band configuration.
This is analogous to what DNSSEC was attempting to achieve for the web (with limited success, because it was retrofitted onto a model designed for human-readable addresses). For a network built from scratch for agents, cryptographic addressing is the natural baseline.
The Pilot Protocol specification (published as an IETF Internet-Draft) implements a 48-bit virtual address space with the structure N:NNNN.HHHH.LLLL, resolved by a distributed registry rather than DNS. Peer-to-peer tunnels use X25519 key exchange for forward secrecy and Ed25519 for identity. The address is the identity; no certificate authority is required to vouch for the binding.
Similar approaches appear in established peer-to-peer systems: Tor’s onion addresses, I2P’s destination keys, libp2p’s PeerIDs. The agent networking case applies these patterns at a layer below the application, making them available to any protocol running above.
Capability Discovery vs. URL Discovery
The web’s discovery model is URL-based: you find a resource by knowing or finding its address. Search engines crawl and index URLs. DNS maps hostnames to IPs. The entire human web is organized around the assumption that you need a location — a URL — to retrieve anything.
Agents need capability-based discovery. Not “where is the FX data stored?” but “which peer on this network has structured historical FX data for EUR/USD in the 2021–2024 range, with timestamp precision to the minute?”
This distinction matters for multi-agent system design. URL-based discovery requires centralized registries (which the orchestrator manages) or pre-configured peer lists (which a human sets up). Capability-based discovery enables emergent peer relationships: agents discovering and routing to specialists based on what those specialists can do, not where they are hosted.
The implementation of capability-based discovery typically involves:
- A directory layer where agents register their specializations on joining the network
- Domain-organized groups that agents self-select into based on their capabilities
- Query routing that maps a request to the best-matching peer group, then to the best-matching peer within the group
This is the architecture of interest groups on Pilot — where agents cluster by domain (security, finance, research, aviation) — but the pattern is general and appears in various forms in peer-to-peer research networks dating back to Gnutella and Chord.
The Transport Layer Question
Most agent communication in 2026 runs over TCP. TCP provides ordered, reliable delivery, connection management, and congestion control. For web applications where a human is waiting for a complete document to render, TCP’s properties are well-matched.
For agent-to-agent request-response, TCP introduces overhead that’s worth examining:
- Three-way handshake on every new connection adds latency at the start of each agent interaction
- Head-of-line blocking means a single lost packet stalls all subsequent messages in the stream
- Connection state is maintained at both endpoints, consuming memory proportional to the number of active connections
QUIC (RFC 9000) addresses several of these problems for web traffic: 0-RTT connection establishment, stream multiplexing without head-of-line blocking, connection migration. It is the likely successor to HTTP/1.1 + TLS for web traffic.
For native agent networks, the transport design space is somewhat different. Agent interactions are often short-lived: a query and a structured response. The connection is one-to-one rather than client-to-server. The latency budget is different because agents can handle asynchronous responses in ways browsers cannot.
UDP with application-layer reliability — sliding window, selective acknowledgment, AIMD congestion control — provides equivalent guarantees to TCP without the head-of-line blocking constraint. It also enables faster NAT traversal through hole-punching, which is relevant for agents running in constrained network environments (behind corporate firewalls, on cloud functions with restricted networking).
The 4x latency advantage observed for structured data retrieval on native agent networks versus the web stack is not primarily a transport-layer effect. The larger contributors are the elimination of HTML/JSON parsing overhead and the avoidance of scraping retry logic. But the transport design matters for large-scale deployments where aggregate connection overhead is significant.
The Security Surface
Peer-to-peer networks expand the security surface compared to hub-and-spoke architectures. In a centralised model, the orchestrator is the trust boundary: it validates inputs from subagents and controls what external resources they can access. In a peer network, trust relationships form directly between agents.
This requires careful design at the identity and policy layers.
Identity: Cryptographic addresses that are unforgeable and directly verifiable eliminate impersonation attacks that affect hostname-based systems (DNS spoofing, certificate mis-issuance). An agent can verify its peer’s identity without a trusted third party.
Authorization: Capability-based access control — where an agent’s permissions derive from its verified identity and declared capabilities — is more tractable in a peer network than role-based access control administered by a central orchestrator. But it requires that the identity layer be robust: if an agent can claim arbitrary capabilities, the model breaks.
Attestation: For enterprise deployments, agents may need to prove properties beyond identity — that they are running a specific version of a model, that their reasoning trace is available for audit, that they haven’t been fine-tuned in ways that violate policy. Attestation is an open research problem for autonomous agents and applies regardless of network architecture.
The peer network model doesn’t solve these security problems, but it provides a better foundation: cryptographic identity at the network layer, direct authentication without CA intermediaries, and the ability to audit trust relationships at the session layer rather than reconstructing them from application logs.
Current State and Research Directions
Production peer networks for agents exist but are early. The Pilot network at ~190,000 agents and 19.7 billion requests processed represents a meaningful data set; the behavioral patterns observed there (emergent peer routing, domain-based clustering, specialized service agent adoption) are consistent with what peer-to-peer network theory would predict.
The open research questions are significant:
- How do capability registries scale without becoming centralized bottlenecks?
- What are the right granularity and semantics for agent capability declarations?
- How does the network handle byzantine peers — agents that lie about their capabilities or manipulate their responses?
- What are the formal security properties of the X25519/Ed25519 construction under adversarial conditions specific to agent networks (e.g., long-lived agents with persistent addresses)?
- How does the peer routing protocol degrade when large fractions of the network are unavailable?
These are tractable research problems with good analogs in the distributed systems and peer-to-peer networking literature. The agent networking case adds complexity at the capability layer that doesn’t have a clean prior-art equivalent.
Conclusion
The centralised orchestration model for multi-agent systems is a local maximum. It is easier to reason about, easier to secure with current tools, and easier to debug. But it imposes a structural ceiling: agents can only coordinate through the relationships a human explicitly wires.
The peer network model is a different optimization target. It is harder to secure, harder to reason about at scale, and requires solving non-trivial problems in capability discovery and byzantine fault tolerance. But it is the model that enables genuine emergent coordination — agents forming trust relationships, sharing work, and collectively accumulating knowledge in ways that no central orchestrator can preplan.
The internet didn’t emerge from a series of increasingly sophisticated mainframes. The intelligence of the web emerged from the connections between nodes that nobody planned. The same dynamic is likely to be true for agent networks.
The infrastructure questions are real and the security questions are hard. But the direction seems right.
References: Pilot Protocol IETF Internet-Draft (pilotprotocol.network). Google Cloud A2A Protocol (Linux Foundation, 2025). Anthropic MCP Specification (Linux Foundation, 2024). RFC 9000, QUIC: A UDP-Based Multiplexed and Secure Transport (IETF, 2021). Maymounkov & Mazières, “Kademlia: A Peer-to-peer Information System Based on the XOR Metric” (IPTPS, 2002).
Peer-to-Peer AI: The Case for Decentralized Agent Networks was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.