UHP vs Agentic Resource Discovery (ARD)

The one-sentence difference

ARD is a pre-invocation discovery layer for finding agentic resources across catalogs 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-08-11, a Draft standard with a runnable 52-check conformance suite (2026.8.11.post1).
• ARD is currently v0.9 (Draft), with canonical status Proposal, dated 28 May 2026. Its canonical specification is maintained by the ARD project and identifies Junjie Bu (Google), R.V. Guha (Microsoft) and Shaun Smith (Hugging Face) as authors.
• ARD’s current draft status matters: it is an open specification under active development, not a finalized standard whose current fields or federation behavior should be treated as permanently stable.

Architectural comparison

Dimension	UHP	ARD
Primary boundary	Product/client ↔ UHP server ↔ complete harness runtime	Publisher/catalog ↔ discovery registry ↔ discovery client
Main purpose	Execute agent work consistently across harnesses	Publish, index, search and discover agentic resources before invocation
Published entry point	GET /v1/uhp discovers a UHP server’s protocol/version/capabilities; harness APIs expose that server’s harness catalog	Domain-hosted /.well-known/ai-catalog.json advertises resources; registries ingest catalogs and expose search
Search model	No federated web-scale resource-search contract	Standard registry REST surface includes POST /search, POST /explore and agent-listing APIs
Resource model	Harnesses, responses, sessions, containers, files, artifacts and events	Media-type-driven catalog entries for agentic resources such as MCP servers, A2A agent cards, Skills, APIs, nested catalogs and registries
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	v0.9 Draft / Proposal; open and evolving

ARD’s discovery model

ARD separates two complementary discovery paths:

1. Static publication. A publisher hosts an ai-catalog.json manifest under its own domain, normally at /.well-known/ai-catalog.json. The draft also describes other discovery hints such as HTML link metadata and DNS records.
2. Dynamic registry search. Registries crawl or ingest catalogs, index their entries and expose a standard HTTP REST search interface. Web ingestion is required by the current draft; other pipelines such as Git, package registries or OCI registries may be added by an implementation.

The design is intentionally artifact-agnostic. A catalog entry wraps a resource using its media type rather than forcing MCP, A2A, Skills or APIs into one runtime schema. That distinction is central to how ARD relates to UHP: discovery metadata tells a client what exists and where to find it; the resource’s native protocol defines what happens after connection.

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 catalog 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. ARD v0.9 is media-type driven and shows resource types such as MCP servers, A2A agent cards, Skills and APIs, but this guide has not verified a standardized UHP media type or ARD profile for UHP. 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 current ARD specification explicitly keeps several concerns outside its discovery layer:

• It does not execute an agent, tool or workflow.
• It does not replace MCP, A2A, UHP or another native invocation protocol.
• It does not make one registry globally authoritative; federation is decentralized.
• It does not replace the discovered resource’s authentication and authorization model.
• It does 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

• Canonical ARD v0.9 specification
• ARD specification repository
• 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-08-11 architecture