UHP vs Agentic Resource Discovery (ARD)

Resolve a discovery entry before treating it as an endpoint

The current ARD proposal is v0.91 and restates its description layer using JSON-LD and namespaces. The preserved v0.9 draft is a predecessor, not an interchangeable schema. UHP 2026-09-28 Draft remains the execution contract. Both sides were reopened 4 October 2026.

Resolution step	Consumer responsibility
Fetch publisher discovery document	Follow /.well-known/ard.json and the specified rel="ard" discovery path
Read an entry	Resolve terms under the effective context; do not assume every payload uses old v0.9 field semantics
Select a referenced artifact	Check its media type, identity, version and origin before use
Invoke an agent/tool	Negotiate the referenced protocol and authorization separately

The current proposal says a registry response must carry identifier, while other terms may be omitted. A sparse search result therefore needs further resolution before a client can assume it contains a complete connection contract. representativeQueries helps semantic indexing; it is not an authorization or capability proof.

For a potential UHP service, resolve its actual endpoint and inspect UHP discovery before submitting work. DNS-AID addresses a separate domain-controlled location/trust layer. A discovery result naming MCP or A2A does not define a native UHP binding, and community media types must not be reported as finalized IANA registrations.

The one-sentence difference

ARD is a pre-invocation discovery layer for finding agentic resources across published entry sources and registries. UHP is an execution contract for submitting work to servers that run complete agent harnesses. ARD helps answer what should I connect to?; UHP helps answer how do I execute work through a harness server consistently?

Status first

• UHP is 2026-09-28, a Draft standard with a runnable 85-check conformance suite (2026.9.28.post3).
• ARD’s current published specification is v0.91, status Proposal, dated 26 August 2026. PR #81 promoted the reviewed v0.91 draft to spec/ard.md; the former v0.9 specification is preserved as spec/ard-v0.9.md.
• v0.91 makes the ARD entry the discovery object, restates the description layer in JSON-LD with namespaces, and keeps ARD conformance self-contained while preserving compatibility with existing catalog-style entries.
• The current discovery names are normative: a consumer resolving a domain MUST fetch /.well-known/ard.json and MUST honour rel="ard". The predecessor /.well-known/ai-catalog.json path and rel="ai-catalog" relation are now optional compatibility lookups (MAY), not required fallbacks.
• The ARD repository now publishes an official zero-dependency conformance CLI for validating manifests, publisher resolution and registry REST behavior.

Architectural comparison

Dimension	UHP	ARD
Primary boundary	Product/client ↔ UHP server ↔ complete harness runtime	Publisher/entry source ↔ discovery registry ↔ discovery client
Main purpose	Execute agent work consistently across harnesses	Publish, index, search and discover agentic resources before invocation
Published/current entry point	GET /v1/uhp discovers a UHP server’s protocol/version/capabilities; harness APIs expose that server’s harness catalog	Published v0.91 requires consumers to fetch /.well-known/ard.json and honour rel="ard"; predecessor AI Catalog names may also be consulted for compatibility
Search model	No federated web-scale resource-search contract	Standard registry REST surface includes POST /search, optional POST /explore and GET /agents APIs
Resource model	Harnesses, responses, sessions, containers, files, artifacts and events	JSON-LD ARD entry carrying comparable discovery signals while remaining compatible with catalog entries
Federation	UHP does not define registry federation	ARD defines registry federation modes including automatic federation, referrals and no federation
Identity/trust	UHP authenticates callers and scopes server objects; implementation security applies around the harness runtime	Domain-anchored publication plus optional trust metadata; ARD can carry identity, attestations, provenance and signatures
Runtime authentication	UHP defines its own server authentication/scoping requirements	ARD deliberately delegates runtime authentication/authorization to the native protocol or API of the discovered resource
Execution	UHP submits, streams, continues and cancels tasks and exposes files/artifacts	ARD stops at discovery/resolution; the selected resource is then used through its native protocol or API
Maturity snapshot	Draft standard with conformance suite and a reference implementation	Published v0.91 Proposal with schemas, OpenAPI and official conformance CLI

ARD’s discovery model

The published v0.91 specification separates two complementary discovery paths:

1. Static publication. A publisher exposes ARD entries through sources such as /.well-known/ard.json, in-page JSON-LD, robots.txt Agentmap directives, rel="ard" links or DNS records. The well-known path contains a manifest whose entries follow the ARD entry model.
2. Dynamic registry search. Registries crawl or ingest published entry sources, index the entries and expose a standard HTTP REST search interface. Web ingestion is required; additional pipelines such as Git, package registries or OCI registries may be supported by an implementation.

The compatibility rule changed materially from the earlier v0.9 model. Under current v0.91, a consumer resolving a domain MUST fetch /.well-known/ard.json and honour rel="ard". It MAY additionally consult the predecessor /.well-known/ai-catalog.json path and rel="ai-catalog" relation, but doing so is a courtesy to older publishers rather than a conformance requirement. Publishers are therefore expected to move to the ARD-named forms rather than relying on mandatory fallback.

