How AI Agents Discover Each Other

A common complaint in developer threads is that there is no good way to find agents scattered across GitHub repos, registries, and random subdomains. It 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 leaves much of the question of where those cards live and how agents find them to each deployment.

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 handles agent discovery with a built-in registry, human-readable hostnames, descriptive tags, a directory of service agents, and runtime self-discovery -- and how this compares to the alternatives. For a broader walkthrough of decentralized approaches -- DHT records, semantic taxonomies, and multi-factor trust verification -- see the step-by-step AI agent discovery process guide for P2P networks.

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 automatic registration, liveness, descriptive tags and private-by-default visibility. Search by capability is covered for one part of the network, the service agents, by a separate directory.

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 and then sends a heartbeat every 60 seconds. pilotctl lookup shows when a node was last seen; a node whose heartbeats stop is counted as offline after 30 minutes by default.

# Agent automatically registers on daemon start
$ pilotctl daemon start
Daemon running (pid 48211)
  Address:  0:0000.0000.0003
  Hostname: agent-alpha
  Socket:   /tmp/pilot.sock
  Logs:     ~/.pilot/pilot-48211.log

The registry is not in the data path. After two agents discover each other, they communicate directly over encrypted UDP tunnels. The registry is only consulted during initial lookup.

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 (lowercase letters, digits and hyphens, up to 63 characters; a few names such as localhost are reserved) and must be unique on the registry.

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

# Or change it later
$ pilotctl set-hostname analytics-primary
hostname set: analytics-primary

# Other agents look up by hostname
$ pilotctl find analytics-primary
Hostname:  analytics-primary
Node ID:   18
Address:   0:0000.0000.0012
Visible:   public

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. A lookup succeeds when the node is public, when you share a network with it, or when it already trusts you; a private node's hostname does not resolve for strangers.

Programs resolve hostnames the same way, through the local daemon: pilotctl find on the command line, or ResolveHostname in the Go driver (and its equivalent in the Node and Python SDKs).

Tags: Capability Labels for Discovery

Tags are short 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 skills, data sources, or regions. A node carries up to three, made of lowercase letters, digits and hyphens.

# Set tags on your agent (up to three)
$ pilotctl extras set-tags nlp summarization english
tags set: #nlp #summarization #english

# Tags appear in the node's registry record
$ pilotctl lookup analytics-primary

Tags describe; they are not a search index. They show up in pilotctl lookup and in a network's member list, so an agent that has already found a peer can read what it says it does. There is no network-wide search by tag.

Search by capability exists for one kind of agent: the service agents. list-agents is a curated directory of the roughly 430 data service agents on the public backbone (weather, finance, news, transit, science and more), and it matches a query against each agent's hostname, category and description. This is the "What can you do?" layer that DNS lacks, for the agents in that catalogue.

Your own agents are found by name or address: pilotctl find for a known hostname, an address passed in configuration, or the member list of a network you share. Private agents never appear in any directory. pilotctl peers --search only filters the peers you are already connected to, by node ID.

Capability Discovery in Practice

Directory discovery becomes useful when agents use it programmatically. The reply from list-agents is structured JSON that agents can parse directly.

# Programmatic discovery: find a service agent for weather forecasts
$ pilotctl --json send-message list-agents --data '/data {"search":"weather forecast"}' --wait
# one entry from the reply's "items" array
{
  "address": "0:0000.0000.4BB9",
  "hostname": "open-meteo-forecast",
  "category": "weather",
  "description": "Open-Meteo global weather forecast: hourly+daily T/precip/wind/humidity/clouds/etc per lat/lon, ≤16d.",
  "example": "/data {\"latitude\": 1.0, \"longitude\": 1.0}"
}

An agent can parse this JSON and choose an agent for the job from the category and description fields; the example field shows the query shape the agent accepts. This is runtime service discovery that happens without a service mesh, without Consul, and without any infrastructure beyond the Pilot directory service.

Combining Discovery With Trust

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

# 1. Discover an agent with the capability you need
$ pilotctl send-message list-agents --data '/data {"search":"weather forecast"}' --wait

# 2. Initiate a handshake with the best candidate
$ pilotctl handshake open-meteo-forecast "Need forecasts for delivery planning"

# 3. After approval, query it over the encrypted tunnel
$ pilotctl send-message open-meteo-forecast --data '/data {"latitude": 52.52, "longitude": 13.41}' --wait

The discovery phase is open (searching a public directory), but the communication phase is gated by the zero trust handshake. Most service agents approve handshakes automatically; your own agents decide for themselves. The same holds between your own agents: resolving a hostname gives you an address, not access.

The Registry as a Public Directory

For agents that want maximum visibility, the Pilot registry offers public mode. After pilotctl set-public, anyone can resolve the agent's hostname and read its registry record: address, tags and when it was last seen.

The registry is not a browsable catalogue, though: you reach a public agent through its hostname or address. The browsable catalogue is list-agents, and it is curated: it lists the service agents, not every public node.

Private agents (the default) resolve only for peers that trust them or share a network with them -- the registry enforces the same visibility rules for all clients. There is no way to enumerate private agents through the CLI or the API.

For organizations that want a private network, see Building a Private Agent Network for Your Company.

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 info command (excerpt):

$ pilotctl --json info
{
  "status": "ok",
  "data": {
    "node_id": 3,
    "address": "0:0000.0000.0003",
    "hostname": "agent-alpha",
    "public_key": "3b7f...a91c",
    "uptime_secs": 16320,
    "peers": 7,
    "encrypted_peers": 7,
    "relay_peer_count": 2,
    "handshake_pending_count": 1,
    ...
  }
}

This is the agent's view of itself. It knows its virtual address and hostname, how many peers it has, how many of them it reaches through the relay, and whether handshake requests are waiting for a decision. The peers it trusts are listed by pilotctl trust, and its own tags by a pilotctl lookup of its own address. An LLM-powered agent can use this context to make decisions: "I have a pending handshake. I should review it before accepting new work." (pilotctl context is a different command: it prints the CLI's command catalogue for agent tools.)

Self-discovery also enables agents to detect connectivity problems early. The daemon does not classify its NAT type, but if most peers show up as relayed, the agent knows its traffic goes through the beacon 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 Agent Name Service (ANS) draft is an 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. Pilot's registry handles naming, registration and liveness today, in shipping code, after an install command and pilotctl daemon start.

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: Name the agent and start it - automatic registration
$ pilotctl init --hostname data-cruncher
$ pilotctl daemon start
Daemon running (pid 51007)
  Address:  0:0000.0000.0050
  Hostname: data-cruncher
  ...

# Step 2: Describe capabilities via tags
$ pilotctl extras set-tags data-analysis python gpu

# Step 3: Resolve the peer you need by name
$ pilotctl find chart-maker
Hostname:  chart-maker
Node ID:   51
Address:   0:0000.0000.0033
Visible:   public

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

# Step 5: After approval, collaborate
$ pilotctl send-file chart-maker analysis-results.json
# files the peer sends back land in ~/.pilot/received/
$ pilotctl received

Every step is a single command. There is no service mesh to deploy and no DNS records to create. The registry handles registration and liveness. Tags describe capabilities. 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.