| Internet-Draft | AI Agent Discovery | July 2026 |
| Jimenez, et al. | Expires 4 January 2027 | [Page] |
This document surveys mechanisms for AI agent discovery being developed at the IETF, at AAIF, at 3GPP, and in open-source projects. It compares them by discovery model, scope, dynamism, cross-domain reach, and semantic capability. It identifies gaps, overlaps, and conflicts between the approaches to inform future standardization work.¶
This note is to be removed before publishing as an RFC.¶
Status information for this document may be found at https://datatracker.ietf.org/doc/draft-jimenez-dawn-discovery-landscape/.¶
Discussion of this document takes place on the Discovery of Agents, Workloads, and Named entities Working Group mailing list (mailto:dawn@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dawn/. Subscribe at https://www.ietf.org/mailman/listinfo/dawn/.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 4 January 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
An AI agent is an LLM-driven system that operates as a loop (see Figure 1): it consults a Large Language Model to plan, acts on external tools and services, observes the results, and repeats. Discovery is one of the action types available within this loop. When the agent determines that its current tool set is insufficient for the task, it queries a discovery source and adds the returned references to its working set for subsequent iterations.¶
An agent's ability to find the right tool or another agent, and to learn enough about it to interact, is what this document calls agent discovery. The term covers finding entities (agents, tools, services) and discovering their capabilities. Discovery can occur before a task begins, through static configuration such as reading a local file, resolving a fixed DNS name, or fetching a well-known URI at startup. It can also occur dynamically during a task, when the agent queries a discovery source in response to a need identified at runtime. The same discovery sources can serve both paths; what differs is when and why they are consulted. This document surveys what those discovery sources are, how they compare, and where gaps remain. It does not prescribe which mechanism an agent should select for a given task.¶
Agent discovery mechanisms are already being built. Protocols, well-known URIs, directory services, and DNS extensions have emerged in parallel from different organizations, often addressing overlapping problems with incompatible approaches. No single IETF document yet inventories this work. A Discovery of Agents, Workloads, and Named entities (DAWN) working group is proposed in the IETF to address this space. DAWN's proposed charter targets interoperable discovery across organizational boundaries, with planned deliverables including terminology [I-D.farrel-dawn-terminology], a problem statement [I-D.akhavain-moussa-dawn-problem-statement], requirements [I-D.king-dawn-requirements], and a gap analysis. This document contributes to that gap analysis by surveying the existing mechanisms, comparing them, and identifying gaps. It does not propose a new discovery mechanism.¶
This document is organized as follows. Section 2 defines five use cases that motivate the survey. Section 3 establishes the analytical framework: five functional components that any discovery system must address, and how they compose. Section 4 surveys existing mechanisms grouped by approach. Section 5 compares them across multiple dimensions. Section 6 identifies where standardization gaps remain.¶
The surveyed discovery mechanisms address different scenarios that differ mainly in the assumed trust based on who controls the set of discoverable agents.¶
A general-purpose AI agent application ships with a bundled set of subagents and tools. The provider selects the initial set. The implementations, or references to them, are part of the application.¶
Agents and tools are deployed in a single administrative context such as a corporate network. A local administrator controls the set. Applications receive static configuration or discover through local mechanisms, for example multicast within a subnet or resolution within a configured domain such as agents.example.com.¶
An agent contacts a specific collaboration partner whose capabilities and addresses it does not yet know. Discovery targets that partner, typically starting from their domain name. For instance, a travel service agent discovers a hotel chain's booking agent.¶
Multiple organizations establish mutual trust agreements and share agent registrations across their domains. Discovery spans the consortium but not the open Internet. Each organization publishes its own agents; federated peers propagate or proxy discovery queries across domain boundaries. For instance, a supply-chain consortium lets each member's logistics agents discover partner agents in peer domains without exposing them to the public.¶
An agent searches across the Internet for agents or tools suitable for a task, without restricting who can provide them. Search engines or curated directories of agent services support this mode. Discovery can also proceed transitively: an agent or tool reached through an initial search may itself reference further agents or tools, and the agent follows those references as it explores. This hypermedia-driven pattern lets the discoverable surface grow during a task rather than being fixed up front.¶
These scenarios differ along three axes: the trust assumptions between parties, whether a prior contract exists, and the discovery techniques available. Local-network discovery applies in the first two cases; discovery anchored in a partner's domain name applies in the third; federated registries with pre-negotiated trust apply in the fourth; Internet-wide search through a third-party directory, followed by hypermedia-driven traversal, applies in the fifth.¶
This section defines the functional components that discovery systems address. The components serve as the analytical framework for the mechanism survey and comparison that follow.¶
Agent systems address five functional components: lookup, name, description, trust, and interaction. Lookup is the act of finding candidates; the other components handle what happens once candidates are known. The mechanisms surveyed later combine these components in different ways, and the combinations determine which mechanisms can be compared to which.¶
The act of finding a candidate agent or tool. It produces a pointer, typically a name, that the rest of the stack can resolve. A DHT query returning a CID and a DNS-SD browse returning an FQDN are both instances of lookup.¶
The stable name or address under which an agent is referenced. FQDNs, DIDs, and content identifiers are all naming schemes. A name anchors trust: a lookup produces one, and a trust mechanism validates it.¶
The metadata that tells a caller what an agent is and how to use it. Capabilities, supported protocols, authentication schemes, and endpoints live here. A2A Agent Cards and MCP Server Cards are description formats; JSON-LD agent descriptions and OASF records are richer alternatives.¶
The mechanisms that establish whether a discovered name and description can be relied on. DNSSEC and DANE anchor trust in the DNS hierarchy; DID documents anchor trust in public keys; OAuth, SPIFFE, and mTLS authenticate the session once interaction begins.¶
The protocols used once trust is established: JSON-RPC, HTTPS, gRPC, SSE. Discovery is only useful if the caller can then talk to the agent, so description formats must declare which interaction protocols are on offer.¶
Mechanisms differ in how many of these components they bundle. DNS-AID bundles lookup and name. A2A's /.well-known fetch bundles lookup and description. ANP spans all five. These differences explain why the mechanisms surveyed later are not drop-in replacements for each other. Note also that a target resource may itself serve as a discovery source - for example, when an agent fetches another agent's capability description via a well-known URI. The "act" and "discover" roles shown in Figure 1 are conceptually distinct but not necessarily distinct endpoints.¶
To illustrate how the components compose in practice, consider the Known Partner use case. An agent that knows a partner's domain name but nothing else might proceed as follows: resolve the domain (Name), fetch a well-known URI to retrieve an Agent Card or description (Lookup + Description), discover authentication requirements from the card (Trust), and then connect using the declared protocol (Interaction). This sequence is not normative; mechanisms differ in which steps they require, which they skip, and which they collapse. MCP, for instance, goes directly from local configuration to interaction with no resolution or trust step. ANP may perform all five components in a single protocol exchange.¶
This section surveys mechanisms drawn from IETF (httpapi drafts, CATALIST contributions, DNS-based proposals), AAIF (A2A Agent Cards, MCP Server Cards), 3GPP (6G architecture studies on agent discovery), and open-source projects (ANP Agent Discovery Service Protocol, AGNTCY Agent Directory Service, the IoA framework, and related efforts). They are grouped by approach: DNS-based resolution, host-level self-description, and registries and directories.¶
Maps agent identifiers to network locations. Answers "where does this agent live" using DNS primitives (A/AAAA, SVCB, DNS-SD), with optional agent-specific record types.¶
[I-D.mozleywilliams-dnsop-dnsaid] uses a structured namespace under _agents subdomains (e.g., _chat._agents.example.com) with SVCB records to publish agent metadata. It requires no new DNS protocol elements and integrates with DNSSEC and DANE for trust. An accompanying problem statement [I-D.mozley-aidiscovery] argues that decentralized publication through known entry points is preferable to centralized registries.¶
[I-D.cui-dns-native-agent-naming-resolution] proposes a 3-layer model (discovery, resolution, connection) using FQDNs as stable identifiers and SVCB/HTTPS records [RFC9460] for endpoint resolution. Its scope is deliberately limited to the resolution layer; discovery and connection are delegated to other mechanisms.¶
[I-D.nemethi-aid-agent-identity-discovery] takes a minimal approach: a DNS TXT record at _agent.<domain> with semicolon-delimited key-value pairs (version, URI, protocol token, authentication hint, optional Ed25519 public key). It is protocol-agnostic, delegating interaction to A2A, MCP, or other protocols. AID requests IANA registration of the _agent DNS node name.¶
[I-D.liang-agentdns] proposes a root domain naming system for LLM agents with unified namespace, semantic service discovery, protocol-aware interoperability, and unified authentication. This draft has expired.¶
All four proposals agree that DNS handles naming and location; they differ on record type (SVCB vs. TXT), namespace convention (_agents vs. _agent), and how much metadata belongs in DNS versus a fetched document.¶
These approaches are based on self-publication at a known location. A host serves its own machine-readable description at a well-known URI; the client dereferences the URL rather than querying a registry.¶
[RFC9727] defines /.well-known/api-catalog as a well-known URI for advertising available APIs on a given host. It was not designed with agents in mind, but the pattern serves the same function as A2A Agent Cards and MCP Server Cards: "here is what this host offers, in machine-readable form." Companion drafts cover link hints [I-D.ietf-httpapi-link-hint] and authentication links [I-D.ietf-httpapi-authentication-link].¶
The A2A community has adopted this pattern for multi-agent hosts. A2A now allows an api-catalog [RFC9727] at /.well-known/api-catalog to advertise several agents under a single origin, each entry linking to that agent's card. This addresses the one-agent-per-host assumption of the base Agent Card discovery model.¶
The Agent-to-Agent protocol [A2A-spec] uses Agent Cards as the primary discovery artifact: a JSON document served at /.well-known/agent-card.json describing identity, capabilities, skills, and authentication requirements. Discovery is pull-based and static; you need to know the agent's host to fetch its card.¶
The Model Context Protocol [MCP-spec] focuses on agent-to-tool communication via JSON-RPC 2.0 over Streamable HTTP or stdio. Discovery is local configuration: clients are pre-configured with server URLs or launch commands. Once connected, capability negotiation occurs via a JSON-RPC initialize exchange where client and server declare supported features (tools, resources, prompts). MCP defines OAuth discovery endpoints (/.well-known/oauth-protected-resource and /.well-known/oauth-authorization-server) for authentication. The base protocol has no mechanism for discovering available servers; clients learn about servers out of band. A separate MCP Registry [MCP-registry] addresses this: it is a centralized catalog of publicly available MCP servers, with namespace ownership validated at publication through GitHub, DNS, or HTTP verification. The registry is a hosted service rather than a peer-to-peer or federated protocol, and it indexes only MCP servers.¶
The Agent Network Protocol [ANP-spec] defines a /.well-known/agent-descriptions endpoint for JSON-LD metadata documents, with agent identity anchored in Decentralized Identifiers (DIDs). ANP also specifies an Agent Discovery Service Protocol (ADSP) for cross-domain indexing; ADSP is covered under Registries and Directories below.¶
[I-D.cui-ai-agent-discovery-invocation] (referred to as AIDIP in the comparison tables below) proposes patterns for agent discovery and invocation with an optional Agent Semantic Resolution (ASR) layer, contributing to the CATALIST discussion space [I-D.yao-catalist-problem-space-analysis].¶
The .well-known pattern is being independently reinvented outside standards bodies. For example, the Agent Discovery Protocol (ADP) publishes a /.well-known/agent-discovery.json document that bundles service endpoints for identity, memory, governance, reputation, and other agent services into a single JSON file served identically across all subdomains of an operator. ADP is a single-author effort (Walko Systems, April 2025) with one implementation. It illustrates the pull toward self-describing discovery documents but lacks IANA registration, formal specification, or multi-implementer review.¶
A discovery and registration layer provides aggregation across hosts. A registry accepts agent metadata and answers capability-centric queries, trading per-host autonomy for cross-domain search.¶
3GPP is studying agent registration and discovery as part of the 6G system architecture across multiple working groups. [TR22.870] defines service requirements for AI agent communication in 6G, establishing that 6G systems shall support mechanisms for AI agents (on-device, 3rd-party, and network-internal) to register their attributes and enable discovery. A companion IETF draft [I-D.yu-dmsc-ai-agent-use-cases-in-6g] reframes these requirements for protocol design and notes that existing 3GPP discovery mechanisms (e.g., NRF) may not be sufficient for cross-platform and cross-domain agent discovery.¶
Two parallel paths are emerging within 3GPP:¶
The SA6 application enablement study [TR23.801-02] examines how to extend the exposure framework, including the Common API Framework (CAPIF) [TS23.222], so that 3rd-party AI agents can act as API Invokers. Key Issue 1.3 ("Enabling Exposure to 3rd Party AI Agents") identifies that current CAPIF has no semantic API discovery mechanism aligned to AI agent interaction patterns, and that CAPIF's existing structured API descriptions are not suitable for AI agents that interact through intent-based or less structured requests. The study considers enabling AI agents to discover and consume CAPIF-published services, as well as supporting the publication and discovery of services provided by service producers' AI agents. Because CAPIF operates at the application layer, this path is potentially applicable to any 3rd-party AI agent regardless of where it resides.¶
The SA2 6G system architecture study [TR23.801] addresses agent discovery in Key Issue #19 ("6G Network for AI"). It studies whether and how the 6G core network can support an AI agent on a UE discovering another AI agent on a different UE, enable inter-agent communication including identification and authorization, and enhance network capability exposure to AI agents on Application Functions (AFs). The study proposes new 3GPP-specific network functionalities - an AI agent Management Functionality (registration, authentication, authorization) and an AI agent Discovery Functionality. Discovery options under study include signalling via NAS (control plane), via user plane, or via AF-triggered queries, with support for both identity-based lookup and skill-based discovery. The study also considers exposing network capabilities as tools to external AI agents using agentic protocols such as MCP. This path is more UE-agent oriented, with the operator-managed network acting as an active mediator of agent identity, authorization, and discovery.¶
Both paths are in study phase (Rel-20, target completion 2027) and have not yet produced normative specifications.¶
The Internet of Agents framework [IoA] coordinates heterogeneous AI agents using structured protocols. Its discovery mechanism is semantic: agents register capability metadata and others find them via semantic queries rather than URL-based lookups. IoA is an academic framework (OpenBMB), open source.¶
ANP's ADSP [ANP-spec] is the aggregation layer above the per-host /.well-known/agent-descriptions endpoint described in Section 4. It operates in two modes. In active discovery, an indexing service queries domains' well-known endpoints to retrieve paginated collections of agent descriptions in JSON-LD format. In passive discovery, agents submit their description URLs to an indexing service, analogous to submitting a sitemap to a search engine. Agent identity in ADSP is anchored in did:wba identifiers resolved via HTTPS-hosted DID documents. ADSP does not define soft-state lifetimes or federation between indexers; each indexer maintains its own crawl scope.¶
The Agent Directory Service [I-D.mp-agntcy-ads] is a distributed directory that stores and discovers AI agent metadata using a federated network of interconnected servers. ADS combines three building blocks: a libp2p Kad-DHT for content routing and server discovery, the Open Agentic Schema Framework (OASF) [OASF] for capability-based matching, and OCI Distribution-compliant storage (ORAS/zot) for record retrieval.¶
OASF is a schema system for describing agent capabilities and metadata, created by Cisco/Outshift. It defines a record format whose key fields include skills drawn from a hierarchical taxonomy (15 top-level categories such as NLP, computer vision, security, agent orchestration, and advanced reasoning, with 100+ specific skills underneath), domain classifications, locators (endpoint URLs), author information, and extensible modules for additional metadata. Skills and domains are the routable attributes: when an OASF record is published into ADS, its skill annotations are extracted and announced into the DHT so that capability-based queries can locate relevant servers.¶
Discovery is two-phase: a client queries the DHT with skill taxonomy terms, receiving both matching record identifiers (CIDs) and the addresses of servers hosting them, then fetches the full OASF records from the relevant server's OCI-compliant store. ADS also includes a runtime discovery component that automatically detects labeled containers and pods in Docker and Kubernetes environments.¶
The specification is published as an Internet-Draft. A reference implementation in Go with gRPC/protobuf interfaces is open source, and a production instance is operated by Cisco/Outshift. ADS is the most complete federated directory implementation surveyed: it addresses cross-domain search (via DHT-routed skill queries), federation (via Kad-DHT), and structured capability matching (via OASF taxonomy). Its main limitations are that OASF is not yet adopted by other discovery systems (A2A, MCP, and ANP each define their own metadata formats), and ADS does not natively index A2A Agent Cards or MCP Server Cards.¶
[I-D.pioli-agent-discovery] specifies a lightweight federated protocol for registering and discovering agents. Agents obtain stable identifiers in the form agent:<local-id>@<authority>, register with endpoints, capabilities, and time-to-live values, and are discovered via direct AID resolution or capability-based queries. Registration requires cryptographic proof-of-control via JWS signatures (ES256 mandatory). ARDP supports cross-domain federation through explicit trust relationships. Its scope is deliberately narrow: it excludes interaction protocols, identity governance, and runtime authorization.¶
[I-D.jimenez-agent-directory] defines the Agent Directory (AD), an HTTP/JSON service that adapts the CoRE Resource Directory [RFC9176] from constrained IoT devices to software agents. Agents register their identity, capabilities, and reachable endpoints via POST to /ad/r; clients discover them via GET to /ad/l with filters on agent name, capability name, capability type, protocol, and tags. Registrations are soft state with configurable lifetimes, following the same lifecycle model as [RFC9176].¶
The AD is discoverable at /.well-known/ad, which returns the paths to the registration and lookup interfaces. On local networks, DNS-SD with service name _ad._tcp provides zero-configuration discovery. The lookup interface supports two views: agent view (default) groups results by agent with capability summaries; capability view returns individual capabilities across all matching agents with the owning agent's base URI and protocols inlined.¶
Capability types defined by the AD are tool, skill, resource, and prompt. Registrations carry optional identity and identity_type fields that point to external identity metadata (Agent Identity Profiles, OpenID Connect, WIMSE, or DID documents), letting clients verify agents beyond trusting the directory. The AD requires TLS and mandates OAuth 2.0 bearer tokens or mTLS for registration; errors use RFC 9457 Problem Details.¶
Federation across multiple AD instances is acknowledged but not specified in the initial version. The soft-state model bounds staleness: federated entries carry the original lifetime and expire without explicit deletion if synchronization lapses.¶
A public prototype is deployed at ad.jaime.win (Cloudflare Worker, MIT license).¶
The A2A Registry (a2aregistry.org) is a curated web directory of A2A-compatible agents. Entries are persistent and include periodic health checks to verify agent availability. The registry is human-browsable but provides no programmatic query API; discovery requires manual search through the web interface. It is A2A-only and does not index agents using other protocols.¶
This section compares the surveyed mechanisms along three dimensions: discovery model and scope (Table 1), coverage of the five components defined in Section 3.1 (Table 2), and applicability to the use cases defined in Section 2 (Table 3). It concludes with a summary of the key structural differences that cut across all three tables.¶
Table 1 characterizes each mechanism by its architectural model, the scope of agents it can reach, whether it supports dynamic updates, cross-domain queries, and semantic (capability-based) lookup.¶
| Approach | Model | Scope | Dynamic | Cross-domain | Semantic |
|---|---|---|---|---|---|
| api-catalog | Pull | Per-host | No | No | No |
| A2A Agent Cards | Pull | Per-agent | No | Yes (known host) | No |
| MCP | Config | Per-tool | No | No | No |
| ANP ADSP | Hybrid | Internet | Yes | Yes | Partial |
| AGNTCY ADS | DHT | Cross-domain | Yes | Yes (DHT) | Yes (OASF) |
| 3GPP 6G | Registry | Network | Yes | Operator | Partial |
| IoA | Registry | Cross-agent | Yes | Yes | Yes |
| ARDP | Registry | Federated | Yes (TTL) | Yes (federation) | No |
| Directory (AD) | Registry | Cross-domain | Yes (TTL) | Yes (federation) | No |
| A2A Registry | Curated | A2A agents | Health check | No | No |
| DNS-AID | DNS | Per-domain | DNS TTL | Per-domain | No |
| DN-ANR | DNS | Per-domain | DNS TTL | Per-domain | No |
| AID | DNS | Per-domain | DNS TTL | Per-domain | No |
| AgentDNS | DNS | Cross-domain | Unknown | Yes | Yes |
| AIDIP | Hybrid | Cross-domain | Unknown | Unknown | Yes (ASR) |
Key observations from Table 1:¶
Pull-based self-description (api-catalog, A2A, MCP) is the most widely deployed pattern but offers neither cross-domain reach nor dynamic updates.¶
DNS-based approaches are decentralized but limited to per-domain scope with no semantic capability.¶
Registry and directory approaches (3GPP 6G, ADS, AD, ARDP) achieve cross-domain reach and dynamic updates but require centralization or federation.¶
Semantic lookup - finding an agent by what it can do - remains rare, with partial support only in ADS (OASF taxonomy), IoA, 3GPP 6G (skill-based discovery), AgentDNS, and AIDIP.¶
Table 2 maps each mechanism to the five discovery components. A cell indicates what the mechanism provides for that component; a dash indicates the component is out of scope or delegated elsewhere.¶
| Approach | Lookup | Name | Description | Trust | Interaction |
|---|---|---|---|---|---|
| api-catalog | Well-known URI | - | API list | TLS | - |
| A2A Agent Cards | Well-known URI | - | Agent Card | Per-card auth | - |
| MCP | Local config | - | JSON-RPC caps | - | JSON-RPC |
| ANP ADSP | Crawl/index | DID | JSON-LD | DID | HTTP |
| AGNTCY ADS | DHT query | CID | OASF record | - | - |
| 3GPP 6G | Registry query | Operator | Capabilities | Operator PKI | Per-API |
| IoA | Registry query | Platform | Capabilities | - | Structured |
| ARDP | Query | agent: URI | Capabilities | JWS proof | - |
| Directory (AD) | Registry query | Scoped | Cap. views | TLS + ident. | - |
| A2A Registry | Web browse | URL | Card link | - | - |
| DNS-AID | DNS query | FQDN | - | DNSSEC/DANE | - |
| DN-ANR | DNS query | FQDN | - | DNSSEC | - |
| AID | DNS TXT query | FQDN | - | Ed25519 (opt) | - |
| AgentDNS | DNS query | Domain | Semantic | - | - |
| AIDIP | Semantic query | - | Capabilities | - | Invocation |
Table 3 maps mechanisms to the five use cases. "Yes" means the mechanism is designed for that scenario; "Partial" means it can be applied but with limitations; a dash means it does not address the scenario.¶
| Approach | Curated set | Local context | Known partner | Federated consortium | Free-form search |
|---|---|---|---|---|---|
| api-catalog | Yes | Yes | Yes | Partial | Partial |
| A2A Agent Cards | - | - | Yes | - | - |
| MCP | Yes | Partial | - | - | - |
| ANP ADSP | - | - | Yes | Partial (DID) | Yes |
| AGNTCY ADS | - | - | - | Yes (DHT) | Yes |
| 3GPP 6G | - | Yes | - | Partial (operator) | - |
| IoA | - | - | - | - | Yes |
| ARDP | - | Partial | Yes | Yes | - |
| Directory (AD) | Yes | Yes | Yes | Partial | Partial |
| A2A Registry | - | - | - | - | Partial (human) |
| DNS-AID | - | Yes | Yes | - | - |
| DN-ANR | - | Yes | Yes | - | - |
| AID | - | Yes | Yes | - | - |
| AgentDNS | - | - | - | - | Partial |
| AIDIP | - | - | Partial | - | Yes (ASR) |
No single mechanism spans all five use cases; a complete system requires composing mechanisms from different approaches. Section 6 expands on the gaps visible from this mapping.¶
This section identifies gaps that emerge from the comparison in Section 5. Each gap represents a problem that no surveyed mechanism fully solves.¶
Most mechanisms require prior knowledge of an agent's URL or host (see the Semantic column in Table 1). No standardized way exists to discover agents by capability alone. The Free-form search use case depends on this capability, yet existing solutions (ADS via OASF taxonomy, ANP ADSP via crawling, IoA via semantic queries) are each single-implementer with incompatible metadata formats. No IETF standard addresses capability-based agent search.¶
The Federated consortium use case has emerging support from ARDP (explicit trust relationships), ADS (DHT peering), and AD (acknowledged but unspecified), as shown in the Cross-domain column of Table 1 and the Federated consortium column of Table 3. Each uses a different trust model, propagation mechanism, and identity scheme. No interoperable standard lets federated directories from different implementations exchange agent registrations.¶
3GPP is studying two approaches to agent discovery: extending the application-layer exposure framework (CAPIF) for AI agent interactions, and defining new 3GPP-specific network functionalities for UE agent discovery. Neither path has yet defined how agents discovered through these mechanisms relate to agents discoverable via application-layer protocols such as A2A or MCP. No bridging mechanism exists between network-registered agents and A2A Agent Cards or MCP tool schemas. The Local context use case within operator networks may require both network-assisted and application-layer discovery to interoperate.¶
Each approach defines its own metadata format: A2A Agent Cards, MCP tool schemas, ANP agent descriptions (JSON-LD), OASF records, 3GPP capability metadata, DNS-AID agent indexes (see the Description column in Table 2). No common schema or mapping exists between them. An agent discovered via one mechanism cannot be described to a client expecting another format without bespoke translation. A unified "AI Card" format merging A2A Agent Cards and MCP Server Cards has been announced under the AAIF umbrella, but no specification has been published.¶
DNS lookup is not enough to establish trust. TLS gives a domain certificate, but a domain certificate alone does not establish trust in the agent behind it. Discovery mechanisms generally assume trust is established out of band. [I-D.klrc-aiagent-auth] maps existing IETF standards to agent auth, but the mapping between WIMSE workload identifiers and MCP server identity, or between SPIFFE trust domains and A2A Agent Card authentication, has not been written down. The Known partner use case requires verifying a partner's identity and capabilities before interaction, but no standard connects the identity returned by DNS-based lookup to the trust required for interaction. Establishing a root of trust - whether via a registry, WIMSE workload identity, or another mechanism - remains an open problem.¶
Most pull-based mechanisms (api-catalog, A2A Agent Cards, ANP descriptions) serve static metadata with no way to propagate capability changes to previously discovered clients. Soft-state registration with TTLs (as in [RFC9176]) addresses this for directory-based approaches; [I-D.jimenez-agent-directory] and [I-D.pioli-agent-discovery] both adopt this model. Well-known URI approaches have no equivalent, leaving the Curated set and Known partner use cases without change notification.¶
The .well-known URI namespace is under pressure from AI-related registrations. At IETF 125 DISPATCH, the designated expert reported agents.json, ai.txt, and /.well-known/ai were all filed without real specs. Multiple discovery approaches depend on .well-known URIs, making namespace coordination a practical concern.¶
Table 3 shows that no single mechanism addresses all five scenarios. A complete discovery system requires composing multiple mechanisms, but no standard defines how they compose or interoperate.¶
Agent discovery introduces security considerations around metadata integrity, impersonation, and information disclosure. [I-D.klrc-aiagent-auth] provides a framework for agent authentication and authorization using existing standards. [I-D.beyer-agent-identity-architecture] addresses human-anchored agent identity and delegation chains.¶
This document has no IANA actions.¶
The authors thank Heidi-Maria Back, Emil Zhang, Paul Ardeleanu, and Carlos Bravo for input and review.¶
This appendix expands the Known Partner illustration from Section 3.2 into a step-by-step sequence showing where existing standards apply. Not all mechanisms require all steps; this represents one possible composition.¶
Standard DNS resolution applies if the agent knows a domain name. SVCB records [RFC9460] can provide service parameters. DNS-AID [I-D.mozleywilliams-dnsop-dnsaid], DN-ANR [I-D.cui-dns-native-agent-naming-resolution], and AID [I-D.nemethi-aid-agent-identity-discovery] propose agent-specific DNS extensions. If the agent has only a capability description, it must query a directory or registry such as ARDP [I-D.pioli-agent-discovery].¶
Multiple competing well-known URIs exist: api-catalog [RFC9727], agent-card.json (A2A), agent-descriptions (ANP). There is no single standard entry point.¶
Each protocol defines its own metadata format. A2A uses Agent Cards, MCP uses JSON-RPC capability negotiation, ANP uses JSON-LD agent descriptions.¶
[I-D.klrc-aiagent-auth] maps 3 OAuth discovery mechanisms to agent auth: AS metadata [RFC8414], Protected Resource Metadata [RFC9728], and Client ID Metadata Documents.¶
The AIMS stack from [I-D.klrc-aiagent-auth] applies: identifier, credentials, attestation, provisioning, authentication, authorization.¶
Protocol-specific. A2A uses JSON-RPC over HTTPS, MCP uses JSON-RPC over Streamable HTTP or stdio, ANP uses HTTP.¶