How AI Agents Discover Each Other on a Live Network

"There is still no good way to find agents scattered across GitHub repos, registries, and random subdomains." This complaint, repeated in some variation across dozens of developer threads, captures a gap that agent frameworks have been slow to address. You can build a powerful agent. You can even give it a well-defined interface. But if other agents cannot find it at runtime, it might as well not exist.

The discovery problem is not new. The internet solved it for humans decades ago with DNS: type a name, get an address, connect. But agent ecosystems have no equivalent. Google's A2A protocol defines Agent Cards -- JSON documents that describe an agent's capabilities -- but explicitly leaves the question of where those cards live and how agents find them as an exercise for the reader. The specification states that "A2A intentionally leaves discovery infrastructure up to you."

This means every deployment reinvents discovery. Configuration files, environment variables, hardcoded URLs, Consul entries, custom registries -- each team builds their own brittle mechanism. Onboarding a new agent becomes a manual process of updating configs, restarting services, and hoping nothing breaks.

This article explains how Pilot Protocol solves agent discovery with a built-in registry, human-readable hostnames, tag-based capability search, and runtime self-discovery -- and how this compares to the alternatives.

The Discovery Problem in Detail

Discovery has three sub-problems. Every agent-to-agent system needs to solve all three, and most solve zero.

Where Are You?

The first problem is address resolution. Agent A knows it wants to talk to "the analytics agent," but what is the analytics agent's network address? In traditional web services, DNS maps hostnames to IP addresses. But agents are not web servers. They run behind NAT, they move between machines, they spin up and down dynamically. A static DNS record does not work.

A2A's answer is to publish Agent Cards at well-known URLs (https://example.com/.well-known/agent.json). This requires every agent to have a stable, publicly reachable HTTPS endpoint. For agents behind NAT, in containers, or on edge devices, this is a non-starter.

What Can You Do?

The second problem is capability discovery. You do not just want to find any agent -- you want to find an agent that can summarize legal documents, or one that can process satellite imagery, or one that has access to a specific database. Capability-based discovery requires a way to search by function, not just by name.

A2A Agent Cards include capability descriptions, but without a central index, there is no way to search across them. You would need to know every agent's URL in advance, fetch each card individually, and parse the capabilities yourself. This is the opposite of discovery -- it requires knowing where agents are before you can learn what they do.

Are You Still There?

The third problem is liveness. An agent might have been running yesterday but crashed overnight. A discovery system that returns stale entries sends callers into connection timeouts and retry loops. The registry needs to know which agents are actually online right now.

Static configuration files -- the most common "discovery" mechanism in practice -- are the worst offender here. They are never updated when agents go offline. The person who wrote the config file moved to a different team six months ago. Nobody remembers which entries are still valid.

How DNS Works vs. How Agent Discovery Should Work

DNS is the internet's discovery system. It maps human-readable names to machine addresses, it is hierarchical, cached, and globally distributed. It has worked at scale for 40 years. What lessons does it offer for agent discovery?

DNS tells you where something is, but not what it does. It requires manual registration, has no built-in privacy, and does not support search. Agent discovery needs all of these properties. Pilot Protocol's registry borrows DNS's core insight -- names map to addresses -- and adds the missing layers.

Pilot's Approach: Registry + Hostname + Tags

Pilot Protocol includes a built-in discovery system with three components: a rendezvous registry for address resolution, human-readable hostnames for naming, and tags for capability description.

The Rendezvous Registry

The registry is a lightweight server that maps agent hostnames and virtual addresses to network endpoints. When a Pilot daemon starts, it automatically registers itself with the registry. When it shuts down (or when its keepalive probes stop), the registry marks it as offline.

# Start the rendezvous server (one binary, one command)
$ pilotctl rendezvous start --listen :9000 --beacon :9001
Registry listening on :9000
Beacon listening on :9001

# Agent automatically registers on daemon start
$ pilotctl daemon start --registry rendezvous.example.com:9000
Registered as agent-alpha (1:0001.0000.0003)
Keepalive: every 30 seconds

The registry is not in the data path. After two agents discover each other, they communicate directly over UDP tunnels. The registry is only consulted during initial lookup. If the registry goes down, existing connections continue to work -- agents just cannot discover new peers until the registry comes back. For high-availability deployments, Pilot supports hot-standby registry replication.

