Agent Discovery Protocols in Distributed Systems

An agent that cannot find a peer cannot delegate a task to it, and delegation is the whole point of running more than one agent. Multi-agent systems exist to do work that a single agent can't handle alone: splitting a problem across specialists, routing a task to whichever service knows how to finish it, coordinating steps across organizations that don't share infrastructure. All of that depends on one agent being able to locate another, confirm what it can do, and trust the answer. Agent discovery is that foundation, and it's the piece of the stack that engineers tend to treat as an afterthought while they build everything above it.

Why agent discovery is infrastructure multi-agent systems cannot defer

The agents running in production today aren't the short-lived chatbot calls from a few years back. Many now run as always-on services: they plan, invoke outside tools on their own, and keep working with other agents over long stretches of time. That shift changes what "finding another agent" means. Finding another agent becomes a standing operational requirement, the kind of thing that has to work correctly every time, not just most of the time. Research on decentralized agent discovery treats the agent directory as real operating infrastructure, something whose latency, reliability, and message overhead shape everything built on top of it, not just a list that gets checked once during setup. Two older approaches tried to solve this before open standards existed, and both hit a wall. Part of the trouble is that the tools engineers already had weren't built for this. Processes, threads, system calls, files, permissions: these are the building blocks of traditional operating systems, and they all assume behavior that's bounded and predictable. Discovery mechanisms borrowed from older distributed-systems thinking carry assumptions that don't match that reality, so agent discovery needs its own answer, not a repurposed one.

Protocol stack for agent communication

Five open protocols now define how agents talk to each other, and keeping them straight matters, because it's easy to confuse a protocol that invokes a tool with one that discovers a peer, or to confuse coordination with identity. Each piece of the stack handles a different kind of discovery. MCP handles discovery of tools and data inside a single server. A2A handles discovery of peer agents through its Agent Card mechanism, which comes up next. ARD handles discovery of capabilities before an agent ever tries to invoke them, which the section after that covers in full. ANP handles identity and directory lookup at the network level. None of these protocols fully replaces another, because each one answers a question the others don't ask. A survey spanning three decades of agent research gives this some useful historical shape. It traces a path from platform-side coordination in earlier decades, when Multi-Agent Systems handled coordination through the platform itself, through data-side annotation in the Semantic Web era, when meaning was encoded into the data agents read, to model-side interpretation now, where large language models do the interpreting directly. That survey names discovery mechanism as one of four dimensions separating these generations, which says something: discovery hasn't just changed in its details across thirty years, it's changed in where the work of discovery actually happens.

A2A's Agent Card Mechanism for Discovery

A2A's Agent Card is the clearest, most concrete standard you have today for agent-level discovery. It's a JSON document, served at a fixed address, /.well-known/agent-card.json, that lays out an agent's name, description, version, capabilities, skills, supported interfaces, and security schemes. Any other agent that finds this document can read it and start working with that agent, without needing to be configured ahead of time for that specific connection. Once two agents are talking, A2A runs the conversation over HTTP. A coordinator sends a structured task request, and the agent on the receiving end can answer right away, stream a response back piece by piece, or run the task in the background and report later. The Agent Card is the contract that sets the terms for everything that follows, including what kind of response to expect and how to ask for it. As A2A moved toward production readiness, it added signed Agent Cards, giving the protocol a way to cryptographically verify that a card actually came from the agent it claims to represent. Here's what A2A was never built to solve. The protocol defines how an agent announces itself and how another agent calls on it once that first agent has been found. It says nothing about how an agent is supposed to search a large, mixed, cross-organizational environment to find the right card. That search problem sits a layer below A2A, and it stayed unsolved even as the protocol ecosystem around A2A consolidated. By August 2025, ACP, a project started by IBM Research, had merged into A2A. ACP's merger left pre-invocation discovery unaddressed. Knowing how to talk to an agent once you've found it is a different problem from finding it, and A2A was never designed to solve the second one.

How the Agentic Resource Discovery specification addresses pre-invocation discovery

The gap A2A leaves open, finding the right Agent Card in a sprawling cross-organizational environment before ever invoking anything, is what the Agentic Resource Discovery specification, or ARD, was built to close. Google and a long list of industry partners announced ARD as an open standard, and it lets agents discover and verify outside tools, APIs, skills, and other agents across organizational lines. ARD runs on two core pieces. The first is the catalog: an organization publishes a machine-readable file, called ard.json, inside its own domain, listing the tools, APIs, skills, and agent endpoints it makes available. Trust isn't something ARD adds on afterward. The specification builds in domain-based ownership and verification, so an agent can check that a capability it found really does belong to the organization claiming to offer it, before it connects to anything. That means a team with an existing MCP integration can add ARD for discovery without ripping out and replacing the execution layer underneath it. None of this makes ARD a finished answer. The standard doesn't guarantee uniform quality on its own; it guarantees a shared format for organizations to publish into.

The P2P infrastructure layer beneath the protocol standards: structured overlays versus gossip under two-level churn

