Agent Resource Discovery (ARD) Architecture

Conventions and Definitions The following terms are used throughout the ARD documents:

Agentic Resource (or Resource):: A network-accessible capability — such as an autonomous agent (A2A), an MCP server, a static AI skill, an API service, or an ARD Registry — that a consumer discovers and interacts with. In ARD, each resource is described by a protocol-specific descriptor (e.g., an A2A Agent Card, an MCP server card, or a skill document) referenced by the entry's url or carried inline in data.
ARD Entry:: An entry in a registry or manifest that describes one agentic resource for discovery, or that points to another ARD Registry. Its format is specified in .
Manifest:: A static or dynamically generated application/ard+json document containing an array of ARD entries (). A manifest is reached at an entry point discovered via (including a well-known URI), may contain entries from one or multiple publishers, and may include or consist of an entry that points to an ARD Registry.
Entry Point:: The URI of an ARD manifest, together with the source from which the client learned it (). An entry point is unverified until the client has retrieved the manifest and authenticated the origin.
Initial Contact:: The process by which a client obtains one or more entry points, starting from a domain name, a local network attachment, or configuration ().
ARD Registry:: The component that holds entries and offers two interfaces, discovery of entries and registration of entries. A registry may also populate itself by crawling and ingesting manifests. The discovery interface is specified in ; the registration interface is to be specified separately ().
Publisher:: The party that controls a domain name and publishes resources under it, by serving a manifest that lists them or by registering entries with an ARD Registry. The domain name appears as <publisher> in the discovery identifiers of its entries. In its interactions with a registry, a publisher acts as a client.
Consumer:: A client that discovers entries through a manifest or an ARD Registry and retrieves or invokes the described resource at its url. Consumers include agents, applications whose behavior is driven by a language model acting on a user's intent, orchestrators, and other workloads.
Domain Owner:: The party that controls the DNS domain name under which a manifest or an ARD Registry is reached. For a publisher's own manifest, the domain owner is the publisher. For an aggregator or a third-party registry, the domain owner operates the manifest or registry while each entry identifies its own publisher.
Discovery Identifier:: A persistent, location-independent identifier that uniquely identifies an agentic resource across manifests and registries. In , it uses the Uniform Resource Name (URN) syntax urn:air:<publisher>:<namespace>:<agent-name>, decoupling publisher identity (<publisher>) from both the manifest or registry host (Domain Owner) and the runtime endpoint (url). Local or non-DNS deployments may bind identifiers to their respective trust domain anchors.
Trust Manifest:: An optional cryptographic envelope within an ARD entry that asserts publisher or third-party verifier identity, software provenance, and compliance attestations ().

System Architecture and Interaction Flows shows the components of the architecture and the interfaces between them, with the specification that defines each interface. Arrows start at the party that initiates an interaction. A consumer may discover entries directly by retrieving a manifest via initial contact, or by querying an ARD Registry (which may itself be discovered via an entry in a manifest). The registration interface is to be specified in a later document (); runtime access to a resource is outside the scope of ARD.

Agent Resource Discovery Architecture and Protocol Mapping | | | | | Publisher | | Consumer | +----------------+ Crawl | / Domain | | | | |-------------->| Owner | | |--------->| ARD Registry | | | | | Lookup, | |<--------------| | | | Search +----------------+ Register +-----------+ | | [ARD] [TBD] | +----------+ | | | | Access (at Entry `url`) Publishes | v v +------------------------------------------------------------------+ | Agentic Resource (Hosted on Same or Separate Domain) | +------------------------------------------------------------------+ ]]> The architecture separates discovery from runtime execution across four lifecycle phases:

