The Emerging Agent Discovery Stack

Imagine a client is asked to interact with the support agent for acme.com.

First, the client needs a low-friction starting point: "where should I go, and which protocol should I speak?" A DNS-first mechanism such as AID can answer that with a compact record at _agent.acme.com, while other proposals use richer DNS namespaces, SVCB records, or protocol-specific labels such as _mcp.acme.com.

Second, the client needs description: what can the agent do, which skills or tools does it expose, what authentication does it require, and how should a client invoke it? That information usually belongs in an agent card, manifest, registry entry, or /.well-known document rather than in DNS.

Third, the client needs trust and authorization. DNS control can help anchor a claim, but it does not by itself prove legal authority, delegated permission, or runtime safety. Endpoint proof, domain validation, OAuth-style delegation, workload identity, enterprise governance, and audit all become separate questions.

Fourth, if the task involves money, the client needs a commerce layer: product or service discovery, user intent, payment authorization, settlement, receipts, dispute evidence, and network risk signals. That is where x402, Stripe/OpenAI's Agentic Commerce Protocol, Google's AP2, Google's UCP, Machine Payments Protocol, ERC-8183, and card-network trust efforts enter the picture. They sit above discovery because they depend on finding and trusting the right parties first.

That staged model is the core of the current landscape. A domain or handle gets the client started; a card, manifest, or registry explains the agent; a trust layer verifies who stands behind it; an authorization layer constrains what it may do; and domain-specific surfaces such as marketplaces or commerce networks add ranking, policy, consent, payment, and transaction guarantees.

If the agentic web becomes more than a product metaphor, agents will need to be named, found, described, and trusted across organizational boundaries. That sounds like one problem, but it is really several. "Finding an agent" can mean resolving a stable identifier, locating an endpoint, retrieving machine-readable metadata, verifying who stands behind that endpoint, and deciding whether the agent is authorized to act in context.

As of April 24, 2026, agent discovery has not settled on one protocol. The more interesting signal is that experimentation is making the requirements clearer. Different approaches overlap, sometimes awkwardly, but the overlap is revealing the stack: bootstrap, description, trust, authorization, registries, overlays, governance, and commerce are separating into different responsibilities.

This piece is published by Agent Community, which maintains AID. AID is listed first where it is directly relevant.

Agent Community is also organizing the community bid for the .agent TLD as a naming layer for the agentic web. That context matters to us, but AID is designed for any domain and the broader stack discussed here applies far beyond .agent.

Why This Is Happening Now

Agent discovery sits between two eras of internet infrastructure.

The first era gave us durable identity and metadata building blocks: SAML metadata, WebFinger, OIDC and OAuth discovery, SCIM, OpenID Federation, ACME, DNSSEC, DANE/TLSA, transparency logs, and workload identity patterns. Identity-literate readers will recognize the inheritance: names, issuers, metadata, keys, policy, provisioning, and trust chains.

The agent wave adds a different pressure. Software actors now need to be discoverable as task-performing endpoints across organizational boundaries. They may expose protocols such as MCP or A2A, carry machine-readable capability descriptions, prove endpoint authenticity, receive delegated authority from a user or organization, appear in registries or marketplaces, and participate in commerce flows.

That is why the field does not look like one clean protocol lineage. It is a newer stack forming on top of an older substrate. Most of the artifacts in this map are not finished standards: many are active individual Internet-Drafts, ecosystem drafts, previews, product surfaces, or discussion threads. That does not make them unimportant. It means the useful question is less "which one won?" and more "which responsibility is each effort trying to own?"

The Stack at a Glance

The cleanest way to read the landscape right now is by responsibility, not by logo or standards body.

The point of this table is not to imply clean boundaries. Many efforts span more than one layer. The value is that the field becomes easier to reason about once routing, description, trust, authorization, overlays, and commerce are no longer forced into the same bucket.

These approaches are not all substitutes. They are often complements: DNS-first bootstrap gets a client started, cards and registries explain what an agent can do, trust layers establish who stands behind the endpoint, and commerce layers add payment and transaction semantics.

DNS as the Broader First Hop

Across multiple public proposals, DNS-first agent bootstrap has become a visible pattern. AID, DNS-AID, and DN-ANR all treat DNS as a primary starting point, even though they make different design choices.

The disagreement is not really "DNS or no DNS." It is how much meaning DNS should carry.

