---
title: "Google, Microsoft and Hugging Face Publish the Agentic Resource Discovery Spec"
description: "ARD is a proposed open spec for publishing and discovering AI capabilities via an ard.json file. Backed by Google, Microsoft and Hugging Face, but adoption is unconfirmed."
tldr: "On 17 June 2026, Google, Microsoft and Hugging Face announced Agentic Resource Discovery (ARD), a draft open specification for publishing, discovering and verifying AI capabilities across the web. Publishers describe their MCP servers, agents, skills and APIs in a manifest at /.well-known/ard.json, and registries crawl those catalogs so agents can find capabilities by natural-language query. The spec is now a v0.91 Proposal under an Apache 2.0 licence, and renamed the file from ai-catalog.json. It is a capability-discovery layer for sites that expose agent-callable tools, not a content-visibility signal, and there is no confirmed adoption beyond the launch coalition yet."
publishDate: 2026-06-22
updatedDate: 2026-09-29
author: "Liam Hayward"
---
On 17 June 2026, Google announced the [Agentic Resource Discovery (ARD) specification](https://developers.googleblog.com/announcing-the-agentic-resource-discovery-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](/ai-search/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](/ai-search/agentic-search/) from [agent-readiness](/ai-search/agent-readiness/) and [WebMCP](/ai-search/webmcp-web-model-context-protocol/). 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](https://developers.googleblog.com/announcing-the-agentic-resource-discovery-specification/)
- [ARD specification — agenticresourcediscovery.org](https://agenticresourcediscovery.org/spec/)
- [Agentic Resource Discovery: let agents search — Hugging Face](https://huggingface.co/blog/agentic-resource-discovery-launch)
- [Google, Microsoft back draft AI agent discovery spec — Search Engine Journal](https://www.searchenginejournal.com/google-microsoft-back-draft-ai-agent-discovery-spec/579894/)
- [Lighthouse v13.5.0 release notes, GitHub](https://github.com/GoogleChrome/lighthouse/releases/tag/v13.5.0)
- [ard-schema not updated for ARD v0.91, Lighthouse issue #17251, GitHub](https://github.com/GoogleChrome/lighthouse/issues/17251)