
ARD is Google's proposed open standard for helping autonomous agents find what a website offers without scraping HTML or manual API setup.
No. It is a draft specification published by Google, with the stated intent of working toward a broader standards process. Treat it as a credible early proposal, not a ratified standard. Build thinly, watch for converging conventions.
No. ARD is a discovery layer. It points agents at endpoints you already run. If you have a REST API, an MCP server, or an OpenAPI document, the manifest references those. You do not rewrite anything.
`robots.txt` tells crawlers what not to index. A sitemap lists pages. ARD lists actions and feeds an agent can use, with authentication and terms attached. The audience is software that will transact, not software that will read.

14-day trial. No DevOps. No Sales call. Provisioned in under a minute.
Publish a static, unsigned manifest at `/.well-known/ard.json` that lists one public read-only feed, such as your product catalog. That single file makes you discoverable and costs almost nothing to maintain. Add signed actions later.
The policy decisions (which actions to expose, what terms apply, what value caps to set) belong to operations or the COO. The implementation belongs to whoever owns your public API surface today. Security reviews the signing key handling. Legal reviews the linked terms.
Google has published a draft specification called Agentic Resource Discovery, or ARD, which describes how an autonomous software agent can find the tools, data feeds, and actions a website wants to expose. If your business has a website, a product catalog, a booking flow, or a support portal, this is the layer that decides whether an agent acting on behalf of a customer can transact with you cleanly or has to guess by reading your pages. This post is a state-of read on what ARD proposes, what it means for operators, and what to do in the next two quarters.
Today, when an agent acts on behalf of a user (booking travel, reordering supplies, filing a claim), it usually does one of three things: call a published API that the vendor maintains, scrape the public website and click buttons, or hand off to a human. Each path has a cost.
A discovery standard sits before all three. It is a small, machine-readable file that says: here are the things this domain lets an agent do, here is how to call them, here are the terms. If your buyers' agents can read that file, they stop guessing. You stop paying for ambiguity.