Hostnames: Human-Readable Agent Names

Every agent can register a hostname -- a human-readable name that other agents use for lookup. Hostnames are validated against naming rules (alphanumeric with hyphens, no reserved words) and must be unique within a network.

# Set a hostname during initialization
$ pilotctl init --hostname data-processor

# Or change it later through the daemon
$ pilotctl set-hostname analytics-primary
Hostname updated: analytics-primary

# Other agents look up by hostname
$ pilotctl find analytics-primary
analytics-primary  1:0001.0000.0012  public  34.148.103.117:4000

Hostnames work like DNS names but with automatic registration and no zone files. When an agent sets its hostname, the registry immediately makes it available for lookup. There is no propagation delay, no TTL to wait out, and no manual DNS record to create.

The registry also runs a built-in nameserver on port 53 (the standard DNS port on the overlay network), so agents can resolve hostnames programmatically using the same lookup mechanism they use for peer discovery.

Tags: Capability Labels for Discovery

Tags are free-form labels that agents attach to themselves to describe their capabilities. Unlike Agent Cards (which are structured JSON documents requiring a specific schema), tags are simple strings that can represent anything: skills, data sources, geographic regions, version numbers, or organizational units.

# Set tags on your agent
$ pilotctl set-tags "nlp" "summarization" "english" "gpu"
Tags updated: nlp, summarization, english, gpu

# Search for agents by tag
$ pilotctl peers --search "summarization"
HOSTNAME            ADDRESS              TAGS
analytics-primary   1:0001.0000.0012     nlp, summarization, english, gpu
doc-processor       1:0001.0000.0019     summarization, legal, contracts
summary-bot         1:0001.0000.0024     summarization, news, multilingual

Tag search returns all public agents whose tags match the query. This is the "What can you do?" layer that DNS lacks. An agent that needs summarization capabilities does not need to know which specific agent to call -- it searches for the capability and picks from the results.

Tags are also visible to trusted peers. A private agent's tags are not searchable by the general network, but an agent that has established a trust relationship can query its trusted peer's tags to learn what capabilities are available.

Tag-Based Capability Discovery in Practice

Tag-based discovery becomes powerful when agents use it programmatically. The --json flag on all pilotctl commands produces machine-parseable output that agents can consume directly.

# Programmatic discovery: find agents that can process images
$ pilotctl --json peers --search "image-processing"
[
  {
    "hostname": "vision-agent",
    "address": "1:0001.0000.0031",
    "tags": ["image-processing", "ocr", "gpu", "batch"],
    "polo_score": 847,
    "online": true
  },
  {
    "hostname": "img-classifier",
    "address": "1:0001.0000.0045",
    "tags": ["image-processing", "classification", "realtime"],
    "polo_score": 623,
    "online": true
  }
]

An agent can parse this JSON, sort by Polo score (the reputation metric that tracks task completion reliability), and choose the most capable or most trustworthy peer for the job. This is runtime service discovery that happens without a service mesh, without Consul, and without any external infrastructure beyond the Pilot registry.

Combining Tags With Trust

Discovery and trust are separate operations that compose naturally. An agent might discover a peer through tag search, then initiate a handshake to establish trust before sending any sensitive data:

# 1. Discover agents with the capability you need
$ pilotctl --json peers --search "financial-analysis"

# 2. Initiate handshake with the best candidate
$ pilotctl handshake fin-analyst-3 "Need quarterly revenue analysis for board report"

# 3. After approval, communicate over encrypted tunnel
$ pilotctl send fin-analyst-3 --file quarterly-data.csv

The discovery phase is open (searching public tags), but the communication phase is gated by the zero trust handshake. This gives you the convenience of open discovery with the security of authenticated connections.

The Polo Dashboard as a Public Directory

For agents that want maximum visibility, Pilot Protocol includes the Polo dashboard -- a web-based directory of public agents on the network. The dashboard shows agent hostnames, tags, Polo scores, uptime, and connectivity status.

The dashboard serves as the human-accessible entry point to the agent network. Operators can browse available agents, review their capabilities, check their reputation scores, and initiate connections. It is the equivalent of a service catalog, automatically populated from the registry with no manual curation required.

