SXF GUIDE / AGENTIC INTERNET
AI Agent Discovery:
How Will AI Agents Find Each Other?
AI agent discovery is becoming a missing infrastructure layer of the agentic web. A capable autonomous system may know what it wants done without knowing which agent, tool or service can do it. The discovery problem begins with “what exists?” but quickly expands into capability matching, protocol compatibility, identity, freshness, trust, cost, reputation and routing. In 2026, A2A Agent Cards, the official MCP Registry, DNS-AID, ADP, AINS, new registry protocols and capability-search research began attacking different pieces of the same question: how does one machine find the right machine to work with?
How will AI agents find each other? Through a discovery stack—not one universal directory.
Today, an AI agent can discover another agent through several mechanisms: direct configuration, an A2A Agent Card at a well-known URL, a central or federated registry, enterprise catalogs, semantic capability search, and emerging DNS- or name-service-based proposals. A2A now standardizes the machine-readable Agent Card and permanently registers /.well-known/agent-card.json, while multiple 2026 Internet-Drafts explore DNS discovery, agent registries and richer naming systems.
But discovery is not trust. An agent that advertises “I can book flights” has only made a claim. A production discovery pipeline must still ask: Is the record fresh? Is the endpoint authentic? Does the agent actually support the task? Is it compatible with my protocol and security requirements? What evidence supports its claims? Is it authorized? And among many candidates, which one should receive the task?
THE PRIMARY KEYWORD / THE CORE PROBLEM
What is AI agent discovery?
AI agent discovery is the process of locating autonomous agents and retrieving enough machine-readable information to determine whether they are candidates for a task.
A basic discovery system can answer:
A useful discovery system must answer much more:
- What is the agent called?
- Which organization or operator publishes it?
- What capabilities and skills does it claim?
- Which endpoint and protocol should a client use?
- What authentication does interaction require?
- Which input and output formats are supported?
- Is the record current?
- What evidence supports the claims?
- Can this agent be used in the current policy context?
- If hundreds of agents qualify, which candidate should be selected?
This makes agent discovery partly a naming problem, partly a service-discovery problem, partly an information-retrieval problem and partly a trust problem.
FROM KNOWN ENDPOINTS TO AN OPEN AGENT ECOSYSTEM
Why agent discovery becomes infrastructure when agents stop being hard-coded
Early agent systems are often built around known relationships: a developer configures a model, a fixed set of tools, perhaps a few sub-agents, and every endpoint is known in advance.
That architecture breaks when the task becomes open-ended:
“Find a customs-compliance agent that supports EU imports and can return a cited report.”
“Find a freight agent that can quote Berlin → Shanghai and transact under €2,000.”
“Find a specialist agent that understands this codebase's framework and can run inside our security policy.”
The calling agent now knows the capability it needs, but not necessarily the provider, endpoint or protocol.
That is the discovery gap.
A2A's own documentation states the dependency directly: before agents can collaborate, they must find each other and understand the capabilities being offered. In August 2026, A2A joined the Agentic AI Foundation as a Growth Stage project and described its role as a horizontal layer for agents to discover, delegate and collaborate across framework and vendor boundaries.
THREE PROBLEMS THAT SHOULD NOT BE COLLAPSED
Agent discovery vs agent routing vs agent authorization
| Stage | Question | Example |
|---|---|---|
| Discovery | Which agents could perform this task? | Find agents advertising freight-quote capability. |
| Resolution | Where is this agent and what is its current metadata? | Resolve endpoints, interfaces, version and current status. |
| Filtering | Which candidates meet hard constraints? | A2A-compatible, EU region, structured JSON output. |
| Ranking | Which candidate is preferable? | Rank by task fit, evidence, cost and latency. |
| Routing | Where should the task be sent? | Select Agent B and invoke its preferred endpoint. |
| Authorization | Is this actor allowed to perform the requested action? | Agent B may quote, but not charge the user's card. |
The distinction is critical. The September 2026 Agent Registry Protocol draft explicitly preserves the rule that discovering an agent does not imply authorization to invoke it. That is the same separation SXF uses in the AI Agent Authorization reference.
THE DISCOVERY RECORD
What information does one AI agent need about another?
There is no universal record format, but current protocols converge around a common set of fields.
Name, provider, stable identifier or verifiable publisher relationship.
What the agent says it can do and which skills or task domains it exposes.
Where the agent can be reached and which interface should be preferred.
A2A, proprietary API, messaging mode, versions and extensions.
Authentication schemes and access requirements.
Accepted and returned content types or modalities.
Current version, status, availability and freshness.
Signatures, attestations, registry provenance, execution history or other trust signals.
Discovery therefore produces a candidate description. It should not be confused with a guarantee that the agent is competent, trustworthy or authorized.
THE MOST CONCRETE DISCOVERY PRIMITIVE TODAY
What is an A2A Agent Card?
An A2A Agent Card is a JSON document that acts as a machine-readable description of a remote A2A agent.
The current A2A specification includes information such as:
- the agent's name, description and provider-facing metadata;
- supported interfaces and endpoints;
- protocol binding and version;
- capabilities;
- skills;
- supported input and output media types;
- security schemes and requirements;
- and optional signatures.
That makes the Agent Card closer to a machine-readable service manifest than a marketing profile.
Another agent can fetch the card, inspect it and decide whether the advertised agent is even structurally compatible before starting a task.
ONE URL THAT MATTERS
A2A permanently registers /.well-known/agent-card.json
The A2A specification registers the well-known URI suffix agent-card.json. A public A2A agent can therefore expose its card at:
This is important because it standardizes where to look once a domain is known.
That solves a narrower problem than global search. If an agent knows the domain of a potential provider, it can retrieve the card without proprietary discovery code.
It does not solve:
- How do I discover the domain in the first place?
- How do I find every agent capable of task X?
- How do I compare thousands of Agent Cards?
- How do I know a self-declared skill is true?
Those questions create the need for registries, search indexes, DNS discovery and trust layers.
INTEGRITY IS NOT REPUTATION
Signed Agent Cards help prove integrity—but a signature cannot prove capability
A2A supports Agent Card signatures using JSON Web Signature (JWS). The specification describes how clients can verify signatures and recommends verifying at least one signature when signatures are present.
This can help answer:
A valid signature can provide useful integrity and publisher evidence.
A signature does not independently prove performance, safety or task competence.
A malicious or low-quality agent can sign an inaccurate self-description perfectly.
Discovery systems therefore need to treat signed metadata as one signal in a larger trust decision.
A2A DOES NOT REQUIRE ONE GLOBAL DIRECTORY
Three practical A2A discovery patterns
A2A documentation describes multiple strategies because discovery requirements differ between the open internet and private systems.
Well-known URI
Best when the client already knows a domain. Fetch the Agent Card from the standardized URL and evaluate the advertised interfaces and skills.
Registry / catalog discovery
Useful when clients need to search a population of agents by capability, provider, policy or other metadata rather than knowing the endpoint in advance.
Direct / private configuration
Useful for tightly controlled relationships where clients are configured with known Agent Cards or private discovery endpoints.
A mature ecosystem will likely use all three. Private enterprise agents do not need to be globally searchable, while public commerce or specialist agents may benefit from broad discovery.
SEARCH NEEDS AN INDEX
What is an AI agent registry?
An AI agent registry is a service that publishes, indexes or resolves records about agents.
Depending on the design, a registry may expose:
- agent identifiers;
- versions and deployments;
- capabilities and skills;
- endpoints;
- operators or publishers;
- protocol compatibility;
- lifecycle status;
- authority or relationship references;
- trust evidence;
- and search APIs.
The key architectural choice is whether the registry is:
| Model | Strength | Main risk / tradeoff |
|---|---|---|
| Central catalog | Easy search, indexing and ranking. | Central governance, moderation and availability dependency. |
| Federated registries | Multiple operators and specialized trust domains. | Conflicting records, duplicate identities and ranking complexity. |
| DNS / domain-based | Reuses globally deployed naming infrastructure and domain control. | Capability search and rich ranking require additional layers. |
| Enterprise directory | Strong local policy and privacy. | Poor global discoverability. |
| Marketplace | Can combine discovery with price, reviews and transactions. | Economic incentives can distort rankings and trust signals. |
TOOLS AND AGENTS ARE DIFFERENT DISCOVERY TARGETS
The official MCP Registry shows what machine-readable discovery already looks like
The official MCP Registry is a community-driven catalog and API for discovering publicly available Model Context Protocol servers.
Its original launch described it as a primary source of truth from which public and private sub-registries could derive richer, opinionated catalogs.
That is relevant to agent discovery even though MCP servers are not synonymous with autonomous agents.
Vertical integration: give an agent capabilities, APIs and data.
Horizontal collaboration: discover another autonomous actor and delegate work.
Future orchestrators may need to query both kinds of ecosystem: “Do I need a tool, a specialist agent, or either?”
CAN DNS BECOME AN AGENT DISCOVERY LAYER?
DNS-AID: publishing AI agents through the Domain Name System
The active DNS for AI Discovery (DNS-AID) Internet-Draft proposes using DNS to publish information that helps other agents discover AI services.
The May 2026 revision describes three increasingly difficult lookup situations:
- the requester knows both the organization and agent;
- the requester knows the organization but not which of its agents offers the required capability;
- the requester knows only the capability and not the organization or agent.
The draft focuses primarily on the first two. Global capability search is a broader indexing problem.
The attraction is obvious: DNS already provides globally distributed, cached, administratively delegated naming infrastructure.
DNS-AID does not magically turn DNS into Google for agents. It can provide a scalable route into discovery, while richer capability retrieval and ranking happen above it.
RESEARCH / INTERNET-SCALE FEASIBILITY
A 2026 study tested the case for DNS using 119,757 real-world service endpoints
A June 2026 preprint, Discovering Agents for Discovery: The Case for DNS, frames agent discoverability around three criteria: navigational completeness, lookup complexity and transaction performance.
The researchers evaluated metadata requirements using 119,757 real-world service endpoints and multiple agent-tooling ecosystems. Their results argue that the relevant discovery data can fit within the scale of a DNS transaction and that DNS offers a plausible foundation for low-latency discovery.
This is not proof that DNS-AID will become the winner. It is evidence that internet-scale agent discovery does not necessarily require replacing the internet's naming substrate.
A LAYERED DISCOVERY PROPOSAL
Agent Discovery Protocol (ADP): DNS → metadata → interaction
The June 2026 Agent Discovery Protocol (ADP) v1.1 Internet-Draft proposes a layered architecture:
Find the path toward the agent or capability provider.
Retrieve machine-readable description and identity material.
Escalate to a real-time WebSocket interaction layer when needed.
The design principle is incremental cost: use lightweight discovery first, then fetch richer metadata and open interactive channels only when the workflow requires them.
ADP is an Internet-Draft and should be treated as work in progress, not as an established standard.
A NAME SERVICE FOR RICH AGENT OBJECTS
AINS: what if agent names resolve to capabilities, routes and evidence?
The September 24, 2026 AINS: AInternet Name Service draft proposes a transport-independent logical namespace for agents and an HTTPS-based resolution protocol.
Unlike ordinary DNS name-to-address resolution, AINS records are designed to map agent identifiers to richer metadata including:
- identity information;
- capabilities;
- endpoints;
- route-provider metadata;
- route posture;
- and references to cryptographic evidence.
This represents a different philosophy from DNS-AID.
Leverage existing domain administration, caching and network infrastructure.
Resolve agent-centric objects that carry capabilities, routing posture and evidence references.
Both are current proposals, not settled internet architecture.
THE REGISTRY IS STARTING TO ABSORB TRUST CONTEXT
Agent Registry Protocol (ARPA): discovery plus relationships, lifecycle and evidence
The latest September 2026 revision of the Agent Registry Protocol proposes an HTTP/JSON protocol for agent registration and resolution.
Its scope goes beyond a simple directory. Records may represent:
- persistent agent identifiers and deployment identifiers;
- typed relationships between agents, operators and principals;
- bounded delegated authority;
- capability and assurance references;
- current and historical lifecycle state;
- registry discovery;
- and evidence references.
The draft also makes an architectural distinction worth preserving across the industry:
A registry can provide inputs to trust and authorization. It should not silently become the universal policy engine.
ANOTHER REGISTRY MODEL / DIFFERENT SCOPE
AREG: publishing and resolving agent definitions
The August 2026 Agent Registry (AREG) Internet-Draft proposes an open, vendor-neutral registry specification for publishing, discovering and resolving agent definitions.
An AREG entry can identify:
- where an agent definition can be fetched;
- who published it;
- which version is current;
- and how consumers can verify authenticity.
Its design illustrates an important point: an “agent registry” does not have one universal meaning yet.
Some registries index runnable endpoints. Others index definitions. Others add identity, authority, reputation or marketplace data.
Search engines for agents will need to normalize these differences.
THE HARD CASE IS “I KNOW THE TASK, NOT THE AGENT”
Capability discovery turns agent selection into information retrieval
The easiest discovery query is:
The harder and economically more interesting query is:
Now the system needs semantic retrieval.
The task description may not use the same words as the agent's skill metadata. A user may ask for “validate this supplier's carbon claims” while an agent advertises “Scope 3 emissions evidence verification.”
Keyword equality is not enough.
A scalable discovery engine may need embeddings, enriched capability profiles, taxonomy mapping, filters and learned or policy-driven ranking.
2026 RESEARCH / WHY “PUT THE REGISTRY IN THE PROMPT” DOES NOT SCALE
At thousands of candidates, capability discovery needs retrieve-then-rank architecture
An August 2026 preprint, Enrich-Retrieve-Rank: Scaling Capability Discovery Beyond In-Context Routing, tested discovery across registries of models, agents, tools and skills.
In the reported experiments, an in-context routing baseline's top-1 matching accuracy fell from 0.85 at 10 candidates to 0.12 at 7,278 candidates. The proposed retrieve-then-rank pipeline degraded less severely, reaching 0.39 at full scale, and the authors reported a large cost advantage over placing the full registry in context.
The exact numbers belong to that benchmark, not to every real system. But the architectural lesson is important:
The same research describes a production capability-discovery pipeline that enriches sparse metadata offline, retrieves candidates and then reranks a short list.
FINDING IS NOT BELIEVING
Discovery is not trust
Suppose a registry returns 30 agents that all claim:
Discovery succeeded.
The difficult work has barely started.
A relying agent may still need to evaluate:
- publisher authenticity;
- record freshness;
- capability evidence;
- security posture;
- prior execution results;
- task-specific quality;
- price and latency;
- jurisdiction or data residency;
- and whether the agent is authorized for the intended action.
This is why the future discovery stack will probably separate self-description from independent evidence.
THE TEMPTATION AND THE TRAP
Does every AI agent need a reputation score?
A universal “87/100 trust score” is attractive because it makes ranking easy.
It is also dangerous.
An agent can be excellent at one domain and unreliable in another. A five-star travel agent is not automatically a five-star legal-research agent.
Reputation also creates incentive attacks:
- fake transactions;
- Sybil accounts;
- collusive reviews;
- reputation laundering after version changes;
- and selective publication of successful outcomes.
A September 2026 Internet-Draft called Agent Trust & Execution Passport (ATEP) explores portable, machine-readable execution history and trust metadata derived from append-only logs. It is an early proposal, not an accepted standard.
The more robust direction is likely multidimensional evidence:
| Signal | What it may tell a router |
|---|---|
| Task-domain history | Has the agent succeeded on comparable work? |
| Recency | Are results from the current version or an obsolete build? |
| Verified execution | Can outcomes be linked to evidence rather than self-report? |
| Disputes / failures | How often do transactions fail or get challenged? |
| Security assurance | Which independent controls or attestations apply? |
| Cost / latency | Is the agent operationally suitable for this request? |
DON'T TRUST ONE DIRECTORY JUST BECAUSE IT IS SIGNED
Multi-source corroboration: the registry itself can lie, omit or equivocate
An August 2026 Internet-Draft on Multi-Source Corroboration for AI Agent Discovery starts from an important observation: agents may be represented across independent registries, name services, decentralized identifiers and catalogs.
A single source can:
- omit a record;
- serve stale data;
- show different answers to different observers;
- or publish a signed but misleading artifact.
A cryptographic signature does not solve omission or equivocation by the signer.
For high-impact selection, a discovery engine may therefore compare claims across multiple independent sources before relying on them.
THE DISCOVERY LAYER WILL BECOME AN ATTACK SURFACE
How AI agent discovery can be attacked
Agent spoofing
An attacker publishes a lookalike identifier, domain or endpoint and hopes routers select the wrong agent.
Capability inflation
An agent advertises skills it cannot perform reliably to appear in more discovery queries.
Registry poisoning
Malicious or compromised publishers insert false metadata or redirect endpoints.
Sybil agents
One operator creates many identities to dominate rankings or manufacture reputation.
Stale metadata
A cached card points to an obsolete endpoint, capability, key or security requirement.
Ranking manipulation
Providers optimize metadata, payments or review signals to win selection despite weaker task fit.
Privacy leakage
Public cards or registries reveal internal agents, sensitive skills, topology or business functions.
Trust transference
A router mistakes “listed in a registry” or “signed card” for proof of safety and authority.
A2A documentation itself warns that Agent Cards can expose sensitive URLs or skills and recommends authenticated extended cards or protected endpoints for sensitive metadata.
NOT EVERY AGENT SHOULD BE ON THE OPEN WEB
Private enterprise discovery may be larger than public agent search
Many valuable agents should never be globally indexed:
- finance agents with access to internal ledgers;
- security agents exposing incident-response capabilities;
- HR agents;
- production deployment agents;
- internal research agents;
- agents bound to regulated datasets.
Enterprise discovery therefore needs the same search primitives with stricter policy:
The MCP Registry's architecture already anticipates private sub-registries, while A2A supports protected cards and private discovery patterns.
THE MACHINE WEB WILL NOT HAVE ONE FORMAT
Cross-protocol discovery: the best capability may be an agent, a tool or a service
An orchestrator starts with a task, not a protocol preference.
For “convert these invoices into normalized accounting entries,” the best option might be:
- an A2A specialist agent;
- an MCP server exposing deterministic accounting tools;
- a conventional API;
- or an internal workflow.
A future discovery engine may therefore index heterogeneous capability objects and normalize them into one retrieval layer.
This creates a broader category:
The 2026 retrieve-rank research explicitly evaluates this broader MATS framing—models, agents, tools and skills—rather than assuming discovery ends at agent directories.
SXF REFERENCE MODEL / THE FULL SEARCH PIPELINE
The SXF AI Agent Discovery Stack
Discovery is strongest when treated as a pipeline of separate decisions rather than a single registry lookup.
Do we know a specific agent, a provider, or only the capability required?
Query DNS, a well-known URL, registry, catalog, enterprise directory or federated index.
Retrieve the current card, record, endpoint, version and protocol metadata.
Map the task intent to advertised skills and retrieve plausible candidates.
Reject candidates that fail protocol, region, format, security or policy requirements.
Verify signatures, publisher relationships and record provenance where available.
Evaluate reputation, execution history, attestations, corroboration and freshness.
Determine whether interaction or the eventual action is permitted in the current context.
Order valid candidates by task fit, quality, price, latency, risk and local policy.
Send the task, observe the result and feed verified outcome evidence back into future discovery.
The critical insight is that no single component should silently claim the authority of all ten stages.
ONE IMAGE / THE MACHINE SEARCH LAYER
How an AI agent goes from “I need a capability” to “send the task here”
The image should make one distinction visually unavoidable:
PRODUCTION DESIGN
A production architecture for AI agent discovery
Separate source adapters from the index.
Normalize A2A cards, registries, DNS records, MCP catalogs and enterprise directories into a common internal representation without erasing provenance.
Keep authoritative source links.
Every normalized field should retain where it came from, when it was observed and whether it was self-declared or independently verified.
Enrich offline.
Generate capability embeddings, taxonomies and searchable profiles before requests arrive instead of making each router reason over raw metadata.
Retrieve before reranking.
Use search to reduce thousands of possibilities to a small candidate set, then apply richer model- or policy-based ranking.
Filter hard constraints first.
Protocol, geography, security, permissions, data residency and required formats should not be traded away by a relevance score.
Verify fresh identity and endpoints.
Do not route solely from stale cached metadata when the action is consequential.
Treat reputation as evidence, not truth.
Use task-specific, time-bounded signals and defend against Sybil and collusion attacks.
Keep discovery separate from authorization.
A high-ranked agent must still pass the relevant authorization and policy checks before action.
Record selection rationale.
For high-impact workflows, log why candidates were retrieved, rejected, ranked and selected.
Feed verified outcomes back carefully.
Update future ranking from evidence-backed results rather than raw self-reported success.
MATURITY MAP / OCTOBER 2026
What is actually standardized in AI agent discovery?
| Technology | Status | What it solves |
|---|---|---|
| A2A Agent Card | A2A standard | Machine-readable agent self-description, interfaces, skills and security requirements. |
/.well-known/agent-card.json | Permanent well-known URI registration in A2A specification | Predictable location to retrieve an Agent Card when a domain is known. |
| Official MCP Registry | Operational official MCP project | Catalog/API for discovering publicly available MCP servers; supports sub-registry architecture. |
| DNS-AID | Active IETF Internet-Draft | Publish AI-agent discovery information through DNS. |
| ADP | Internet-Draft | Layer DNS-AID, well-known metadata and real-time agent interaction. |
| AINS | Internet-Draft | Resolve logical agent names to rich capability, route and evidence metadata. |
| ARPA Agent Registry Protocol | Active individual Internet-Draft | Agent records, relationships, lifecycle, authority state and evidence references. |
| AREG | Internet-Draft | Vendor-neutral publication, search and resolution of agent definitions. |
| ATEP trust passport | Internet-Draft | Portable execution-history and reputation-style metadata. |
Internet-Draft does not mean Internet Standard. Anyone can submit an Internet-Draft, and drafts can change, expire or never progress. They are useful here because they reveal active engineering directions—not because SXF assumes they will win.
THE BIGGER QUESTION
Who becomes Google for AI agents?
The analogy is useful but incomplete.
Human web search ranks documents for attention. Agent discovery may rank actors that can take actions.
That raises the stakes.
A search engine for agents may influence:
- which agent receives commercial demand;
- which agent is trusted with data;
- which agent can spend money or negotiate;
- which protocol ecosystems become dominant;
- and which reputation systems determine machine-to-machine trust.
There are at least four plausible architectural centers:
Decentralized publication and routing from domains or global agent identifiers.
Structured catalogs that resolve agents and current lifecycle metadata.
Cross-registry indexes that retrieve and rank by capability, evidence, price and policy.
Discovery combined with transaction, reputation and payment.
These layers do not need one owner. The mature web split DNS, hosting, search, identity, advertising and commerce across many systems. The agentic web may do the same.
The crucial future keyword may therefore be bigger than AI agent discovery:
BOTTOM LINE
The next web needs a way for machines to find machines
The human web became usable because a person could type a name, follow a link or search an index and reach a service.
Autonomous agents need an equivalent machine path.
A2A Agent Cards now define a serious self-description primitive. DNS-AID asks whether internet naming can expose agents. ADP and AINS explore discovery layers. ARPA and AREG explore registries. The MCP ecosystem already operates a public registry. New research is treating capability selection as a retrieval-and-ranking problem rather than a giant prompt.
None of this has converged into one universal system yet.
That is exactly why the topic matters now.
Discovery is the layer that turns a closed workflow into an ecosystem.
FAQ
AI agent discovery, Agent Cards, registries, DNS and reputation
What is AI agent discovery?
AI agent discovery is the process by which software finds autonomous agents, retrieves machine-readable descriptions of their capabilities and interfaces, and selects candidates that may be suitable for a task. Discovery is separate from authentication, authorization and trust: finding an agent does not prove that it is safe or permitted to act.
How do AI agents find each other?
Current approaches include direct configuration, well-known URLs such as A2A Agent Cards, registries and catalogs, DNS-based discovery proposals, enterprise directories and semantic search over capability metadata. Different environments may combine several methods.
What is an A2A Agent Card?
An A2A Agent Card is a JSON metadata document describing an agent's identity-facing information, supported interfaces, capabilities, skills and security requirements. The A2A specification registers the well-known path /.well-known/agent-card.json for discovery.
What is the difference between agent discovery and agent authorization?
Discovery answers which agents exist and which may match a task. Authorization answers whether a particular agent is allowed to perform a particular action. A successfully discovered agent is not automatically authorized.
What is an AI agent registry?
An AI agent registry is a service that publishes or indexes machine-readable records about agents so clients can search, resolve or retrieve information such as endpoints, capabilities, versions, operators, lifecycle state or evidence. Registry designs vary widely and are not yet unified under one universal standard.
What is DNS-AID?
DNS-AID is the name used by the DNS for AI Discovery Internet-Draft. It proposes publishing discovery information through DNS so agents can locate organization-specific agents or agents offering capabilities without inventing an entirely separate global naming infrastructure.
What is AINS?
AINS, or AInternet Name Service, is a 2026 Internet-Draft proposing a logical namespace and HTTPS resolution model for autonomous agents. Its records can carry identity references, capabilities, endpoint and route metadata, and references to cryptographic evidence.
What is Agent Discovery Protocol (ADP)?
ADP is a 2026 Internet-Draft that layers AI-agent discovery over DNS-AID, well-known JSON metadata and a real-time interaction layer. It is an experimental proposal and not a finalized Internet standard.
What is the Agent Registry Protocol (ARPA)?
The Agent Registry Protocol is a September 2026 Internet-Draft for publishing and resolving agent records, deployments, relationships, authority state and evidence references. Its own specification explicitly separates discovery and resolution from authorization decisions.
Is MCP Registry the same as an AI agent registry?
No. The official MCP Registry is primarily a catalog and API for discovering Model Context Protocol servers. MCP connects agents or clients to tools and data, while A2A-style discovery addresses peer agents. In practice, future agent systems may search both tool registries and agent registries.
Can an Agent Card prove that an AI agent is trustworthy?
No. An Agent Card can describe capabilities and may be cryptographically signed, which can help verify integrity or publisher identity. But a signed self-description does not prove that the advertised capabilities are accurate, safe or high quality. Trust requires additional evidence, policy and evaluation.
How should AI agents choose between multiple agents with the same capability?
A useful selection pipeline can filter for protocol compatibility and hard constraints, retrieve candidates by capability, then rank them using evidence such as task fit, availability, cost, latency, reputation, assurance, policy compatibility and prior performance. The ranking policy depends on the application.
Why can AI agent discovery become a search problem?
As registries grow, putting every candidate description into an LLM context becomes expensive and less accurate. A 2026 preprint on capability discovery reported substantial degradation in in-context routing at thousands of candidates and evaluated a retrieve-then-rank architecture as a more scalable alternative.
What are the security risks of AI agent discovery?
Risks include fake or spoofed agents, stale records, malicious capability claims, registry poisoning, Sybil identities, endpoint substitution, compromised signing keys, privacy leakage and ranking manipulation. Discovery systems need provenance, freshness, corroboration and local trust policy.
Do AI agents need reputation scores?
Not necessarily a single universal score. Reputation can help selection, but one scalar score can hide task-specific differences and be manipulated. Stronger systems may use evidence-backed, multidimensional signals such as verified execution history, domain-specific performance, recency, dispute rates and attestations.
Will there be a Google for AI agents?
It is an open architectural question rather than a settled outcome. Central registries, federated indexes, DNS-based discovery, protocol-specific catalogs and private enterprise directories are all developing. The eventual ecosystem may resemble the web: decentralized naming plus multiple search, ranking and trust layers.
PRIMARY & RESEARCH SOURCES
Protocols and research used for this guide
SXF distinguishes deployed standards and services from research papers and Internet-Drafts. Drafts are work in progress and are labeled as such.
agent-card.json well-known URI and JWS Agent Card signatures. ↗
A2A · Agentic AI Foundation announcementAugust 2026 description of A2A as an open horizontal layer for agents to discover, delegate and collaborate across frameworks. ↗
DNS for AI Discovery (DNS-AID)Active 2026 Internet-Draft proposing DNS-based publication and discovery of AI agents. ↗
Discovering Agents for Discovery: The Case for DNSJune 2026 study evaluating agent-discovery metadata and DNS feasibility using 119,757 real-world service endpoints. ↗
Agent Discovery Protocol (ADP)June 2026 Internet-Draft combining DNS-AID, well-known metadata, identity and an interaction layer. ↗
AINS: AInternet Name ServiceSeptember 2026 Internet-Draft for agent discovery, identification references, route posture and evidence references. ↗
Agent Registry Protocol (ARPA)Latest September 2026 draft for registration, resolution, relationships, lifecycle, bounded authority and evidence. ↗
Agent Registry (AREG)August 2026 vendor-neutral registry draft for publishing, discovering and resolving agent definitions. ↗
Official MCP RegistryOperational community-driven registry service and API for public MCP servers. ↗
MCP · Introducing the RegistryArchitecture rationale for an official upstream source with public and private sub-registries. ↗
Enrich-Retrieve-RankAugust 2026 capability-discovery research on scaling search across thousands of models, agents, tools and skills. ↗
Multi-Source Corroboration for AI Agent DiscoveryAugust 2026 Internet-Draft addressing conflicting, missing and equivocated agent claims across multiple discovery sources. ↗
ATEP: Agent Trust & Execution PassportSeptember 2026 Internet-Draft exploring portable execution-history and trust metadata for agent-to-agent commerce. ↗
A Scalable Trust Discovery Architecture for the Internet of AgentsSeptember 2026 research prototype for hierarchical registry, resolver and trust-aware discovery architecture. ↗
CONTINUE THE AGENTIC INTERNET