AID takes the minimalist view. A TXT record at _agent.<domain> provides a compact bootstrap: protocol token, endpoint URI, authentication hint, optional metadata, and optional public-key material. The design intentionally keeps large capability descriptions out of DNS. AID is an Agent Community final specification with a related individual Informational Internet-Draft, draft-nemethi-aid-agent-identity-discovery. It should not be described as an IETF standard.

AID's limitation is also its point. It does not try to be a registry, ranking engine, marketplace, delegation framework, or full authorization system. It answers a narrower question: given this domain, where is the agent entry point and which protocol should a client try next?

That said, AID is not purely "discovery only." Its optional PKA mechanism adds endpoint proof. When the pka field is present, the discovered endpoint proves control of a DNS-published Ed25519 key through an RFC 9421 HTTP Message Signatures handshake. That proves control of the key published for that endpoint. It does not by itself prove legal authority, organizational delegation, or business reputation.

DNS-AID is structurally richer. It uses a namespace under _agents.<domain> and leans into SVCB-based service binding, metadata exchange, and capability advertisement. DN-ANR sits closer to DNS-native naming and resolution: it uses SVCB and optional TXT or DNSSEC-backed integrity material, but is better described as resolving selected agent identifiers than as doing semantic discovery or ranking.

That design split matters. A thinner DNS layer is easier to operate and less likely to duplicate constantly changing metadata. A richer DNS layer can reduce fetches and make the first hop more expressive. The field has not settled that tradeoff.

What is striking is that protocol-specific communities keep rediscovering the same pattern. MCP DNS Discovery uses _mcp.<domain> TXT records for MCP server bootstrap and, in its newer drafts, also introduces an organizational identity bootstrap record. Serra's MCP discovery work combines a mcp:// URI, /.well-known/mcp-server, and optional DNS acceleration. ATP uses _atp.<domain> SVCB but is broader than bootstrap alone, covering agent transport, identity, authentication, messaging, and capability exchange. AgentDNS, now expired, is still useful as evidence that DNS-inspired namespace and service-discovery designs were already being explored before the current wave of drafts. Even the older AT Protocol handle system, while not an AI-agent standard, is a useful precedent for DNS-backed name resolution with HTTPS fallback and bidirectional validation.

Not every first-hop proposal is DNS-native. The active agent:// URI scheme draft tries to create a transport-agnostic addressing layer that can resolve toward descriptors and then delegate communication to protocols such as A2A, MCP, or Agent Communication Protocol. That belongs near bootstrap, but it is a different design move: instead of asking "which DNS label should a client query?", it asks whether agents need their own URI shape at all.

In other words, DNS may or may not become the universal agent-discovery layer. But it remains unusually well-positioned as a first-hop substrate because it is already distributed, operator-controlled, globally deployed, and part of the path to almost every HTTPS service.

One easy way to understate DNS is to treat it as merely a pointer to /.well-known documents. It can do that, but that is not the core advantage.

DNS sits below the web application layer. A domain can publish a DNS record even when there is no web server, no application route, and no /.well-known endpoint. That makes DNS a broader first-hop substrate for agents that may live behind HTTP, WebSocket, gRPC, custom transports, registries, message queues, local networks, enterprise systems, or future protocols that are not naturally represented as an HTTPS origin document.

/.well-known remains valuable, but it is narrower. RFC 8615 reserves the /.well-known/ path prefix for origin-wide metadata. In agent discovery, that pattern shows up in places such as A2A's /.well-known/agent-card.json, MCP server-card work, ACP's /.well-known/agent.yml, ANP's /.well-known/agent-descriptions, OAuth Protected Resource Metadata, DID Configuration, and AI Discovery Endpoint. All of those assume there is an origin capable of serving the relevant HTTP resource.

The practical distinction is important. DNS can point to a /.well-known document, but it does not have to. It can point directly to an endpoint, registry, protocol URI, service binding, or key material. It can also tell the client which protocol family to try before the client commits to HTTP at all.

That does not mean DNS should carry every detail. Large capability graphs, frequently changing skill metadata, pricing rules, policy text, and invocation schemas usually belong in cards, manifests, registries, or HTTP documents. The stronger claim is narrower: DNS is technically more general as a first-hop discovery substrate, while /.well-known is a useful HTTP-origin metadata pattern above it.

Trust Is Separating from Routing

Once agents represent organizations, spend money, or trigger actions on behalf of others, "where is the endpoint?" stops being enough. The next questions are sharper: who controls the namespace, who controls the endpoint key, who authorized the agent to act, what scope was delegated, and how can the action be audited later?

