What Google announced
Google published Agentic Resource Discovery (ARD), an open specification for publishing, discovering and verifying AI capabilities across the web. In the architecture Google describes, an organization hosts a file listing the capabilities it exposes (the post names MCP servers, A2A agents, OpenAPI tools and nested catalogs) under its own domain, and registries crawl those files so agents elsewhere can find them. The Google Developers Blog post, dated June 17, 2026 and bylined Junjie Bu and Srinivas Krishnan, states the specification "is available now," is licensed under Apache 2.0, and is built on the AI Catalog data model from the AI Catalog Working Group under the Linux Foundation.
The first thing a merchant should know is that this is not a product-data standard. Nothing in the material Google published with this announcement — not the blog post, not the ard-spec repository, not the Agent Registry overview — mentions ecommerce, retail, storefronts, product detail pages, shopping, checkout or payments. ARD is a discovery layer for callable services. Whether an AI engine can find and recommend your products is a separate problem solved by a separate stack.
Google frames the specification as answering three questions for an agent: "Where does the right capability live? Which capability should I actually use? And how do I verify it's safe to connect to?" The post states that "today, there is no standard way to answer those questions across organizations," and that existing platform registries "remain fragmented and siloed within specific ecosystems."
Two very different things called a catalog
The naming here is a trap for anyone who works in commerce. Google's post says the provider "hosts an ai-catalog.json file at a well-known path on its domain," describing "the provider's available capabilities." Read quickly, "publish your catalog so agents can discover it" sounds exactly like the product-visibility work most brands are already doing. It is not the same thing.
| ARD catalog | Product catalog | |
|---|---|---|
| What it lists | MCP servers, A2A agents, OpenAPI tools, nested catalogs | SKUs, variants, prices, availability, reviews |
| File | ai-catalog.json at a well-known path (path not stated in the post) | Product JSON-LD on the PDP, feeds, platform APIs |
| Who consumes it | Client agents and ARD registries looking for a capability to call | AI answer engines and shopping surfaces selecting products to cite |
| Question answered | "What can this organization's software do for me?" | "Which product should I recommend or add to the cart?" |
Our read: keeping these two senses of "catalog" apart is the single most useful thing an operator can take from this announcement. Conflating them produces exactly the wrong prioritization, because one of them is a live revenue channel and the other is developer infrastructure most brands do not currently publish at all.
How catalogs and registries fit together
Google states the architecture "relies on two primitives: catalogs and registries." The catalog is the domain-anchored file. The post's justification for that placement is the interesting part: "because these catalogs are hosted directly under the organization's own domain, ownership of that domain serves as the cryptographic foundation for identity and trust."
Registries, per the post, "act as search engines for the agentic web" — they crawl published catalogs, index the contents, and return "matching capabilities along with the metadata required to verify the publisher and establish trust before connecting." A client agent can query a registry with a plain-language intent, or, in Google's words, "completely bypass search and directly fetch a catalog from a known partner's domain." For production use, publishers can attach verifiable trust metadata so the agent or registry can "actively confirm the publisher's true cryptographic identity before connecting to the endpoint." After that handoff, Google says ARD "steps out of the way" and the agent connects using the capability's native protocol.
If that shape feels familiar, it should. Publish a file at a known path on a domain you control, let machines read it, and let domain ownership carry the authority. That is structurally the same pattern as robots.txt directives for AI crawlers and the llms.txt files Shopify now emits for every store. The parallel is ours, not Google's, and the purposes differ materially: llms.txt orients crawlers to content, while ARD advertises callable endpoints with cryptographic publisher verification attached.
What this means for ecommerce brands
Directly, today: nothing. There is no merchant-facing ARD task in any of the source material, and no source connects ARD to a commerce protocol.
Indirectly, and as our inference rather than Google's claim, there is one real connection worth holding. Storefronts are starting to expose agent-callable surfaces of their own — inventory and order MCP servers, and browser-side agent tooling of the kind in Shopify Hydrogen's WebMCP work. Any organization that publishes such an endpoint eventually faces the discovery problem ARD is aimed at: how does an agent outside your platform learn the endpoint exists and decide it is safe to call? ARD is a candidate answer. That is a statement about how the pieces could fit, not about anyone's roadmap.
The practical implication is to keep two workstreams separate. Product-side visibility — Product JSON-LD completeness, crawler admittance, machine-readable price and availability, the work covered in checking whether agents can read your PDPs — is unaffected by this announcement. Agentic checkout work under ACP and the related protocols is likewise unaffected; no source ties ARD to any of them. If a vendor tells you ARD is how AI will find your products, ask them which line of the specification says so.
"Available now" and "v0.9 (Draft)" are both true
The blog post says the specification is available now. The repository README states the status as "v0.9 (Draft). The specification is open and evolving; feedback and proposals are welcome via issues and, for non-normative changes, pull requests." Both statements are accurate and they describe different things: the text is published, the schemas are not frozen.
The README describes the repository layout as spec/ard.md, spec/schemas/ holding "CDDL, JSON Schema, and OpenAPI definitions," architecture decision records, and conformance tooling, and states that the rendered spec at agenticresourcediscovery.org/spec is generated from the repo, "so this is the single source of truth." Normative changes require an issue first and are landed by a maintainer. The repository page shows 91 commits, 405 stars and 46 forks under an Apache-2.0 license.
Our read: hosting a static catalog file against a draft spec is cheap and reversible. Building infrastructure that assumes the schemas will not move is not, and the repository says plainly that they may.
What to do this week
- Do not reprioritize product-visibility work. No source asks merchants to publish product data through ARD, and treating this as a PDP task is a category error.
- Inventory your agent-callable surfaces. If your organization exposes an MCP server, an A2A agent, or a public OpenAPI endpoint, you are in scope for the problem ARD addresses. If you expose none, you are not.
- Read the spec, not the blog post. The post never states the well-known path for
ai-catalog.json.spec/ard.mdin the ards-project/ard-spec repository is the authoritative source for the path and the required format. - Treat any implementation as provisional. A hosted catalog file is a reasonable low-cost experiment against a v0.9 draft; dependent tooling is not.
- If you run Gemini Enterprise Agent Platform, note that Google says native ARD support arrives "in the coming months" with no date attached. Plan accordingly.
- Keep it off the agentic-commerce track. File this separately from agentic commerce optimization work until a source connects them.
The strategic read
Google shipped an open specification and, in the same post, the commercial product that implements it. Agent Registry in Gemini Enterprise Agent Platform is described as "the enterprise-grade product that delivers on this vision and forms part of this global federated network," providing "fully hosted support for searching, discovering, and hosting agentic resources." Google says it assigns "globally unique namespaced URNs," enforces egress policies, pins tools and specifications, and uses Agent Identity to verify what the post calls the trust manifest.
A specification with one operating registry is a product onboarding path. A specification with several is a web standard.
Nothing in the sources suggests foreclosure: the spec is Apache 2.0, it sits on a Linux Foundation data model, and federation across registries is the explicit design. But the post names only Google's own implementation. Whether anyone else stands up a registry, and whether any of them crawls the open web at meaningful coverage, is what will decide which of those two outcomes this becomes. Watch for the second registry, not the first.
The second thing worth watching is whether commerce shows up in the schemas at all. Google's engine work already spans product surfaces — see our tracking coverage for Gemini and AI Overviews — but the discovery layer described here is aimed at tools, and no provided source bridges the two.
Open questions
- What is the well-known path? The post says
ai-catalog.jsonsits "at a well-known path" and never states it. - Who are the launch partners? The post credits "partners across the industry" twice and names none in the text. Whether any are commerce platforms is unknown.
- Does the spec address commerce at all?
spec/ard.mdwas not among the material reviewed here, so this is unanswered rather than answered no. - What is the cryptography? The post names the trust manifest and says Agent Identity verifies it, but describes no signing scheme or key distribution method.
- Which other registries exist? Only Google Cloud's is named.
- When is 1.0? The repository states v0.9 (Draft) with no roadmap, and "in the coming months" for Agent Platform support carries no date or quarter.
- Any relationship to Google's commerce protocol work? No source mentions one, and none can be assumed.
Frequently asked questions
Does Agentic Resource Discovery help AI engines find my products?
No source says so. ARD catalogs list callable capabilities such as MCP servers, A2A agents and OpenAPI tools, not products. Google's announcement, the ard-spec README and the Agent Registry documentation do not mention ecommerce, product detail pages, shopping or checkout.
What is an ai-catalog.json file?
Google's post describes it as a file a provider hosts at a well-known path on its own domain, describing the provider's available capabilities, which "can include things like MCP servers, A2A agents, OpenAPI tools, or even other nested catalogs." The post does not state the well-known path; the specification in the ards-project/ard-spec repository does.
Is the ARD specification finished?
The Google Developers Blog post states "The ARD specification is available now." The ard-spec GitHub README states the status is "v0.9 (Draft). The specification is open and evolving." The text is published, but the schemas may still change.
How is ARD different from llms.txt or robots.txt?
All three publish a machine-readable file on a domain you control. Our read is that the purposes differ: robots.txt governs crawler admittance and llms.txt orients crawlers to content, while ARD advertises callable endpoints with verifiable publisher identity attached so an agent can decide whether to connect.
Should a Shopify merchant do anything about ARD this quarter?
Only if the organization already exposes agent-callable services such as an MCP server or a public API. There is no merchant-facing ARD task in any source, and product-visibility work is unaffected by this announcement.
Ask AI about this
Ask an AI engine to separate agent-tool discovery from product discovery in your own words: