Google, Microsoft and Hugging Face Publish the Agentic Resource Discovery Spec

On 17 June 2026, Google announced the Agentic Resource Discovery (ARD) specification, a draft open standard for publishing, discovering, and verifying AI capabilities across the web. Despite the Google Developers Blog announcement, ARD is not a Google-only project: the spec is co-authored by Junjie Bu (Google), R.V. Guha (Microsoft), and Shaun Smith (Hugging Face), with contributing organisations including Amazon Web Services, Cisco, Databricks, GitHub, GoDaddy, Nvidia, Salesforce, ServiceNow, and Snowflake.

ARD is infrastructure for the agentic web rather than a search ranking signal. It addresses how an AI agent finds out which tools, agents, and APIs a site exposes, and how it confirms who published them, before connecting.

What problem does ARD solve?

As more sites expose machine-callable capabilities (MCP servers, agent-to-agent endpoints, agent skills, OpenAPI tools), agents have no standard way to answer three questions: where those capabilities exist, which to use for a task, and whether they are safe to connect to. Capability declarations are currently fragmented across protocols and scattered across domains.

ARD proposes a common layer for that discovery problem, positioned as a shared standard across the industry rather than one company’s format. At launch it built on the AI Catalog data model from the Linux Foundation’s AI Catalog Working Group; since version 0.91 it defines its own entry schema, which it says “does not derive from any catalog schema”.

How does ARD work?

The spec defines two primitives.

A static catalog file. Publishers host a manifest at /.well-known/ard.json. It describes the site’s agentic resources, each entry carrying a domain-anchored identifier, a display name, a media type, and a pointer to (or embedded copy of) the capability definition, alongside optional descriptions, tags, capabilities, and representative queries. Entries can reference MCP servers, A2A agents, skills, APIs, or nested catalogs.

A registry API. Registries crawl and index published catalogs and expose REST endpoints (POST /search, POST /explore, GET /agents) that return ranked matches to natural-language discovery queries. The model is deliberately search-engine-like: registries are to capability catalogs what search engines are to web pages. Agents either query a registry to find capabilities or fetch a known partner’s catalog directly.

Beyond the well-known path, a catalog can be advertised through an Agentmap directive in robots.txt, an HTML <link rel="ard"> tag, or a DNS service binding record, mirroring how sitemaps are declared today.

Update, 29 September 2026: ARD version 0.91, dated 26 August 2026, renamed the file and the link relation. At launch the manifest lived at /.well-known/ai-catalog.json and was advertised with rel="ai-catalog". The spec now says consumers must fetch ard.json, may still check the old path as a courtesy, and that a publisher on the old path “SHOULD move to ard.json”. Its status also changed from draft to Proposal. One mismatch to know about: the ARD audit added in Lighthouse 13.5.0 (18 September 2026), and live in PageSpeed Insights by 29 September, still looks only for the old path and link relation, and an open Lighthouse issue tracks the fix. A site that follows the current spec will therefore see that audit as not applicable until it ships.

How is trust established?

Because each catalog sits on its own publisher’s domain, ARD uses domain ownership as the basis for identity: the domain embedded in a resource’s identifier must align with where the catalog is served. The spec also defines an optional trustManifest carrying cryptographic workload identifiers (such as SPIFFE IDs or DIDs) and attestation objects, so an agent can verify a publisher’s identity before connecting. Runtime connections then use each capability’s native protocol.

How does this relate to llms.txt and sitemaps?

ARD sits at a different layer from the content-discovery conventions publishers already know. llms.txt and XML sitemaps help agents and crawlers find and read content. The ARD manifest declares what an agent can do on a site: the callable tools and services it exposes. The same read-versus-act distinction separates agentic search from agent-readiness and WebMCP. ARD is the discovery layer that sits in front of those action protocols.

What this means

For content and editorial sites, ARD changes nothing in the near term. It is relevant only to sites that already expose, or plan to expose, agent-callable capabilities: e-commerce, SaaS, booking, and tool platforms. Those sites should treat it as a watch item, and the discovery declarations (a well-known file, a robots.txt line, a <link> tag) are low-cost to add once an MCP server or agent endpoint actually exists.

Two caveats temper the announcement. First, the spec is early: it is published at v0.91 with “Proposal” status under an Apache 2.0 licence, and the format may change before it stabilises, as the filename already has. Second, the breadth of the backing coalition signals intent, not adoption. No major registry behaviour or agent runtime has been confirmed to read an ARD manifest at scale yet. The standard is worth tracking because of who is behind it, but publishing a catalog earns nothing until registries and agents consume it.

Sources

• Announcing the Agentic Resource Discovery specification — Google Developers Blog
• ARD specification — agenticresourcediscovery.org
• Agentic Resource Discovery: let agents search — Hugging Face
• Google, Microsoft back draft AI agent discovery spec — Search Engine Journal
• Lighthouse v13.5.0 release notes, GitHub
• ard-schema not updated for ARD v0.91, Lighthouse issue #17251, GitHub