A Survey of AI Agent Discovery Mechanisms
draft-jimenez-dawn-discovery-landscape-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jaime Jimenez , Jim Feng , Jari Arkko , Mirja Kühlewind , Rajat Kandoi | ||
| Last updated | 2026-07-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-jimenez-dawn-discovery-landscape-00
Discovery of Agents, Workloads, and Named entities (DAWN) J. Jimenez
Internet-Draft J. Feng
Intended status: Informational J. Arkko
Expires: 4 January 2027 M. Kuehlewind
R. Kandoi
Ericsson
3 July 2026
A Survey of AI Agent Discovery Mechanisms
draft-jimenez-dawn-discovery-landscape-00
Abstract
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.
About This Document
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/.
Status of This Memo
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/.
Jimenez, et al. Expires 4 January 2027 [Page 1]
Internet-Draft AI Agent Discovery July 2026
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 Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Discovery Framework . . . . . . . . . . . . . . . . . . . . . 6
3.1. Discovery Components . . . . . . . . . . . . . . . . . . 6
3.2. Illustrative Flow: Known Partner . . . . . . . . . . . . 8
4. Discovery Mechanisms . . . . . . . . . . . . . . . . . . . . 8
4.1. DNS-Based Resolution . . . . . . . . . . . . . . . . . . 8
4.1.1. DNS-AID . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. DN-ANR . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.3. AID . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1.4. AgentDNS . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Host-Level Self-Description . . . . . . . . . . . . . . . 9
4.2.1. IETF httpapi: api-catalog (RFC 9727) . . . . . . . . 10
4.2.2. A2A Agent Cards . . . . . . . . . . . . . . . . . . . 10
4.2.3. MCP Server Discovery . . . . . . . . . . . . . . . . 10
4.2.4. ANP Agent Descriptions . . . . . . . . . . . . . . . 11
4.2.5. AIDIP: Agent Discovery and Invocation . . . . . . . . 11
4.2.6. Other Community Efforts . . . . . . . . . . . . . . . 11
4.3. Registries and Directories . . . . . . . . . . . . . . . 11
4.3.1. 3GPP Network-Assisted Agent Discovery . . . . . . . . 11
4.3.2. IoA Framework (Semantic Discovery) . . . . . . . . . 12
4.3.3. ANP Agent Discovery Service Protocol (ADSP) . . . . . 13
4.3.4. AGNTCY Agent Directory Service (ADS) . . . . . . . . 13
4.3.5. Agent Registration and Discovery Protocol (ARDP) . . 14
4.3.6. Agent Directory (AD) . . . . . . . . . . . . . . . . 14
Jimenez, et al. Expires 4 January 2027 [Page 2]
Internet-Draft AI Agent Discovery July 2026
4.3.7. A2A Registry . . . . . . . . . . . . . . . . . . . . 15
5. Comparison . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Discovery Model and Scope . . . . . . . . . . . . . . . . 15
5.2. Component Coverage . . . . . . . . . . . . . . . . . . . 17
5.3. Use Case Applicability . . . . . . . . . . . . . . . . . 19
6. Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . . 20
6.1. No Standard for Semantic Discovery . . . . . . . . . . . 20
6.2. No Interoperable Federation . . . . . . . . . . . . . . . 20
6.3. Network and Application Layer Integration . . . . . . . . 20
6.4. Metadata Schema Fragmentation . . . . . . . . . . . . . . 21
6.5. Trust Bootstrapping . . . . . . . . . . . . . . . . . . . 21
6.6. No Lifecycle Management . . . . . . . . . . . . . . . . . 21
6.7. Well-Known Namespace Pressure . . . . . . . . . . . . . . 21
6.8. No Mechanism Spans All Use Cases . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9. Informative References . . . . . . . . . . . . . . . . . . . 22
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 26
Appendix B. Detailed Discovery Flow Example . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction
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.
Jimenez, et al. Expires 4 January 2027 [Page 3]
Internet-Draft AI Agent Discovery July 2026
+----------------+
| Large Language |
| Model (LLM) |
+------------+---+
^ |
| |
context action
| |
| v
+------+ +--+-----------------+ +----------------+
| User |---req--->| |-----act----->| Target tool, |
| or | | AI Agent |<-------------| service, or |
| Sys. |<---res---| (loop) | | resource |
+------+ | | +----------------+
| action selected: |
| - reason (LLM) | +----------------+
| - act |---discover-->| Discovery |
| - discover |<-------------| source |
| | +----------------+
+--------------------+
Figure 1: AI Agent with Discovery as an Action Type
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
Jimenez, et al. Expires 4 January 2027 [Page 4]
Internet-Draft AI Agent Discovery July 2026
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.
2. Use Cases
The surveyed discovery mechanisms address different scenarios that
differ mainly in the assumed trust based on who controls the set of
discoverable agents.
Curated set: 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.
Local context: 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.
Known partner: 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.
Federated consortium: 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.
Free-form search: 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
Jimenez, et al. Expires 4 January 2027 [Page 5]
Internet-Draft AI Agent Discovery July 2026
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.
3. Discovery Framework
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.
3.1. Discovery Components
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.
Jimenez, et al. Expires 4 January 2027 [Page 6]
Internet-Draft AI Agent Discovery July 2026
+--------+
| Lookup |
+--------+
|
| produces
v
+------+ validates
| Name |<--------------------+
+------+ |
| |
| points to |
v |
+-------------+ specifies +-------+
| Description |----------->| Trust |
+-------------+ +-------+
| |
| declares |
v |
+-------------+ validates |
| Interaction |<-------------+
+-------------+
Figure 2: Discovery Components and Their Relationships
Lookup: 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.
Name: 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.
Description: 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.
Trust: 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.
Interaction: The protocols used once trust is established: JSON-RPC,
Jimenez, et al. Expires 4 January 2027 [Page 7]
Internet-Draft AI Agent Discovery July 2026
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.
3.2. Illustrative Flow: Known Partner
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.
4. Discovery Mechanisms
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.
4.1. DNS-Based Resolution
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.
Jimenez, et al. Expires 4 January 2027 [Page 8]
Internet-Draft AI Agent Discovery July 2026
4.1.1. DNS-AID
[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.
4.1.2. DN-ANR
[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.
4.1.3. AID
[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.
4.1.4. AgentDNS
[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.
4.2. Host-Level Self-Description
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.
Jimenez, et al. Expires 4 January 2027 [Page 9]
Internet-Draft AI Agent Discovery July 2026
4.2.1. IETF httpapi: api-catalog (RFC 9727)
[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.
4.2.2. A2A Agent Cards
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.
4.2.3. MCP Server Discovery
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.
Jimenez, et al. Expires 4 January 2027 [Page 10]
Internet-Draft AI Agent Discovery July 2026
4.2.4. ANP Agent Descriptions
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.
4.2.5. AIDIP: Agent Discovery and Invocation
[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].
4.2.6. Other Community Efforts
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.
4.3. Registries and Directories
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.
4.3.1. 3GPP Network-Assisted Agent Discovery
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:
Jimenez, et al. Expires 4 January 2027 [Page 11]
Internet-Draft AI Agent Discovery July 2026
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.
4.3.2. IoA Framework (Semantic Discovery)
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.
Jimenez, et al. Expires 4 January 2027 [Page 12]
Internet-Draft AI Agent Discovery July 2026
4.3.3. ANP Agent Discovery Service Protocol (ADSP)
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.
4.3.4. AGNTCY Agent Directory Service (ADS)
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),
Jimenez, et al. Expires 4 January 2027 [Page 13]
Internet-Draft AI Agent Discovery July 2026
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.
4.3.5. Agent Registration and Discovery Protocol (ARDP)
[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.
4.3.6. Agent Directory (AD)
[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.
Jimenez, et al. Expires 4 January 2027 [Page 14]
Internet-Draft AI Agent Discovery July 2026
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).
4.3.7. A2A Registry
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.
5. Comparison
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.
5.1. Discovery Model and Scope
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.
Jimenez, et al. Expires 4 January 2027 [Page 15]
Internet-Draft AI Agent Discovery July 2026
+===========+========+============+=======+==============+========+
|Approach |Model |Scope |Dynamic| Cross-domain |Semantic|
+===========+========+============+=======+==============+========+
|api-catalog|Pull |Per-host |No | No |No |
+-----------+--------+------------+-------+--------------+--------+
|A2A Agent |Pull |Per-agent |No | Yes (known |No |
|Cards | | | | host) | |
+-----------+--------+------------+-------+--------------+--------+
|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 | Yes |No |
| | | |(TTL) | (federation) | |
+-----------+--------+------------+-------+--------------+--------+
|Directory |Registry|Cross-domain|Yes | Yes |No |
|(AD) | | |(TTL) | (federation) | |
+-----------+--------+------------+-------+--------------+--------+
|A2A |Curated |A2A agents |Health | No |No |
|Registry | | |check | | |
+-----------+--------+------------+-------+--------------+--------+
|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) |
+-----------+--------+------------+-------+--------------+--------+
Table 1: Discovery Model and Scope
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.
Jimenez, et al. Expires 4 January 2027 [Page 16]
Internet-Draft AI Agent Discovery July 2026
* 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.
5.2. Component Coverage
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.
Jimenez, et al. Expires 4 January 2027 [Page 17]
Internet-Draft AI Agent Discovery July 2026
+===========+==========+========+============+========+===========+
|Approach |Lookup |Name |Description |Trust |Interaction|
+===========+==========+========+============+========+===========+
|api-catalog|Well-known|- |API list |TLS |- |
| |URI | | | | |
+-----------+----------+--------+------------+--------+-----------+
|A2A Agent |Well-known|- |Agent Card |Per-card|- |
|Cards |URI | | |auth | |
+-----------+----------+--------+------------+--------+-----------+
|MCP |Local |- |JSON-RPC |- |JSON-RPC |
| |config | |caps | | |
+-----------+----------+--------+------------+--------+-----------+
|ANP ADSP |Crawl/ |DID |JSON-LD |DID |HTTP |
| |index | | | | |
+-----------+----------+--------+------------+--------+-----------+
|AGNTCY ADS |DHT query |CID |OASF record |- |- |
+-----------+----------+--------+------------+--------+-----------+
|3GPP 6G |Registry |Operator|Capabilities|Operator|Per-API |
| |query | | |PKI | |
+-----------+----------+--------+------------+--------+-----------+
|IoA |Registry |Platform|Capabilities|- |Structured |
| |query | | | | |
+-----------+----------+--------+------------+--------+-----------+
|ARDP |Query |agent: |Capabilities|JWS |- |
| | |URI | |proof | |
+-----------+----------+--------+------------+--------+-----------+
|Directory |Registry |Scoped |Cap. views |TLS + |- |
|(AD) |query | | |ident. | |
+-----------+----------+--------+------------+--------+-----------+
|A2A |Web browse|URL |Card link |- |- |
|Registry | | | | | |
+-----------+----------+--------+------------+--------+-----------+
|DNS-AID |DNS query |FQDN |- |DNSSEC/ |- |
| | | | |DANE | |
+-----------+----------+--------+------------+--------+-----------+
|DN-ANR |DNS query |FQDN |- |DNSSEC |- |
+-----------+----------+--------+------------+--------+-----------+
|AID |DNS TXT |FQDN |- |Ed25519 |- |
| |query | | |(opt) | |
+-----------+----------+--------+------------+--------+-----------+
|AgentDNS |DNS query |Domain |Semantic |- |- |
+-----------+----------+--------+------------+--------+-----------+
|AIDIP |Semantic |- |Capabilities|- |Invocation |
| |query | | | | |
+-----------+----------+--------+------------+--------+-----------+
Table 2: Component Coverage by Mechanism
Jimenez, et al. Expires 4 January 2027 [Page 18]
Internet-Draft AI Agent Discovery July 2026
5.3. Use Case Applicability
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| Local | Known | Federated | Free-form |
| |set | context | partner | consortium | search |
+=============+=======+=========+=========+============+===========+
| api-catalog |Yes | Yes | Yes | Partial | Partial |
+-------------+-------+---------+---------+------------+-----------+
| A2A Agent |- | - | Yes | - | - |
| Cards | | | | | |
+-------------+-------+---------+---------+------------+-----------+
| MCP |Yes | Partial | - | - | - |
+-------------+-------+---------+---------+------------+-----------+
| ANP ADSP |- | - | Yes | Partial | Yes |
| | | | | (DID) | |
+-------------+-------+---------+---------+------------+-----------+
| AGNTCY ADS |- | - | - | Yes (DHT) | Yes |
+-------------+-------+---------+---------+------------+-----------+
| 3GPP 6G |- | Yes | - | Partial | - |
| | | | | (operator) | |
+-------------+-------+---------+---------+------------+-----------+
| IoA |- | - | - | - | Yes |
+-------------+-------+---------+---------+------------+-----------+
| ARDP |- | Partial | Yes | Yes | - |
+-------------+-------+---------+---------+------------+-----------+
| Directory |Yes | Yes | Yes | Partial | Partial |
| (AD) | | | | | |
+-------------+-------+---------+---------+------------+-----------+
| A2A |- | - | - | - | Partial |
| Registry | | | | | (human) |
+-------------+-------+---------+---------+------------+-----------+
| DNS-AID |- | Yes | Yes | - | - |
+-------------+-------+---------+---------+------------+-----------+
| DN-ANR |- | Yes | Yes | - | - |
+-------------+-------+---------+---------+------------+-----------+
| AID |- | Yes | Yes | - | - |
+-------------+-------+---------+---------+------------+-----------+
| AgentDNS |- | - | - | - | Partial |
+-------------+-------+---------+---------+------------+-----------+
| AIDIP |- | - | Partial | - | Yes (ASR) |
+-------------+-------+---------+---------+------------+-----------+
Table 3: Use Case Applicability by Mechanism
Jimenez, et al. Expires 4 January 2027 [Page 19]
Internet-Draft AI Agent Discovery July 2026
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.
6. Gap Analysis
This section identifies gaps that emerge from the comparison in
Section 5. Each gap represents a problem that no surveyed mechanism
fully solves.
6.1. No Standard for Semantic Discovery
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.
6.2. No Interoperable Federation
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.
6.3. Network and Application Layer Integration
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.
Jimenez, et al. Expires 4 January 2027 [Page 20]
Internet-Draft AI Agent Discovery July 2026
6.4. Metadata Schema Fragmentation
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.
6.5. Trust Bootstrapping
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.
6.6. No Lifecycle Management
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.
6.7. Well-Known Namespace Pressure
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.
Jimenez, et al. Expires 4 January 2027 [Page 21]
Internet-Draft AI Agent Discovery July 2026
6.8. No Mechanism Spans All Use Cases
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.
7. Security Considerations
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.
8. IANA Considerations
This document has no IANA actions.
9. Informative References
[A2A-spec] "Agent-to-Agent Protocol Specification", 2025,
<https://google.github.io/A2A/>.
[ANP-spec] "Agent Network Protocol", 2025, <https://github.com/agent-
network-protocol/AgentNetworkProtocol>.
[I-D.akhavain-moussa-dawn-problem-statement]
Akhavain, A., Moussa, H., and D. King, "Problem Statement
for the Discovery of Agents, Workloads, and Named Entities
(DAWN)", Work in Progress, Internet-Draft, draft-akhavain-
moussa-dawn-problem-statement-04, 12 June 2026,
<https://datatracker.ietf.org/doc/html/draft-akhavain-
moussa-dawn-problem-statement-04>.
[I-D.beyer-agent-identity-architecture]
Beyer, B., "Architecture for Human-Anchored Agent
Identity, Delegation, and Provenance", Work in Progress,
Internet-Draft, draft-beyer-agent-identity-architecture-
00, 1 April 2026, <https://datatracker.ietf.org/doc/html/
draft-beyer-agent-identity-architecture-00>.
[I-D.cui-ai-agent-discovery-invocation]
Cui, Y., Chao, Y., and C. Du, "AI Agent Discovery and
Invocation Protocol", Work in Progress, Internet-Draft,
draft-cui-ai-agent-discovery-invocation-01, 12 February
2026, <https://datatracker.ietf.org/doc/html/draft-cui-ai-
agent-discovery-invocation-01>.
Jimenez, et al. Expires 4 January 2027 [Page 22]
Internet-Draft AI Agent Discovery July 2026
[I-D.cui-dns-native-agent-naming-resolution]
Cui, Y., "DNS-Native AI Agent Naming and Resolution", Work
in Progress, Internet-Draft, draft-cui-dns-native-agent-
naming-resolution-01, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-cui-dns-
native-agent-naming-resolution-01>.
[I-D.farrel-dawn-terminology]
Farrel, A., Yao, K., Schott, R., and N. Williams,
"Terminology for the Discovery of Agents, Workloads, and
Named Entities (DAWN)", Work in Progress, Internet-Draft,
draft-farrel-dawn-terminology-02, 4 June 2026,
<https://datatracker.ietf.org/doc/html/draft-farrel-dawn-
terminology-02>.
[I-D.ietf-httpapi-authentication-link]
Pot, E., "Link relationship types for authentication",
Work in Progress, Internet-Draft, draft-ietf-httpapi-
authentication-link-01, 3 March 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-
authentication-link-01>.
[I-D.ietf-httpapi-link-hint]
Nottingham, M., "HTTP Link Hints", Work in Progress,
Internet-Draft, draft-ietf-httpapi-link-hint-04, 10 August
2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
httpapi-link-hint-04>.
[I-D.jimenez-agent-directory]
Jimenez, J., "Agent Directory", Work in Progress,
Internet-Draft, draft-jimenez-agent-directory-01, 8 May
2026, <https://datatracker.ietf.org/doc/html/draft-
jimenez-agent-directory-01>.
[I-D.king-dawn-requirements]
King, D. and A. Farrel, "Requirements for the Discovery of
Agents, Workloads, and Named Entities (DAWN)", Work in
Progress, Internet-Draft, draft-king-dawn-requirements-01,
28 April 2026, <https://datatracker.ietf.org/doc/html/
draft-king-dawn-requirements-01>.
[I-D.klrc-aiagent-auth]
Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B.,
Steele, N., and A. Parecki, "AI Agent Authentication and
Authorization", Work in Progress, Internet-Draft, draft-
klrc-aiagent-auth-02, 1 June 2026,
<https://datatracker.ietf.org/doc/html/draft-klrc-aiagent-
auth-02>.
Jimenez, et al. Expires 4 January 2027 [Page 23]
Internet-Draft AI Agent Discovery July 2026
[I-D.liang-agentdns]
梁致远, Cui, E., and Y. Cheng, "AgentDNS: A Root Domain
Naming System for LLM Agents", Work in Progress, Internet-
Draft, draft-liang-agentdns-00, 8 October 2025,
<https://datatracker.ietf.org/doc/html/draft-liang-
agentdns-00>.
[I-D.mozley-aidiscovery]
Mozley, J., Williams, N., Sarikaya, B., and R. Schott, "AI
Agent Discovery (AID) Problem Statement", Work in
Progress, Internet-Draft, draft-mozley-aidiscovery-01, 16
April 2026, <https://datatracker.ietf.org/doc/html/draft-
mozley-aidiscovery-01>.
[I-D.mozleywilliams-dnsop-dnsaid]
Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J.
Damick, "DNS for AI Discovery", Work in Progress,
Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, 27
May 2026, <https://datatracker.ietf.org/doc/html/draft-
mozleywilliams-dnsop-dnsaid-02>.
[I-D.mp-agntcy-ads]
"Agent Directory Service", 2025,
<https://spec.dir.agntcy.org>.
[I-D.nemethi-aid-agent-identity-discovery]
Nemethi, B., "Agent Identity and Discovery (AID)", Work in
Progress, Internet-Draft, draft-nemethi-aid-agent-
identity-discovery-00, 16 March 2026,
<https://datatracker.ietf.org/doc/html/draft-nemethi-aid-
agent-identity-discovery-00>.
[I-D.pioli-agent-discovery]
Pioli, R., "Agent Registration and Discovery Protocol
(ARDP)", Work in Progress, Internet-Draft, draft-pioli-
agent-discovery-01, 24 February 2026,
<https://datatracker.ietf.org/doc/html/draft-pioli-agent-
discovery-01>.
[I-D.yao-catalist-problem-space-analysis]
Yao, K. and Z. Sarker, "Problem Space Analysis of AI Agent
Protocols in IETF", Work in Progress, Internet-Draft,
draft-yao-catalist-problem-space-analysis-01, 2 March
2026, <https://datatracker.ietf.org/doc/html/draft-yao-
catalist-problem-space-analysis-01>.
Jimenez, et al. Expires 4 January 2027 [Page 24]
Internet-Draft AI Agent Discovery July 2026
[I-D.yu-dmsc-ai-agent-use-cases-in-6g]
Yu, M., Wang, A., Li, J., and Z. Li, "AI Agent Use Cases
and Requirements in 6G Network", Work in Progress,
Internet-Draft, draft-yu-dmsc-ai-agent-use-cases-in-6g-01,
11 January 2026, <https://datatracker.ietf.org/doc/html/
draft-yu-dmsc-ai-agent-use-cases-in-6g-01>.
[IoA] "Internet of Agents: Weaving a Web of Heterogeneous
Agents", 2024, <https://github.com/OpenBMB/IoA>.
[MCP-registry]
"Model Context Protocol Registry", 2025,
<https://github.com/modelcontextprotocol/registry>.
[MCP-spec] "Model Context Protocol Specification", 2025,
<https://modelcontextprotocol.io/specification>.
[OASF] "Open Agentic Schema Framework", 2025,
<https://docs.agntcy.org/oasf/open-agentic-schema-
framework/>.
[RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
Authorization Server Metadata", RFC 8414,
DOI 10.17487/RFC8414, June 2018,
<https://www.rfc-editor.org/rfc/rfc8414>.
[RFC9176] Amsüss, C., Ed., Shelby, Z., Koster, M., Bormann, C., and
P. van der Stok, "Constrained RESTful Environments (CoRE)
Resource Directory", RFC 9176, DOI 10.17487/RFC9176, April
2022, <https://www.rfc-editor.org/rfc/rfc9176>.
[RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
and Parameter Specification via the DNS (SVCB and HTTPS
Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.
[RFC9727] Smith, K., "api-catalog: A Well-Known URI and Link
Relation to Help Discovery of APIs", RFC 9727,
DOI 10.17487/RFC9727, June 2025,
<https://www.rfc-editor.org/rfc/rfc9727>.
[RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0
Protected Resource Metadata", RFC 9728,
DOI 10.17487/RFC9728, April 2025,
<https://www.rfc-editor.org/rfc/rfc9728>.
Jimenez, et al. Expires 4 January 2027 [Page 25]
Internet-Draft AI Agent Discovery July 2026
[TR22.870] 3GPP, "Study on 6G Use Cases and Service Requirements",
2026,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=4374>.
[TR23.801] 3GPP, "Study on System Architecture for 6G", 2026,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=4542>.
[TR23.801-02]
3GPP, "Study on 6G Application Enablement", 2026,
<https://portal.3gpp.org/desktopmodules/Specifications/
SpecificationDetails.aspx?specificationId=4574>.
[TS23.222] 3GPP, "Common API Framework for 3GPP Northbound APIs
(CAPIF)", 2024.
Appendix A. Acknowledgments
The authors thank Heidi-Maria Back, Emil Zhang, Paul Ardeleanu, and
Carlos Bravo for input and review.
Appendix B. Detailed Discovery Flow Example
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.
Jimenez, et al. Expires 4 January 2027 [Page 26]
Internet-Draft AI Agent Discovery July 2026
Agent starts with intent and entrypoint (URI)
|
v
+------------------+
| 1. Resolve entry | DNS A/AAAA, SVCB/HTTPS records,
| point | SRV, DNS-SD, DANE/TLSA
+--------+---------+ Or: query directory/registry
|
v
+------------------+
| 2. Fetch host | GET /.well-known/api-catalog
| metadata | GET /.well-known/agent-card.json
| | GET /.well-known/agent-descriptions
+--------+---------+
|
v
+------------------+
| 3. Fetch agent | GET /agent/{id}/agent-card.json
| metadata | JSON-RPC initialize (MCP)
| | Returns: capabilities, auth reqs
+--------+---------+
|
v
+------------------+
| 4. Discover auth | GET /.well-known/oauth-authorization-server
| requirements | GET /.well-known/oauth-protected-resource
| | From Agent Card: required schemes
+--------+---------+
|
v
+------------------+
| 5. Authenticate | SPIFFE/WIMSE or other attestation
| and authorize | OAuth 2.0 token acquisition
| | mTLS setup
+--------+---------+
|
v
+------------------+
| 6. Establish | HTTPS, WebSocket, SSE, gRPC
| transport | Protocol negotiation
+--------+---------+
|
v
+------------------+
| 7. Begin | Send task with auth tokens
| interaction | Handle streaming responses
+------------------+
Jimenez, et al. Expires 4 January 2027 [Page 27]
Internet-Draft AI Agent Discovery July 2026
Figure 3: Example End-to-End Agent Discovery Flow
Step 1 (resolve entry point): 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].
Step 2 (fetch host metadata): Multiple competing well-known URIs
exist: api-catalog [RFC9727], agent-card.json (A2A), agent-
descriptions (ANP). There is no single standard entry point.
Step 3 (fetch agent metadata): Each protocol defines its own
metadata format. A2A uses Agent Cards, MCP uses JSON-RPC
capability negotiation, ANP uses JSON-LD agent descriptions.
Step 4 (discover auth requirements): [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.
Step 5 (authenticate): The AIMS stack from [I-D.klrc-aiagent-auth]
applies: identifier, credentials, attestation, provisioning,
authentication, authorization.
Steps 6-7 (transport and interaction): Protocol-specific. A2A uses
JSON-RPC over HTTPS, MCP uses JSON-RPC over Streamable HTTP or
stdio, ANP uses HTTP.
Authors' Addresses
Jaime Jimenez
Ericsson
Email: jaime@iki.fi
Jim Feng
Ericsson
Email: jim.feng@ericsson.com
Jari Arkko
Ericsson
Email: jari.arkko@ericsson.com
Jimenez, et al. Expires 4 January 2027 [Page 28]
Internet-Draft AI Agent Discovery July 2026
Mirja Kuehlewind
Ericsson
Email: mirja.kuehlewind@ericsson.com
Rajat Kandoi
Ericsson
Email: rajat.kandoi@ericsson.com
Jimenez, et al. Expires 4 January 2027 [Page 29]