ARD is the missing lookup layer for AI agents. Here is what it actually does.

On 17 June 2026, eleven companies — Google, Microsoft, GitHub, Hugging Face, NVIDIA, Salesforce, Snowflake, Cisco, Databricks, GoDaddy, and ServiceNow — published a draft spec called Agentic Resource Discovery, or ARD. It is an open standard for how an AI agent finds tools, APIs, and other agents on the open web at runtime, rather than being told about them at build time. This piece walks through what ARD does, the four-step flow it enables, and why the separation of finding from calling is the architectural move worth understanding.

The gap ARD fills

To see why ARD matters, you have to see what it sits on top of.

In late 2024 Anthropic released the Model Context Protocol (MCP), which standardised the interface between an AI agent and a tool. MCP defines the handshake: how the agent introduces itself, how it calls a function, what the response looks like. If you have used an AI assistant that can read your calendar or query a database, MCP (or something MCP-shaped) is probably the wire format underneath.

But MCP only answers one question: given that I know this tool exists, how do I talk to it? It does not answer the prior question: how did I know this tool existed in the first place?

Today, the answer is mostly "a human developer wired it in." Someone sat down, picked the tools the agent should have access to, and registered them at build time. The agent's effective universe of capabilities is whatever was hard-coded when it shipped. If a new tool appears in the world next month, the agent cannot use it unless someone redeploys.

ARD is the spec for fixing that. It is a discovery protocol, not an execution protocol. It is the lookup layer.

The four-step flow

The mechanism has four steps, and the best way to understand ARD is to walk through each.

Step 1 — Publish. An organisation that wants its tools and APIs to be discoverable by agents publishes a machine-readable catalog at a known path on its own domain. The file is called ai-catalog.json, and the format is defined by the AI Catalog data model, which is maintained as an open standard under the Linux Foundation. The catalog lists capabilities — what the tools do, who provides them, where they live, how to authenticate, what MCP endpoint to connect to. If you have ever seen a robots.txt file at the root of a website telling search crawlers what to index, this is the same idea. The domain itself is the unit of trust: acmecorp.com publishes the canonical catalog for Acme's tools, because Acme controls acmecorp.com.

Step 2 — Index. Registries crawl those domain-hosted catalogs and build searchable indexes. There is no single official registry — the spec is federated, meaning multiple registries can coexist and interoperate. GitHub has shipped one called Agent Finder. Hugging Face has shipped one called Discover Tool. An enterprise can run its own internal registry that only indexes catalogs from approved domains. Think of registries as the search engines of the agent web: they do not own the catalogs, they just index them.

Step 3 — Query. When an agent is working on a task and needs a capability it does not already have wired in, it asks a registry. The query is structured — "find me something that can convert currencies" or "find an MCP server for project management" — and the registry returns matching capabilities with enough metadata for the agent to decide whether to use them. This is the runtime part. The agent does not need to have known about these tools yesterday.

Step 4 — Connect. Once the agent picks a capability, it connects to it using the underlying execution protocol — usually MCP. ARD's job ends at "here is the tool, here is where it lives, here is how to talk to it." MCP takes over from there.

Publish, index, query, connect. That is the whole flow.

Why the separation matters

The reason this two-layer split is worth a piece of its own is that it mirrors the most successful architectural decision in the history of the open web: the separation of DNS from HTTP.

DNS is the discovery layer. When you type wikipedia.org, DNS tells your browser which server to talk to. HTTP is the execution layer — it is how your browser actually fetches the page. The two protocols evolved independently, which is why the web survived the move from HTTP/1.1 to HTTP/2 to HTTP/3 without rewriting DNS, and why DNSSEC could be added later without breaking every browser.

ARD plus MCP is the same shape. ARD is the lookup. MCP is the call. Each layer can evolve on its own clock. A tool provider publishes its catalog once and gets discovered by every agent that speaks ARD, regardless of which registry that agent prefers. An agent vendor picks which registries to trust without having to also pick which execution protocol to support.

The metaphor breaks in one place worth flagging: DNS is hierarchical and ultimately rooted in a small number of authoritative servers. ARD is deliberately not. It is domain-anchored, each organisation is its own root of trust for its own catalog, and federated across registries. That is closer to how the web's .well-known paths work (RFC 5785, if you want to read the precedent) than to DNS proper. The architectural point still holds: discovery and execution are separated, and the separation is the unlock.

What runtime discovery actually changes

Here is the practical consequence. An agent built and deployed today, if it speaks ARD, can use tools that did not exist when it shipped. It queries a registry, finds something new, reads the capability description, connects via MCP, uses it. No redeployment. No human in the loop wiring the integration.

That is the mechanism behind a lot of the "agentic commerce" and "agents-as-buyers" talk you have probably seen. The reason those theses sounded speculative until now is that someone always had to manually connect each agent to each merchant or service. ARD removes that step. Whether the broader thesis pays off is a different question — but the technical precondition is no longer missing.

Two things worth watching

Anthropic is not on the list. MCP is Anthropic's protocol, and ARD is designed to sit on top of it, yet Anthropic is not among the eleven announcing companies. That could mean parallel tracks that converge later, or it could mean a quiet divergence on how the agent stack should be governed. If Anthropic releases its own discovery mechanism, the clean two-layer story gets messier.

Trust at the registry layer. Domain-anchoring solves who publishes a catalog. It does not solve whose catalog you should believe. If a registry indexes a malicious catalog, an agent querying that registry can be steered to a hostile tool. The spec leaves verification mostly to registries and clients, which means trust models will be where the real differentiation, and the real risks, show up. Watch what GitHub, Hugging Face, and the enterprise registries do here. That is where the next layer of this stack gets built.

Footnotes and links

Further reading

• Agile Brand Guide summary of the 27 June 2026 announcement wave: https://agilebrandguide.com/yesterdays-marketing-technology-ai-news-june-27-2026
• Anthropic's original MCP introduction (late 2024) for the execution-layer companion to ARD.

¶