Publishing and Initial Contact: A domain owner or publisher serves a manifest at a well-known URI or advertises its manifest or ARD Registry through the DNS, HTTP link, and local-link mechanisms of ; a manifest lists entries directly or includes an entry that points to an ARD Registry. A client obtains the entry point through initial contact or configuration. Publishers, live workloads, or Commissioning Tools can also register entries dynamically with an ARD Registry through the Registration interface ().
Indexing: An ARD Registry may serve a single domain or aggregate entries across domains. It populates its indices through registrations or by crawling manifests located through the mechanisms of .
Lookup and Search: Consumers discover entries either by querying an ARD Registry using structured filters, faceted exploration, or natural-language queries (), or by reading a manifest obtained through initial contact ().
Descriptor Resolution and Access: The consumer retrieves the protocol descriptor at the entry's url (or reads it from inline data), optionally verifies it against the entry's digest and trustManifest, and accesses the resource using its native protocol. The host at url may be in the publisher's domain or in a third-party hosting domain; the entry's identifier, digest, and trustManifest bind the resource to <publisher>. The registry takes no part in runtime access.

Manifest Data Model A manifest is a JSON document of media type application/ard+json with one top-level member, entries, an array of ARD entries (). A publisher serves it at /.well-known/ard.json. An ARD Registry is also a collection of entries, reached through its discovery interface. A registry obtains its entries by reading manifests or through dynamic registration. An entry describes a single agentic resource, combining core descriptive metadata, payload delivery references, discovery signals, and cryptographic trust assertions (). shows the data model of a manifest. A manifest contains any number of entries, and each entry references exactly one resource. An ARD entry comprises:

Core Envelope: The discovery identifier (a globally unique URI or domain-anchored URN, such as urn:air), the artifact media type (e.g., application/mcp-server-card+json, application/a2a-agent-card+json), and exactly one of url (hypermedia reference to the capability descriptor) or data (inline artifact payload). An entry may also include an algorithm-prefixed cryptographic digest to lock referenced descriptor contents.
Descriptive Metadata: Human-readable attributes including displayName, description, version, and categorical tags.
Discovery Signals: Search attributes that enable high-performance indexing without pre-fetching external artifacts:
- representativeQueries: A list of natural language prompts or queries that the capability satisfies, serving as the primary input for semantic vector and hybrid search indices.
- capabilities: Structured tokens or vocabulary terms identifying specific tools or skills for precise filtering.
Provenance and Trust: An optional trustManifest signed by <publisher>, binding publisher identity, claims, and the artifact digest. The publisher of an entry is established from its trustManifest; the host that serves a manifest or operates a registry establishes nothing about the publishers of the entries it holds.
Open Extensibility: As a JSON-LD node (), an entry inherits the ARD base context and can be extended with domain-specific terms via @context.

Manifest Data Model The resource is served by the publisher in its native format, for example an A2A Agent Card, an MCP server description, a skill, or an API description. Manifests and registries hold entries; a consumer that needs the resource follows the url. An entry that carries the resource inline as data is the exception. A manifest may consist of a single entry whose url is the base URI of a registry; a consumer that retrieves such a manifest proceeds through the registry's discovery interface.

Deployment Topologies ARD is deployed in three settings, which differ in how a consumer reaches a registry and in which party attests to the publisher of an entry:

Local network: A home or small office network without an administrator. Consumers find manifests and registries on the link through Multicast DNS and DNS-SD, or through a network-provided domain name, as specified in . Resources on the network register with a local registry through the Registration interface, and their entries expire when the resources leave the network. Entry points learned over multicast are the least trusted source, and local policy determines which of them a consumer uses.
Private network: The infrastructure of a single organization, within one administrative and trust domain. A registry indexes the organization's resources and is reached through configured entry points or the organization's own DNS. Publisher authority and the authorization to register are established by the organization's identity infrastructure, and the registry is reachable only within the organization.
Internet: Publishers and registries on the public Internet, anchored in the DNS. A consumer starts from a domain name and reaches a publisher's manifest through the organization index record, DNS-SD, the well-known URI, or the ard link relation (). A registry may crawl manifests across domains and accept registrations from publishers in other domains. Each entry carries its publisher's domain in its discovery identifier and an optional trustManifest signed by the publisher, so a consumer can verify the publisher of an entry regardless of which registry returned it.

In every setting a publisher serves its manifest at /.well-known/ard.json; the well-known URI is mandatory to implement in , and the other mechanisms supplement it. A manifest that lists entries directly is the simplest form of the registry role and supports discovery of entries only. A manifest that consists of a single entry pointing at a registry directs the consumer to the registry's discovery interface.