Those are related identity questions, but they are not the same question.

The practical consequence is simple: discovery can tell a client where to go, but authorization decides whether this agent may act for this user, against this resource, under these constraints, at this moment. That is why endpoint proof, domain control, delegated authority, runtime attestation, and audit trail keep showing up as adjacent but distinct concerns.

AID PKA belongs at the narrower end of this trust lane: it proves that the discovered endpoint controls a private key corresponding to public material in DNS. ANSv2 is broader and more trust-centered: ACME-based domain validation, server and identity certificates, transparency logging aligned with SCITT concepts, verification tiers, and domain-anchored lifecycle signals. Discovery is present, but identity and lifecycle control are the center of gravity. The GoDaddy ANS Registration Authority matters because it shows a public implementation path for ANS-style registration authority behavior, not because ANSv2 is a completed standard.

ApertoID makes a similar move in a different form. It publishes DNS declarations under _apertoid.<domain> and references a companion request-signing mechanism. It is less about search and more about authorized declarations, policy, delegation, and proof of control. Agent Identity Registry also belongs here, but it should not be reduced to DNS anchoring. Hardware attestation, federated registrars, public lookup, and governance are central; DNS TXT and SRV are bootstrap pieces inside a broader identity registry proposal.

The same design space appears in DID-adjacent work. did:dns uses DNS records as a DID resolution substrate. did:web binds a DID document to an HTTPS origin. did:webvh adds verifiable history to the did:web style of resolution. DID Configuration links DIDs to web domains through a well-known resource and domain-linkage assertions. High-Assurance DIDs with DNS explores DNS-based cross-validation. These are not agent-discovery standards, but identity readers will recognize them as part of the same domain-control and key-binding conversation.

Adjacent identity work is also relevant even when it is not agent-specific. OAuth Token Exchange gives a vocabulary for delegation and impersonation, while OAuth Identity and Authorization Chaining is closer to the cross-domain chain-of-calls problem that appears when one agent invokes another service on a user's behalf. OAuth Protected Resource Metadata is especially important because it lets a protected API publish how it is protected and where authorization metadata lives; for agent clients, that becomes part of discovering not just "where is the tool?" but "how do I get a usable token for it?" OAuth Dynamic Client Registration and the active OAuth Client ID Metadata Document matter for the same reason: open agent ecosystems cannot assume every client was manually pre-registered.

DPoP, OAuth mTLS, OAuth Resource Indicators, and OAuth Rich Authorization Requests are not agent-discovery protocols, but they provide vocabulary for proof of possession, target-resource binding, and structured authorization details. SPIFFE and the IETF WIMSE working group are part of the workload-identity lineage, with concrete work on workload identifiers and workload credentials. RATS and Entity Attestation Tokens sit nearby when the question becomes "what runtime, device, or software environment is this agent actually running in?"

Web Bot Auth is adjacent because it addresses authenticated automated clients on the web. OpenID Shared Signals is adjacent because agent trust will likely need continuous signals for suspension, compromise, revocation, and remediation rather than one-time authentication. The W3C Verifiable Credentials Data Model 2.0 and related Data Integrity work are also relevant because organization-issued agent credentials, delegation attestations, and capability claims need portable formats if they are to move across registries.

Nearby agent-specific frameworks such as AIP, SAIP, VAIP, and AI-Agent Auth push further into delegation, audit, permission scope, workload identity, and trust scoring. NIST's AI Agent Standards Initiative and NCCoE Software and AI Agent Identity and Authorization project are not protocols, but they are strong evidence that identity, authorization, and interoperability are becoming standards-track concerns. They reinforce the broader point: routing and attestation are being designed together without being the same layer.

Rich Discovery Is Moving Toward Registries and Manifests

If DNS is strongest as a low-friction first hop, the mirror image is also becoming clear: rich discovery keeps moving toward registries, manifests, cards, and HTTP metadata documents.

That shift is visible in AINS, AIDIP, ARDP, AI Discovery Endpoint, and AGTP discovery. The common intuition is that capability detail, richer policy, search, ranking, and invocation metadata belong in JSON documents or registries, not in compact DNS records.

A2A is the clearest released, vendor-backed specification example of that logic. The /.well-known/agent-card.json document acts as a durable description surface for an A2A agent's capabilities, endpoints, authentication requirements, and skills. Broader discovery can happen through direct configuration, curated registries, marketplaces, or catalogs.