The operator stake is concrete. If a procurement agent at a customer can find your reorder endpoint in 200 milliseconds and call it, you keep that revenue. If it cannot, the agent picks a competitor whose discovery file resolved. This is the same shift that happened with sitemaps and search engines, with one difference: the agent is going to transact, not just index.
The Agentic Resource Discovery specification defines three things in plain terms.
/.well-known/ard.json, similar to how robots.txt and security.txt work today.That is the entire surface. It is intentionally small. ARD does not specify the protocol an agent uses to call your actions; it tells the agent where to look and what is on offer. The call itself can be MCP (Model Context Protocol, Anthropic's standard for agent tools), a REST API, or another emerging contract.
Here is what a small manifest looks like for a fictional parts supplier. The point is to show the shape, not to memorize fields.
{
"ard_version": "0.1",
"publisher": {
"name": "Northwind Parts",
"domain": "northwind.example.com",
"contact": "agents@northwind.example.com"
},
"resources": [
{
"id": "reorder",
"type": "action",
"description": "Place a reorder for a known SKU on an existing account.",
"endpoint": "https://api.northwind.example.com/v2/reorder",
"protocol": "mcp",
"auth": "oauth2",
"terms": "https://northwind.example.com/agent-terms"
},
{
"id":
That file tells an agent two things it would otherwise have to learn by trial and error: there is a reorder action behind OAuth, and there is a public catalog feed. For an operator, this is the equivalent of putting a sign on the door with hours and a phone number instead of making people knock.
Agent Your Domain
| |
| GET /.well-known/ard.json |
|------------------------------->|
| |
| 200 OK (manifest + sig) |
|<-------------------------------|
| |
| verify signature |
| pick resource "reorder" |
| |
| OAuth flow + call endpoint |
|------------------------------->|
| |
| 201 Created (order id) |
|<-------------------------------|The agent never reads your HTML, never clicks a button, never breaks when marketing changes the homepage. That stability is the business value.
ARD is not the first attempt at this. It is the most recent, and it leans on existing web conventions rather than inventing new ones. For an operator deciding where to put engineering time, the comparison matters.
| Approach | What it covers | Who maintains it | Operator effort to adopt |
|---|---|---|---|
| Published REST or GraphQL API | Calling endpoints, contracts, docs | You and your partners individually | High; per-partner integration |
| OpenAPI / Swagger doc at a URL | Endpoint schema, no discovery convention | You publish, partners find it manually | Medium; assumes partners know where to look |
| Anthropic MCP server | Tool calls for an agent to use | You run an MCP server per surface | Medium; protocol is solid, discovery is ad hoc |
llms.txt (community) | Hints for language models reading your site | Community draft | Low; informational only, no actions |
| ARD manifest | Discovery of actions, feeds, and auth | Draft spec, Google-led | Low to medium; one file plus signing |
The pattern to notice: MCP is the call layer, ARD is the directory. They are complementary. If you have already stood up an MCP server for partners, ARD is the way to make it findable without each partner asking for the URL.

The honest read is that ARD is a draft. Drafts sometimes win and sometimes get replaced. The cost of a thin implementation, however, is low enough that waiting is not the right default for most B2B operators. Here is how I would sequence it.
Before any engineering, list what an external agent might want to do with your business. For most B2B companies the list is short:
Write that list. For each item, decide whether you want agents to do it at all. This is a policy decision, not a technical one. A COO should own it, not the API team.
Then publish a static manifest covering only the items you already expose through an API. No new endpoints yet. The goal is to be discoverable for what you can already serve.
# Place the manifest at the well-known path and verify it is reachable.
# Replace example.com with your domain.
curl -sS https://example.com/.well-known/ard.json | jq.
# Check that it is served with the correct content type and is not gated by auth.
curl -sI https://example.com/.well-known/ard.json | grep -i content-typeThat short check is what an agent does first. If it fails, you are invisible.
Signing matters because agents that act on behalf of paying customers need to know they are talking to you, not to a man in the middle. The spec uses Ed25519 (a fast, modern signature algorithm); your security team has likely used it before. Publish the public key at a stable URL referenced in the manifest. Rotate keys on the schedule you already use for TLS certificates.
Once the manifest is signed, pick one action that would meaningfully reduce human handling. Reorders, appointment booking, and status checks are common starting points. Add that one resource to the manifest and instrument it. You want to know two things: how many agents discovered it, and what fraction of those calls succeeded.
This is where the eval-driven operations frame becomes load-bearing. An agent calling your reorder endpoint can do things a web form would not let it do: order ten thousand units instead of ten, schedule a delivery to the wrong site, or repeat a failed call in a loop. You need offline evaluations (test runs against recorded agent traffic) and online guardrails (rate limits, value caps, human review thresholds).
A pragmatic starting set:
The point of these guardrails is not to slow agents down. It is to make sure that when an agent makes a mistake, the cost is bounded and the trace is clean.
Three risks deserve to be on the table when you bring this up at your next operating review.
The first is standards fragmentation. ARD is one of several drafts. If Anthropic, OpenAI, or a standards body publishes a competing convention, you may end up serving two manifests. The work to do that is small, but it is real, and the cost of picking the loser is some duplicated maintenance, not a rewrite.
The second is liability. When an agent transacts on your endpoint, the question of who is bound by the order, the human user or the agent vendor, is not fully settled. Your contract terms link from the manifest ("terms": "...") is where you make that explicit. Have legal review the agent terms page before the manifest goes live.
The third is competitive. If your competitors publish a manifest and you do not, agents will route around you. This is the same dynamic as SEO twenty years ago, with shorter feedback loops. You will not get a slow decline; you will get a step function the first time a popular procurement agent decides to prefer ARD-discoverable suppliers.
Three concrete moves, in order.
The discovery layer is going to exist. The only question is whether your business is on the map when the agents start looking.