ARD, explained: how agents will find your brand, and why you shouldn't have to think about it

Short version: ARD (Agentic Resource Discovery) is an open spec that lets a brand publish one JSON file on its own domain describing what agents can do with it. Search services called registries crawl those files, and agents query the registries in plain language to find the right tool. Google, Microsoft, GitHub, Hugging Face and others back it. Adoption is still tiny, ChatGPT and Claude don't support it natively, and it may or may not win. For 42A clients, none of that matters: if your brand runs on our Agentic Engagement Layer, you get ARD the same way you get every other agent standard. Automatically.

Here is how it works, what it is good for, and where it actually stands.

The problem ARD tries to solve

Today, an AI client knows about a tool in one of two ways. Someone installs it (an app in ChatGPT, a connector in Claude), or a developer hardcodes it. Then, to pick the right tool, most clients put every tool description into the model's context window.

That works for ten tools. It does not work for ten million. The ARD spec says this directly: the install model resembles a mobile app store, and stuffing descriptions into the context does not scale.

ARD moves the "which tool should I use?" question out of the model and into a search service. Like a search engine for pages, but for things an agent can call.

How ARD works

1. The entry: one description per capability

The unit of ARD is the entry: a small JSON-LD object that describes one agentic resource. That resource can be an MCP server, an A2A agent, a skill, a plugin, or even another registry.

An entry must carry four things:

• identifier: a domain-anchored URN, in the form urn:air:<publisher-domain>:[<namespace>:]<name>. The domain is the point. It ties the capability to a domain you control.
• displayName: a human-readable name.
• type: a media type that says what the artifact is, for example application/mcp-server-card+json or application/a2a-agent-card+json.
• url or data: a link to the artifact (for example, an MCP server card), or the artifact inline. Exactly one of the two.

Two more fields make the entry findable:

• representativeQueries: 2 to 5 natural-language requests the resource can serve. The registry builds its semantic index from these. Without them, the spec says, the entry cannot be found by search.
• capabilities: short tokens such as ["SearchRooms", "BookRoom"], used for fast structured filtering.

Here is what an entry could look like for a hotel brand's booking server (fictional domain):

{
  "identifier": "urn:air:hotels.example:booking:mcp",
  "displayName": "Hotels Example Booking",
  "type": "application/mcp-server-card+json",
  "url": "https://hotels.example/mcp/server-card.json",
  "capabilities": ["SearchRooms", "BookRoom", "RedeemPoints"],
  "description": "Live room availability, member rates and direct booking for Hotels Example properties.",
  "representativeQueries": [
    "find a family hotel near the beach in Nice for 3 nights",
    "book a room in Paris and pay with my loyalty points",
    "what is the member rate at your London hotel this weekend"
  ]
}

2. The manifest: one file on your domain

Entries go into a manifest: a JSON document with an entries array, hosted at:

https://<your-domain>/.well-known/ard.json

It must be served over HTTPS, as application/json, with Access-Control-Allow-Origin: * so crawlers can fetch it.

There are other ways to point at the manifest: a <link rel="ard"> tag in the page head, an Agentmap: line in robots.txt, entries embedded as JSON-LD in a page, or DNS records.

One detail matters in practice. The spec renamed the file in version 0.91. The old path was /.well-known/ai-catalog.json. Conformant clients must read ard.json and may read the old path. But one independent tracker found that every publisher it saw still serves ai-catalog.json, and only a few also serve ard.json. So today, the safe move is to serve both.

3. Registries: search engines for agents

Registries crawl manifests, index the entries, and expose a standard REST endpoint, POST /search. An agent sends a request like this:

{
  "query": {
    "text": "book a hotel in Paris with loyalty points",
    "filter": { "type": ["application/mcp-server-card+json"] }
  },
  "federation": "referrals",
  "pageSize": 5
}

The registry returns ranked entries, each with a relevance score from 0 to 100. Registries can also work together. In auto mode, a registry queries other registries and merges the results. In referrals mode, it returns pointers to other registries and the client decides which to follow. In none mode, it searches only its own index. Any company can run its own registry, the same way a company runs search on its intranet.