A question shapes whether any discovery mechanism, A2A, ARD, or anything built after them, holds up at scale: how agents find each other across a peer-to-peer network before any protocol layer comes into play. The two broad families here are structured overlays, built on distributed hash tables, and gossip-based overlays, where nodes exchange information informally with neighbors. Neither one is simply better. Each exposes a different balance of reliability against overhead, and the one that fits depends on the churn conditions a given deployment actually faces. Research into decentralized agent discovery under what's called two-level churn draws a distinction that older distributed-systems work never had to make. Node-level churn is just hosts joining and leaving a network, and classic systems were built to handle that. Agent-level churn, agents switching on, switching off, and changing state while the host underneath stays put, is something new, and it compounds with node churn. That interaction reshapes the usual tradeoff between structured and gossip-based designs. Structured overlays, with Kademlia studied as the representative case, hold up better and run more efficiently when conditions are stable or when node churn is the dominant source of disruption. A companion study widens the comparison to three DHT families, Chord, Pastry, and Kademlia, tested across cloud, edge, and intermittently connected environments. What matters is the reliability-and-cost tradeoff it produces under conditions that resemble a real deployment. AGNTCY's Agent Directory Service treats this kind of decentralized discovery as a core architectural piece and has put a Kademlia-oriented design on its own implementation roadmap, which gives this comparison a real production stake. In continuum deployments, spanning cloud, edge, and connections that come and go, a missed lookup doesn't just disappear quietly. The practical point for engineers: pick the overlay family before tuning the implementation. That family-level choice decides which failure modes can be fixed later and which control-plane costs are locked in from the start. It isn't a decision to put off until operations is already running the system.

How the two-level churn model changes discovery reliability

Agent-level churn doesn't look like a failure in the places engineers normally check. A host can be fully healthy and respond to every health check, while every agent running on it has gone cold. From the infrastructure layer, that looks like availability. From the discovery layer, it looks like a failed lookup. Standard distributed-systems monitoring wasn't built to catch that gap: treating agent churn the same way as node churn produces systems that look fine on a dashboard while a failed lookup at the discovery layer goes undetected. The two-level churn research breaks this down into four regimes: stable, node-churn-only, agent-cooling-only, and combined. Three metrics together describe how a discovery system is actually performing: discovery success and recall, how many messages a query takes to resolve, and P95 query latency. The practical response is to treat agent-state transitions, warm, cold, deactivated, as signals the discovery layer watches directly, rather than guessing at agent availability from whether the host is up. That requires the agent runtime itself to expose its state to the discovery layer, and that's a form of architectural coupling that most retrofitted tooling simply doesn't offer out of the box. Building it in has to be a deliberate decision, not something assumed to come for free.

Trust and verification as structural requirements of discovery

Any agent that can discover a peer can, under the wrong conditions, be pointed toward a malicious one instead. That's the reason trust and identity verification have to be designed into the discovery layer from the start, and it's why both ARD and A2A built verification into their core as a mandatory part of the system. A2A's move to signed Agent Cards closes a specific hole: an unsigned JSON file sitting at a predictable, well-known path can be copied, altered, or swapped out by anyone who finds it. Signing ties the card to the identity that issued it, so an impersonation attempt becomes detectable. ARD follows the same logic one layer up, at the catalog level. That check matters most when the thing being discovered is capable of triggering real actions against outside systems. DHT-based overlays face a harder version of this problem, because no central authority sits above the network to check who's allowed to answer for which identifier. The overlay just routes a query to whoever holds the matching hash. That structure leaves room for a Sybil attack, where many malicious nodes claim to service the same identifier, and nothing in the DHT itself prevents that without a verification layer added on top. What's changed across those three generations is the attack surface, not the underlying requirement. Regulation is starting to catch up to this reality too. Together they're creating pressure that will likely turn verifiable discovery, where an agent can show where every capability it used came from, into a governance expectation.

Decisions engineers building multi-agent systems should make today, and their order

The order these decisions get made in matters as much as the decisions themselves. Choosing the infrastructure overlay first, then the protocol layer, then the trust model, keeps a team from locking in the wrong foundation before they've even worked out what the system needs from the protocols running on top of it.

First comes overlay architecture. Figure out the dominant churn regime the deployment will actually face, then choose between a structured, DHT-based overlay and a gossip-based one. A system spread across cloud, edge, and intermittently connected environments, facing both node churn and agent churn, should lean toward a Kademlia-family structured overlay, accepting higher control-plane overhead as the cost of better reliability. This is the budget line to plan for, not a detail to revisit after launch.

Second comes the protocol layer. Use A2A for agent-to-agent coordination, with signed Agent Cards turned on from the start. Use MCP for tool and data access. Bring in ARD if the system needs to find capabilities that live outside any registry it already knows about. The consolidation that produced A2A v1.0 and the Agentic AI Foundation lowers the risk of betting on a standard that gets abandoned, but ARD itself is still early in its community development, so it makes sense to adopt it for discovery catalogs while budgeting time for its schema to keep changing.

Third comes the trust model. Treat agent-state transitions, warm, cold, deactivated, as signals the discovery layer tracks directly. Require signed Agent Cards everywhere. Build in domain-based verification for any capability you discover outside the system's own boundary. You need visibility into state and provenance; it's a basic operating requirement, not a nice extra.

Fourth comes the runtime substrate underneath all of it. Choose infrastructure that surfaces agent state directly to the discovery layer, rather than infrastructure that guesses at agent availability from host health. If you build systems specifically around agents, with discovery treated as a core runtime concern from day one, you avoid the coupling problem that comes from retrofitting this behavior onto cloud tooling that was never designed with agents in mind.

Getting this sequence wrong rarely causes a build failure; instead, the system works fine in development, then comes apart under real production churn, sending engineers on a debugging trail that eventually leads back to an infrastructure decision made before anyone understood what the protocols running on top of it would actually need.