MCP now has its own registry and card story as well. The MCP Registry is currently in preview and provides an official centralized metadata repository for publicly accessible MCP servers, with server.json metadata, namespace authentication, and a REST API for aggregators. The MCP Server Card Working Group is working on a standardized MCP Server Card and discovery mechanism, and the MCP roadmap explicitly lists server cards as a standard for exposing structured server metadata through a .well-known URL.

AINS is worth reading as more than just registry discovery. It combines HTTPS resolution, rich metadata, trust evidence, and signed append-only federation logs. AIDIP emphasizes RESTful discovery and invocation with capability-oriented metadata. ARDP defines a registration and resolution control plane with identifiers, capabilities, presence, and federation. AI Discovery Endpoint proposes a /.well-known/ai document for machine-readable service description. AGTP discovery uses an agent name service and ranked Agent Manifest Documents.

One registry-layer effort worth calling out separately is AGNTCY Agent Directory Service. ADS is a distributed directory proposal for agent records, content addressing, DHT-style lookup, provenance, and capability-based search. It is tightly connected to the Open Agentic Schema Framework, which defines structured records for agent capabilities, interactions, metadata, skills, domains, and modules. That is a different emphasis from AID or DNS-AID: not "how do I get from a domain to a starting endpoint?", but "how do I search and validate a population of agent records?"

There is also an important acronym trap. In commerce, ACP usually means Stripe/OpenAI's Agentic Commerce Protocol. In interoperability discussions, ACP often means the Linux Foundation/BeeAI Agent Communication Protocol. The latter defines an Agent Manifest with identity, capabilities, metadata, runtime status, supported content types, and cataloging fields. Its discovery docs describe direct server queries, public /.well-known/agent.yml manifests, registries, and embedded discovery, while noting that open discovery is not yet part of the official ACP core spec.

ANP approaches the same terrain from a linked-data direction. Its discovery draft uses JSON-LD and /.well-known/agent-descriptions to publish collections of agent description documents, while the broader Agent Network Protocol work leans on DIDs and schema.org-style metadata. NLWeb is not a general agent registry, but it is relevant because it turns websites into structured natural-language endpoints with HTTP, MCP, and A2A-style action bindings. ECMA NLIP is also not discovery-first, but it is a real standards-body protocol for natural-language interaction between AI agents or between humans and agents.

Finally, W3C and Eclipse work are useful precedents for description rather than direct competitors. W3C WoT Discovery already standardizes ways to obtain machine-readable Thing Descriptions through well-known URIs, directories, DNS-SD, DID documents, and local or global discovery flows. WoT Thing Description 2.0 is active draft work on describing affordances, forms, protocols, data schemas, and security metadata. Eclipse LMOS adapts similar ideas to agents and tools, including agent descriptions, local/global discovery, registries, DIDs, and metadata propagation.

The contrast with DNS is the useful part. A card or registry can say: this agent handles refunds, exposes these skills, requires these scopes, accepts these content types, prefers this invocation protocol, and publishes this policy metadata. That is exactly the kind of information that should not be squeezed into a compact first-hop record.

The likely lesson is not DNS versus registries. It is staged discovery. DNS answers "where do I start?" A card or manifest answers "what can this agent do?" A trust layer answers "who stands behind this endpoint?" Authorization answers "what may it do in this context?"

On-Chain and ENS as Compositional Overlays

Crypto and on-chain work should be visible in this conversation, but it should not dominate the core architecture. Most of the strongest public efforts in that lane are better understood as overlays, bridges, or portable identifier systems.

ENSIP-25 is a useful example. It connects ENS names to agent registries through ENS text records. That matters if public agents need portable naming and discoverable registry references, but it is not the same as open-web DNS bootstrap. ENSIP-26-style metadata discussions are worth watching too, though they remain fluid enough to describe cautiously.

ERC-8004 is another important case. It is best framed as draft on-chain identity, reputation, and validation registry work, not a DNS-native discovery protocol. Its relevance comes from composability: an on-chain agent record can point to DNS, ENS, DID, A2A, MCP, or other surfaces without replacing them.

HCS-14 is especially interesting because it behaves like a meta-identifier framework. Its profile registry includes AID DNS/Web and _uaid DNS TXT resolution profiles. In that sense, it looks less like a direct competitor to every naming proposal and more like an attempt to coordinate across them. By contrast, HCS-18 and HCS-21 are better treated, at least for now, as draft ecosystem infrastructure rather than mature open discovery standards.