Core Architectural Principles ARD is designed according to seven foundational principles:

Hypermedia-Based Discovery Discovery in ARD is hypermedia-based. A consumer follows links: from an entry point to a manifest, from a manifest to its entries or to a registry, from a registry response to entries, and from an entry to the resource at its url. A registry offers a lookup interface over its entries with structured filters and, where the registry supports it, natural-language or semantic search (). The entries in a registry are maintained either by the registry itself, which crawls and ingests manifests, or by publishers, which register and refresh their entries through the Registration interface. An entry is discoverable as soon as the registry has indexed it.

Search-First Dynamic Discovery Capabilities are discovered on demand at runtime based on natural language task descriptions and structured constraints, rather than pre-installed statically. Registries maintain continuously refreshed semantic and structured indices, allowing newly published capabilities to be discovered immediately without client recompilation or manual reconfiguration.

Scalability Beyond Context Windows Traditional tool selection relies on injecting every candidate tool description into the model's context window, which does not scale as collections grow to thousands or millions of resources. While a client can rank a small, pre-fetched set of tools locally, local ranking still requires each client to know, fetch, and index the candidate corpus in advance. ARD moves candidate discovery outside the model into a dedicated search service (whether deployed over a curated enterprise catalog or across open domains), where richer signals such as representativeQueries, publisher identity, compliance metadata, and structured attributes can be indexed, and where publisher identity and trust attestations (trustManifest) can be verified ahead of time during ingestion rather than by each client at runtime. The client queries the registry and receives only the top-k relevant entries to inject into its context window.

Artifact-Agnostic Envelope ARD does not define or standardize the internal schemas of specific resource architectures. Instead, it serves as a protocol-neutral envelope. The entry's type field uses IANA Media Types to declare whether the resource is an MCP server (application/mcp-server-card+json), an A2A agent (application/a2a-agent-card+json), an AI skill (application/ai-skill+md), or an Agent Registry (application/ai-registry+json).

Open Namespace Extensibility via JSON-LD Every ARD entry is a JSON-LD node. Core discovery terms are defined in the default ARD base context. Publishers may enrich entries with terms from arbitrary external namespaces (e.g., industry taxonomies, regulatory tags, or pricing models) through @context declarations. Registries index known terms and preserve unrecognized terms, enabling open evolution without revisions to the core specifications.

Universal HTTP REST Baseline To guarantee universal interoperability regardless of execution environments, every ARD Registry exposes a standard HTTP REST interface over HTTPS conforming to . While registries may additionally offer protocol-specific wrappers (such as an MCP tool or A2A skill wrapper), the HTTPS REST API represents the universal baseline.

Strict Separation of Concerns Operational and architectural concerns are decoupled across layers:

Discovery vs. Resolution: ARD identifies what capabilities exist and where their authoritative descriptors or endpoints reside. Lower-level name resolution and transport routing remain delegated to standard DNS and network primitives.
Discovery vs. Execution: ARD is link-based. Once an agentic resource is discovered, the client follows the artifact reference (url) and invokes the resource directly via its native protocol (e.g., JSON-RPC over HTTP/SSE for MCP, HTTP/REST for A2A, or gRPC). The discovery registry never sits in the runtime execution data path.
Identification vs. Network Location: An agentic resource's discovery identifier (urn:air:<publisher>:...) is decoupled from both the manifest/registry hosting origin (Domain Owner) and the physical execution endpoint (url). This allows registries and manifests to aggregate entries across publishers, and allows a resource's runtime endpoint to be hosted on or migrated across cloud providers without changing its identifier.
Search Relevance vs. Security Evaluation: Semantic search scores indicate textual relevance only and do not represent trust, safety, or compliance assertions.
Discovery vs. Authorization: Authentication, token negotiation, and runtime access control are handled by the resource endpoint during invocation, while cryptographic provenance (trustManifest) allows registries and consumers to verify publisher authority independently of where a manifest or registry is hosted.