What is Agentic Resource Discovery?
The shift to agentic commerce
The way people shop is moving into AI. Discovery, comparison, checkout, and even post-purchase monitoring increasingly happen inside AI assistants rather than on a search results page or a brand's own site. This isn't a fringe behavior: 73% of consumers are already using AI in their shopping journey. And the money is following — Accenture estimates that by 2030, more than 30% of online commerce will run through AI agents, close to $3.1 trillion in transactions.
From scraping to brand-controlled protocols
Until now, AI assistants learned about products by scraping the open web – guessing at prices, availability, and specs from whatever pages they could read.
That era is ending.
Brands and the platforms behind these assistants are converging on agentic-commerce protocols: structured, brand-published feeds and endpoints that tell an AI exactly what you sell, what it costs, whether it's in stock, and how to complete a purchase. The difference is control – the brand, not a scraper, becomes the source of truth.
The catch is pace. Several of these protocols have emerged in just the last year, each backed by different platforms, and they ship new releases frequently. Staying compliant is an ongoing commitment, not a one-time integration. And each protocol takes a different approach.
What is ARD?
ARD – Agentic Resource Discovery – is an open proposal for how a domain tells AI agents which agentic resources it offers. Those resources can be MCP servers, A2A agent cards, skills, APIs, and other callable services. A site publishes one manifest at a well-known address, and an agent that lands on the domain reads it to find what is there, instead of needing a custom integration for each resource.
It solves a discovery problem. Each resource is described once, on the publisher's own domain, and any consumer that knows to look at the well-known address can find it.
How it works
The manifest is a JSON document at /.well-known/ard.json with an entries array. Each entry has a urn:air identifier, a media type saying what the resource is, a display name, and a url or inline data for the resource's own descriptor. ARD is an envelope: it does not define what an MCP server card or an A2A agent card contains, it points to them and leaves those details to their own specifications.
Entries can also carry representative queries – a few example requests the resource is good for – and a trust manifest that names the publisher's identity. A manifest can include an entry that points to a registry, whose search API lets agents look for resources across many domains, and an entry that points to a nested catalog of more entries. A site can also advertise the manifest with a link rel="ard" on its pages.
Who's behind it
The specification lives in the ards-project organization on GitHub under the Apache 2.0 license. The project site says it is being developed by a working group with participants from Microsoft, Google, Hugging Face, GoDaddy, and others, and lists Cisco, Databricks, GitHub, GoDaddy, Google, Hugging Face, Microsoft, Nvidia, Salesforce, ServiceNow, and Snowflake as contributors to the specification.
Where it fits
ARD is a current proposal, not a finished standard: the current version is v0.91 and its status is "Proposal", so details can still change. ai-catalog is ARD's predecessor and used /.well-known/ai-catalog.json. ARD defines the single path /.well-known/ard.json, and the spec says a publisher on the predecessor path should move to it, though consumers may still consult the old path. ARD is about discovery only. It does not replace MCP, A2A, or the commerce protocols such as UCP and ACP. It is how an agent finds your MCP server or agent card, and those protocols take over from there.
You can run a completely free check to see whether your manifest and the links it publishes measure up against the current ARD spec right now. And if you would rather not hand-build and maintain that surface as the specification evolves, CorgiMaps connects to your existing data and exposes protocol-compliant endpoints for you, with no changes to your fulfillment stack.