Agentic Resource Discovery Specification Explained

• Agentic Resource Discovery (ARD) is a proposed open standard letting agents find what a website offers without scraping HTML.
• For operators, it means lower integration cost when your business needs to be reachable by buyer agents, support agents, and partner agents.
• It builds on familiar web plumbing (DNS records, well-known files, signed manifests), so your existing web team can implement it.
• The business question is not whether to adopt ARD today, but whether to be discoverable by agents at all, and on whose terms.
• Risk to watch: discovery standards are early and fragmented. Pick a thin first implementation and expand once a winner emerges.

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.

Why a discovery layer matters for the business

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.

• API integration is reliable but slow to set up and limited to partners who have done the work.
• Scraping is fragile, breaks on redesigns, and produces support tickets you cannot trace.
• Human handoff is the most expensive option per transaction and the slowest.

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.

What ARD actually proposes

The Agentic Resource Discovery specification defines three things in plain terms.

1. A well-known location on your domain where agents can fetch a manifest. The convention is /.well-known/ard.json, similar to how robots.txt and security.txt work today.
2. A schema for that manifest, describing the resources you expose: actions an agent can take, data feeds it can read, and endpoints with their authentication requirements.
3. A signing and trust mechanism so an agent can verify the manifest belongs to the domain that served it and has not been tampered with in transit.

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.

A minimal manifest

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.

How an agent uses it

 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.

How ARD compares to what is already out there

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.

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.

What this means for your roadmap

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.

Quarter one: inventory and a static manifest

Before any engineering, list what an external agent might want to do with your business. For most B2B companies the list is short:

• Read the product catalog or service menu with current pricing.
• Check availability or inventory.
• Place an order or book a slot.
• Open a support ticket.
• Fetch an invoice or statement on behalf of an authenticated buyer.

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-type

That short check is what an agent does first. If it fails, you are invisible.

Quarter two: sign the manifest and add one new action

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.

Quarter three: evals and guardrails

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:

• Cap order value per agent session at a configurable amount.
• Require a confirm step for any new shipping address.
• Log every agent call with the manifest version it discovered, the resource id, and the outcome.
• Run a weekly review of failed calls; treat them like a support queue.

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.

Risks to flag to your executive team

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.

What I would do this month if I ran operations

Three concrete moves, in order.

1. Ask your head of engineering whether you have an OpenAPI document for your existing customer-facing API. If yes, you are most of the way to a manifest. If no, that is the first ticket.
2. Decide, at the operator level, which agent-driven actions you want to enable in the next two quarters. Write the list down. Share it with sales and support so they hear it before customers ask.
3. Stand up a static, unsigned manifest on a staging domain. Have one engineer fetch it with an agent harness and confirm a round trip. Cost: a day or two of engineering time. Value: you now know whether the rest of the roadmap is weeks or months.

The discovery layer is going to exist. The only question is whether your business is on the map when the agents start looking.