4. Trust: your domain is your identity

ARD's defense against impersonation is simple. The publisher domain in the identifier must match the identity in the entry's optional trustManifest. An entry that claims urn:air:yourbrand.com:... should be rejected by a verifying registry unless it can show an attestation issued by yourbrand.com.

ARD does not define its own signing scheme. It defers to whatever trust framework the manifest declares (SPIFFE, a DID method, an enterprise PKI). Registries can then filter on trust data, for example only returning entries with a SOC 2 attestation. That is the hook regulated industries like banking and insurance will care about.

The spec also says the search score measures relevance only. It is not a trust or safety rating.

5. Then ARD gets out of the way

Once the agent picks a result, it connects directly to the resource with its native protocol: MCP for an MCP server, A2A for an agent. ARD only handles finding. Authentication and execution belong to those protocols.

Why it matters for brands

• Discovery without an install. Today a customer has to add your app to their assistant. With ARD, an agent can find your capability at the moment a need comes up.
• A new optimization surface. Registries match intent against representativeQueries, descriptions and capabilities. How you describe what your brand can do will decide whether an agent picks you or a competitor. This is Agentic Decision Optimization in its most literal form.
• Your brand, verified. The domain-anchored identifier and trust binding make it harder for someone else's agent to pose as your brand.
• Room for enterprise rules. Filters on trust attestations let banks, insurers and large enterprises run registries that only return approved, compliant tools.

The reality, as of October 2026

We like ARD. We also don't want to oversell it.

• It is a draft. The current version is v0.91, status "Proposal", dated August 26, 2026.
• The backers are serious. Contributors include Google, Microsoft, GitHub, Hugging Face, Salesforce, ServiceNow, Snowflake, Databricks, Cisco, Nvidia and GoDaddy.
• The biggest assistants are missing. OpenAI and Anthropic are not in the working group, and neither has announced native ARD support in ChatGPT or Claude. You can wire a registry into ChatGPT by hand through developer mode, but that is a workaround, not discovery.
• Registries exist, at small scale. GitHub's Agent Finder and Hugging Face Discover already answer ARD search requests. Google says its Agent Platform will connect to ARD registries in the coming months.
• Very few sites publish a manifest. One sample of 39 top sites in June found none. A later count found 31 publishers in total.

The closest comparison is llms.txt. It had a lot of talk and very little adoption for a long time, then documentation platforms started to generate it by default, and it was suddenly everywhere. ARD could follow that path, or another standard could win.

Why our clients don't have to care

This is the part we think matters most.

Every few weeks there is a new agent protocol or discovery standard: MCP, A2A, WebMCP, UCP, ACP, llms.txt, and now ARD. No marketing or IT team should have to track them all, decide which will win, and open a new project each time.

When a brand runs on the 42A Agentic Engagement Layer, we already hold a structured description of everything an agent can do with that brand: the tools, the agents, the rules. That makes ARD a byproduct, not a project:

• We generate the entries from the capabilities already live in the client's layer.
• We write the representativeQueries from what customers actually ask their agents, not from guesses.
• We serve the manifest at both paths, ard.json and ai-catalog.json, with the right headers. If a client can't host files on the .well-known path, we use the DNS option.
• We keep it in sync. When a client adds a capability or changes a rule, the manifest updates with it.
• We add the trust manifest when the registries our clients care about start to require one.

The client's work: none.

Back to the hotel. A guest tells their agent: "3 nights in Paris for the family, use my points." If the agent searches an ARD registry, it finds the hotel's own booking capability, connects through the 42A layer, and gets the member rate, the points balance and the brand's offers. The hotel gets a direct booking, before the agent ever reaches an OTA.

If ARD wins, our clients are already there. If it doesn't, they lost nothing. That is the deal we want to offer for every standard that comes next.

Sources

• Announcing the Agentic Resource Discovery specification, Google Developers Blog
• ARD Specification v0.91
• How to publish an ARD manifest
• Connect ChatGPT to an ARD registry
• Agentic Resources: measured adoption
• Helping agents discover my site search with ARD, Dries Buytaert
• Google, Microsoft back ARD spec, AI Weekly