The broader point is simple: on-chain and ENS systems matter most when they compose with the web stack, not when they are assumed to replace it. They can help with portability, registry linkage, and reputation continuity, but they are not the natural low-latency first hop for a client starting from a bare web domain.

Commerce Is Becoming the Layer Above Discovery

Commerce is not agent discovery, but it is one of the clearest reasons discovery has to become more precise. Once an agent can find a merchant, paid API, service provider, or other agent, the next questions become transactional: what is being bought, who authorized it, how is payment requested, what evidence travels with the transaction, and who is accountable if something goes wrong?

That is why commerce protocols sit above the discovery and identity stack rather than replacing it. x402 revives HTTP 402-style payment challenges for machine payments. Stripe/OpenAI's Agentic Commerce Protocol focuses on checkout and order handoff. Google's Agent Payments Protocol frames payments around verifiable digital credentials and payment mandates, extending A2A and MCP-oriented flows. Google's Universal Commerce Protocol is broader: it tries to create a common commerce language for agents, apps, businesses, and payment providers. MPP aims at per-request machine-to-machine payments for APIs, tool calls, and content. ERC-8183 adds an on-chain job, escrow, provider, and evaluator model for agentic commerce.

These systems do not answer "how do I discover the official support agent for acme.com?" by themselves. They assume that some discovery, identity, authorization, and trust context already exists, then add payment, mandate, settlement, dispute, and risk semantics on top. That is why commerce belongs on the map, but as an upper layer.

Vendor Moves Show Demand, Not Consensus

One reason this category now matters is that large vendors are moving into adjacent parts of it at the same time. But they are not all entering through the same door.

This table should be read as product and market evidence, not as proof that one open discovery architecture has won. Google and A2A strengthen the manifest and marketplace lane. Microsoft and Okta strengthen enterprise identity and governance. WorkOS strengthens MCP-oriented OAuth and authorization plumbing. OpenAI, Stripe, Google commerce work, Tempo/Stripe MPP, and Visa strengthen platform and payment-trust surfaces.

The vendor lane also needs maturity nuance. Microsoft Agent 365 is framed as a control plane with early-access paths. Okta's AI agent management material is enterprise-scoped and, in the cited docs, focused on human-to-agent connections rather than open agent-to-agent discovery. OpenAI AgentKit exists, but Agent Builder and Connector Registry have beta availability notes. Stripe/OpenAI's Agentic Commerce Protocol is primarily about transaction and checkout integration, while its discovery mechanisms are still forming. Visa's Trusted Agent Protocol is available through Visa developer channels, but Visa also describes it as being in development and deployment.

That nuance is the point. Enterprise inventory is not the same thing as public-agent routing. Marketplace listing is not the same thing as cross-protocol naming. Commerce authorization is not the same thing as open discovery, even if the layers will eventually need to interoperate.

What Convergence Probably Looks Like

The cleanest interpretation of the current landscape is not winner-take-all. It is composition.

A plausible near-term stack looks something like this: a stable name or handle resolves through DNS, a URI scheme, or another low-friction resolver; a manifest, card, or registry supplies richer metadata; semantic description layers explain capabilities and affordances; a trust layer proves endpoint or domain control; delegation frameworks carry scoped authority; governance systems handle ownership, lifecycle, and audit; optional overlays such as ENS or on-chain registries bridge across ecosystems; and domain-specific layers such as marketplaces, commerce protocols, or payment networks add ranking, policy, consent, settlement, and transaction guarantees.

That does not mean the architecture is settled. Many of the efforts in this map are still Internet-Drafts, ecosystem drafts, previews, or product surfaces. Some will merge. Some will expire. Some will remain protocol-specific. Some overlap because their authors are still discovering the same requirements from different starting points.

That overlap is the signal. Agent discovery is not yet one protocol. It is an active set of experiments around a clearer set of needs: naming, bootstrap, rich metadata, semantic description, trust, delegated authority, governance, and market context. The agentic web is beginning to develop a real discovery and identity stack, but the boundaries are still being negotiated.

For interpretation, the evidence supports a directional claim: distributed naming infrastructure, especially DNS, is unusually well-positioned as the first-hop layer, while richer discovery, trust, authorization, governance, and commerce specialize above it.

This is a living map. If you see missing efforts, outdated classifications, or newer public artifacts we should fold in, send them to hello@agentcommunity.org.

Source Appendix

The table below is a compact glossary of the main artifacts referenced in this piece. It is meant to make the research surface legible at a glance, not to replace the narrative above.