The underlying architectural distinction remains stable: discovery metadata tells a client what exists and where to find it; the resource’s native protocol defines what happens after connection.

ARD and AI Catalog are related, but they are not the same specification

The earlier ARD v0.9 specification aligned closely with the broader AI Catalog format and built its capability manifest on catalog entries. Published ARD v0.91 now sharpens that separation while preserving compatibility.

The separate AI Catalog working draft defines a common artifact envelope. It uses the media type application/ai-catalog+json, supports nested catalogs, identifies native artifacts by media type, and provides an optional Trust Manifest for identity, attestations and provenance without redefining the underlying MCP, A2A or other artifact schemas.

Current ARD v0.91 defines its own ARD entry and its own conformance. The entry is a JSON-LD node expanded against the ARD base context. Every ARD entry is a well-formed catalog entry, but not every catalog entry is an ARD entry: ARD adds the comparable discovery signals that search needs. representativeQueries is a SHOULD; missing or differently sized query examples produce a conformance warning rather than structural failure so existing tooling can remain compatible.

The published specification also makes the individual entry — rather than a hosted catalog container — the unit ARD describes, indexes and returns. This is now current ARD behavior rather than merely a proposed next-step architecture.

AI Catalog’s governance and maturity remain distinct from ARD. The AI Catalog repository describes itself as a temporary Linux Foundation working repository where members from MCP, A2A and other ecosystems are collaborating. Its adoption section says the A2A and MCP steering committees are expected to vote on adoption after the specification is finalized. This guide therefore treats AI Catalog as an emerging shared discovery substrate, not as an already-adopted MCP or A2A standard.

Note

Do not collapse ARD into AI Catalog. Published ARD v0.91 has its own JSON-LD entry and conformance model while retaining catalog compatibility. That does not make AI Catalog an adopted MCP/A2A standard, and it does not make ARD part of MCP or A2A.

Current conformance surface

ARD v0.91 publishes machine-readable artifacts and an official conformance tool in the specification repository:

• JSON Schema defines the ArdEntry / ArdManifest structural model.
• OpenAPI 3.1 defines registry operations including POST /search, POST /explore and GET /agents.
• The zero-dependency conformance/bin/conformance-test CLI can validate manifests, resolve a publisher and probe registry behavior.
• Publisher-resolution mode tries the normative /.well-known/ard.json path first and may use the predecessor path as a compatibility fallback, explicitly warning that consumers are not required to consult it.

That is a stronger implementation/conformance surface than the guide previously recorded. It still does not make ARD a final Internet standard or create any UHP conformance relationship; the specification’s own status remains Proposal.

Where MCP Server Cards fit

MCP Server Cards are a protocol-specific discovery artifact that can sit inside this broader discovery stack. The experimental MCP Server Card work defines a static JSON document for a remote MCP server’s identity, transport endpoints and supported protocol versions. An AI Catalog or ARD-compatible entry can link to or embed that Server Card, giving the discovery layer a protocol-agnostic way to advertise the artifact while leaving MCP-specific connection details in the card.

This is a useful concrete example of the layering:

ARD / AI Catalog
    │ discover heterogeneous artifact
    ▼
MCP Server Card
    │ MCP-specific identity + connection metadata
    ▼
Remote MCP server
    │ live MCP negotiation / lists / operations
    ▼
Tools, resources and prompts

The current Server Card work intentionally excludes static tool/resource/prompt listings and local package-installation metadata. Dynamic primitives remain runtime MCP data, while install/package metadata belongs to the MCP Registry’s server.json surface. That keeps a Server Card focused on pre-connection remote discovery rather than turning it into a full runtime or registry schema.

Caution

MCP Server Cards are not yet a released MCP extension. SEP-2127 remains open and unmerged, and the official experimental repository explicitly says the work is for prototyping and feedback and is not an accepted or official MCP extension. Its roadmap prioritizes graduation after SDK/reference-implementation and readiness work. This is active standardization direction, not current released 2026-07-28 behavior.

Nothing in that composition creates a UHP relationship. ARD/AI Catalog can advertise many kinds of artifacts, MCP Server Cards describe MCP servers, and UHP remains a separate client↔server↔harness execution contract.

IETF DAWN: a separate discovery standardization path

The IETF Discovery of Agents With Names (DAWN) effort is in formal chartering, but it is not yet a chartered working group. As of 8 September 2026, the IETF Datatracker labels DAWN a Proposed WG and shows charter revision charter-ietf-dawn-00-05 in Start Chartering/Rechartering (Internal Steering Group/IAB Review). That is stronger than the earlier IETF 126 BoF state, but it is still a proposal/chartering state rather than a final charter or published IETF standard.

The proposed charter focuses on finding an AI resource within a local network, within an organization, or between cooperating organizations and learning the minimum information needed for subsequent selection, invocation or communication. It calls for an interoperable generic discovery mechanism built on existing protocols and trust models, explicitly considers mDNS and DNS, and keeps broader capability exchange, post-discovery communication, wider-Internet indexing, identity management and trust evaluation outside the initial scope.