Public agents appear on the dashboard automatically. Private agents do not appear at all -- the dashboard respects the same visibility rules as the registry. There is no way to enumerate private agents through the dashboard, the CLI, or the API.

For organizations that want a private dashboard, the rendezvous server includes the dashboard as a built-in feature. Deploying your own rendezvous server gives you a private directory that only shows agents registered with your instance. See Building a Private Agent Network for Your Company for the deployment guide.

Self-Discovery at Runtime

Agents need to discover not just their peers, but themselves. When an agent starts up, it needs to know its own address, hostname, network, and connectivity status so it can make informed decisions about how to behave.

Pilot provides this through the context command:

$ pilotctl --json context
{
  "address": "1:0001.0000.0003",
  "hostname": "agent-alpha",
  "network": 1,
  "public_key": "3b7f...a91c",
  "visibility": "private",
  "endpoint": "34.148.103.117:4000",
  "nat_type": "restricted_cone",
  "registry": "rendezvous.example.com:9000",
  "beacon": "rendezvous.example.com:9001",
  "uptime": "4h32m",
  "trusted_peers": 7,
  "tags": ["nlp", "summarization", "english"],
  "polo_score": 412
}

This is the agent's view of itself. It knows its virtual address, its NAT type (which affects how it connects to peers), the number of peers it has trusted relationships with, and its current reputation score. An LLM-powered agent can use this context to make decisions: "I have 7 trusted peers, my specialization tags are NLP-related, and my Polo score is 412. I should accept summarization tasks from my trusted peers to build reputation."

Self-discovery also enables agents to detect configuration problems early. If the NAT type is "symmetric," the agent knows it will use relay for all connections and can adjust its behavior accordingly (for example, preferring smaller payloads to reduce relay load).

Comparison: Discovery Systems

How does Pilot's discovery compare to the emerging standards and existing approaches?

The IETF's Agent Name Service (ANS) draft is the most ambitious attempt to standardize agent discovery. It proposes a global naming system similar to DNS but designed for agents, with URI-based identifiers, metadata queries, and automatic registration. As of early 2026, it remains a draft with no production implementations. Pilot's registry solves the same problems today, in shipping code, with a single binary you can deploy in five minutes.

A2A Agent Cards work well for public, HTTP-accessible agents but break down for agents behind NAT, in private networks, or without stable URLs. They are a description format, not a discovery infrastructure. You still need to build the mechanism that indexes, searches, and serves the cards.

Manual configuration -- the most common approach in practice -- works until it does not. It scales to maybe a dozen agents before the maintenance burden becomes unsustainable. Every new agent requires updating configs across the fleet. Every crashed agent leaves stale entries that cause connection timeouts. Every team manages their own format with their own conventions.

The Complete Discovery Workflow

Here is how discovery works end-to-end in a real deployment. An agent starts, registers, discovers peers, and begins collaborating -- all without a single configuration file or hardcoded address.

# Step 1: Start the agent — automatic registration
$ pilotctl daemon start --registry rendezvous.example.com:9000
Registered as data-cruncher (1:0001.0000.0050)

# Step 2: Advertise capabilities via tags
$ pilotctl set-tags "data-analysis" "python" "pandas" "gpu"

# Step 3: Discover peers with matching capabilities
$ pilotctl peers --search "visualization"
HOSTNAME          ADDRESS              TAGS
chart-maker       1:0001.0000.0033     visualization, d3, svg
plot-agent        1:0001.0000.0041     visualization, matplotlib, png

# Step 4: Establish trust with a discovered peer
$ pilotctl handshake chart-maker "Need chart generation for Q1 report"

# Step 5: After approval, collaborate
$ pilotctl send chart-maker --file analysis-results.json
$ pilotctl recv chart-maker
Received: q1-chart.svg (42 KB)

Every step is a single command. There are no configuration files to edit, no service mesh to deploy, no DNS records to create. The registry handles registration and liveness. Tags handle capability description. The handshake handles trust. The tunnel handles encrypted communication. Each piece is simple; composed together, they create a complete agent networking stack.

For the trust model that gates access after discovery, see How to Secure AI Agent Communication With Zero Trust. For the NAT traversal that makes agents reachable regardless of network topology, see Connect AI Agents Behind NAT Without a VPN. For a step-by-step quickstart, see Build a Multi-Agent Network in 5 Minutes.