A new individual Internet-Draft, draft-zhang-dawn-agent-discovery-framework-01, dated 7 September 2026 and announced 8 September 2026, adds a concrete architectural proposal for that discovery space. It describes two logical layers:

1. Local Discovery Plane — zero-configuration advertisement and metadata collection inside a site without mandating one link-local protocol.
2. Federation Plane — site gateways exchange lightweight Federation Metadata Records (FMRs) across administrative domains; an FMR is proposed as a concrete binding of DAWN Minimum Discoverable Information (MDI), while full Capability Cards are retrieved on demand over authenticated unicast.

The proposal also introduces a Federation Gateway and Export Policy Engine so an organization can filter or redact discovery metadata before exporting it. It is explicitly an informational individual Internet-Draft and says it does not define normative protocol formats; instead, it shows how candidate mechanisms such as ACAP, Agent Directory and ARDP could be composed at administrative boundaries.

Caution

The -01 draft’s abstract refers to the DAWN “working group”, but current organizational status is controlled by the IETF Datatracker, which still lists DAWN as a Proposed WG in chartering. The draft is therefore useful architecture work, not evidence that DAWN has already been chartered or that this architecture has been adopted as a WG document.

DAWN also remains separate from ARD. ARD has its own published v0.91 Proposal and registry/static-publication contract. The DAWN proposed charter does not name ARD as its selected protocol, and the new framework treats multiple discovery mechanisms as candidates rather than choosing ARD. Likewise, its references to A2A Agent Cards or AGNTCY directory work are composition examples, not adoption of those protocols as the DAWN standard.

For UHP, the boundary remains straightforward: DAWN is discovery-before-connection work; UHP begins when a client talks to a UHP server to execute through a configured complete harness. A future discovery record could point to a UHP endpoint, but no standardized DAWN↔UHP binding, native HarnessRouter DAWN integration or DAWN adoption of UHP is established by the current primary sources.

How UHP and ARD could coexist

The layers are complementary in principle. A discovery system could use ARD to locate a suitable capability and then use that capability through its native execution protocol. For resources that expose UHP, a future ARD entry convention could describe a UHP endpoint and its metadata, after which the client would speak UHP normally.

Caution

No native ARD↔UHP binding is established by the current evidence. Published ARD v0.91 does not define a standardized UHP media type/profile. The architectural coexistence is therefore an interoperability possibility, not an adoption claim.

Why the 24 August AWS statement matters

AWS published an ARD-focused Agent Registry article on 24 August 2026 and states that AWS contributed feedback during development of the specification. AWS frames ARD as a way for registries to federate across clouds, on-premises environments and SaaS systems while local access control remains with each registry.

That is a meaningful ecosystem signal, but it should not be overstated:

• AWS says it expects ARD to enable cross-environment and cross-organizational discovery and says support for open discovery standards is still evolving.
• AWS Agent Registry’s currently documented native schema support is for MCP and A2A, with Skills/custom records and an MCP query endpoint. That is not evidence that the current service already implements ARD federation.
• Google’s 17 June ARD announcement similarly says native ARD support for its Agent Platform will be available in the coming months, so the announcement is an implementation direction rather than proof that native ARD support is already shipped there.

The safe interpretation is therefore multi-vendor alignment around an emerging discovery specification, not completed universal registry interoperability.

What ARD does not replace

The ARD sources keep several concerns outside the discovery layer:

• They do not execute an agent, tool or workflow.
• They do not replace MCP, A2A, UHP or another native invocation protocol.
• They do not make one registry globally authoritative; federation is decentralized.
• They do not replace the discovered resource’s authentication and authorization model.
• They do not define UHP’s task/session/container/file/artifact lifecycle or harness substitution contract.

Related pages

Read UHP vs MCP, UHP vs A2A, the ecosystem map, the glossary, and UHP architecture for the neighboring layers.

Primary sources

• ARD v0.91 specification — current published Proposal
• ARD v0.91 publication PR #81
• ARD v0.91 publication merge commit aa3e598
• Archived ARD v0.9 specification
• ARD specification repository
• AI Catalog specification
• AI Catalog working repository
• MCP Server Cards experimental extension repository
• SEP-2127: MCP Server Cards — HTTP Server Discovery
• IETF Datatracker: proposed DAWN Working Group and current charter
• IETF Datatracker: DAWN charter document
• IETF announcement: draft-zhang-dawn-agent-discovery-framework-01
• DAWN discovery framework draft -01
• Google Developers: Announcing the Agentic Resource Discovery specification (17 Jun 2026)
• Microsoft: Introducing the Agentic Resource Discovery specification (17 Jun 2026)
• AWS: Agentic Resource Discovery (ARD): An open specification for agent discovery (24 Aug 2026)
• AWS Agent Registry documentation
• UHP 2026-09-28 architecture
• Current UHP conformance suite