Google Just Standardized Agentic Discovery. Here's What It Means (and What It Misses)

Summary

• Google, Microsoft, and others announced the Agentic Resource Discovery (ARD) specification, a new standard for how AI agents find and use tools.
• ARD addresses the "registry" layer of tool discovery, which can reduce agent context size by up to 90% by enabling dynamic, runtime tool selection.
• However, ARD only covers the final step in agent discovery and ignores more influential preceding stages like training data, web search, and local environment files.
• To be selected by agents, companies need a full-stack strategy beyond ARD; Synscribe's Agentic Discovery Playbook covers all 11 plays to ensure tools are not just listed, but consistently chosen.

On June 17, 2026, Google announced the Agentic Resource Discovery (ARD) specification — co-authored with Microsoft and Hugging Face, and backed by Amazon, Cisco, GitHub, Salesforce, Snowflake, and Nvidia. This is the moment agentic discovery stops being fringe theory and becomes foundational infrastructure.

Give it its due: this is a big deal. The discovery problem for AI agents is significant; even inside a single ecosystem, it's hard to answer basic questions about what an agent actually does well, what tools it has access to, and what fails often. ARD is a serious attempt at solving that at the infrastructure level.

We published our own Agentic Discovery Playbook before Google formalized this category. ARD validates the category — and standardizes two of our eleven plays. Here's what it covers, why it matters, and the nine plays it doesn't touch.

What ARD Actually Is

ARD is an open specification for publishing, discovering, and verifying AI capabilities across federated networks. It was co-authored by Junjie Bu (Google), R.V. Guha (Microsoft), and Shaun Smith (Hugging Face), and built on the ai-catalog standard from the AI Catalog Working Group.

Two Core Primitives

Catalogs — Publishers host an ai-catalog.json file at /.well-known/ai-catalog.json. This file describes your agentic resources: MCP servers, A2A agents, skills, APIs. Think of it as a machine-readable menu of everything your platform offers to AI agents.

Registries — Search engines that crawl catalogs, index them, and expose a search/REST API for agents to query at runtime. Google's implementation is the Agent Registry within the Gemini Enterprise Agent Platform.

Four Discovery Mechanisms

ARD specifies four ways for agents or crawlers to locate your catalog:

1. Well-Known URI — /.well-known/ai-catalog.json
2. Agentmap — An entry in robots.txt
3. HTML Link Tag — <link rel="ai-catalog" href="/path/to/ai-catalog.json">
4. DNS — Service Binding (SVCB) records

Trust and Federation

ARD embeds a trust manifest directly into catalog entries: SOC2, HIPAA, and GDPR compliance attestations, plus cryptographic identity via SPIFFE or DID. This directly addresses a key safety concern, as one developer noted, a reputation layer is critical. However, ARD's trust layer is attestation-based, not run-based.

Registries can also federate with each other in three modes: auto, referrals, or none — creating a decentralized but interconnected global network.

What an ai-catalog.json Entry Looks Like

{
  "catalogVersion": "0.1",
  "entries": [
    {
      "identifier": "urn:ai:acme.com:mcpserver:docs",
      "type": "application/mcp-server-card+json",
      "displayName": "ACME Corp Documentation Server",
      "description": "Provides tools to search and retrieve information from ACME's product documentation.",
      "location": "https://mcp.acme.com/docs",
      "representativeQueries": [
        "how to configure the flux capacitor",
        "what are the rate limits for the API",
        "example of using the Python SDK for authentication"
      ],
      "trust": {
        "attestations": ["SOC2", "GDPR"],
        "identity": { "spiffe": "spiffe://acme.com/mcpserver/docs" }
      }
    }
  ]
}

Pay attention to representativeQueries. That field is the key to how your tool gets ranked inside a registry's semantic search. More on this in a moment.

Why This Matters

The old model for tool discovery was explicit installation — an agent developer decides to add a tool, installs it, and it's in the context forever. That approach breaks at scale. Research from Lunar.dev shows that static tool injection can result in agent contexts bloated with 50+ tools consuming 77K tokens before the task even begins — a pattern developers recognize as context pollution.

Dynamic selection cuts that down to ~8.7K tokens — a nearly 90% reduction — because agents only load the tools that are actually relevant to the query at hand.

ARD enables that dynamic, runtime discovery at the network level. Agents don't need tools pre-installed; they query a registry in the moment they need something, find a verified tool, and connect to it. When Google's Agent Registry forms the nucleus of a globally federated network, this becomes infrastructure — not optional.

The representativeQueries field deserves specific attention. It's essentially keyword research for the agentic web. The queries you put in that field determine how a registry ranks your tool when an agent runs a semantic search like "search and retrieve product documentation."

Craft them poorly, and your catalog entry gets buried. Craft them well, and you get selected at runtime over competitors — without any human ever making that choice.

What ARD Doesn't Cover — The Real Story

Here's where we have to be direct. ARD is powerful, but it makes one foundational assumption: that the agent has already decided to query a registry. It addresses what happens after the decision to look for a tool is made.

Our research shows that most of the selection game happens before a registry is ever queried. In fact, most of it happens before the agent even knows it needs a tool.

The full sequence of influence looks like this:

Train → Search → Fetch → Environment → Registry

ARD starts at step 5. Let's walk through what happens in steps 1 through 4.

1. The Training Prior Problem

Agents don't begin a session with a blank slate. They begin with everything baked in during pretraining — and that data has a cutoff. Our research into agent choices shows that in June 2026, agents are operating on a ~5-month-stale training prior, confidently giving answers based on a January 2026 worldview.

The consequence is subtle but critical: if an agent already "knows" your product from training — even with outdated, incorrect, or competitor-favorable data — it won't fire an ARD registry query. It answers from memory. Incumbents with strong training representation are being confidently recommended right now, even when newer or better alternatives exist. Publishing an ai-catalog.json won't fix that. Nothing in ARD touches your training presence.

2. The Web Search and Fetch Surface

When agents do break out of their prior — typically on questions they flag as needing fresh information — their first stop is a web search, not a registry. And this surface is far messier than any spec accounts for.

In one of our research runs, agents surfaced 215 distinct domains across a single research task. Of those, only ~13 were actually fetched — roughly a 6% open rate. Think of it like an email campaign: you can be in the inbox (surfaced in search results), but getting opened is a different game entirely.

It gets more consequential: 48% of claims were killed — marked as incorrect, contradicted by the fetched content, or simply unverifiable. If your documentation is the source being fetched, what it says determines whether your claims survive that verification step. This entire process — surface, fetch, verify, kill — runs entirely outside any ARD-compliant registry.

3. The Environment Layer

Local environment files can override everything that comes after them. In our E1 experiment, a single one-paragraph AGENTS.md file produced a 100% selection flip: a competing tool went from being selected 3/3 runs to 0/3 runs. Not because of better documentation, not because of a better registry listing — because of a one-paragraph file in the project root.

This aligns with what experienced developers already know. As one Reddit user noted, "the best agent behavior I have seen comes from boring stuff: really explicit system constraints, tool schemas, and a minimal 'you must ask before doing X' policy." The environment layer is that boring stuff — and it fires before any retrieval or registry query. ARD has no specification for AGENTS.md, CLAUDE.md, or cursor rules.

4. Directive Docs

What happens when you ship a breaking change and agents keep calling your deprecated API endpoint? ARD doesn't have an answer to that.

In our E3 experiment, a simple directive document — a plain-language file telling agents to stop using a deprecated API pattern — dropped usage of that pattern from 100% to 0%. Not a registry update, not a new catalog entry. A directive doc. This is an active maintenance surface for every API-first product, and it lives entirely outside the ARD spec.

5. The Scaffolder Injection Layer

Tools that scaffold new projects can permanently bias an agent's operating environment before it ever runs. Bun's init command, for example, writes CLAUDE.md and cursor rules directly into every new project it creates. Every future agent session in that repository starts with Bun's preferences already encoded in the environment — no registry query required.

This isn't an edge case. Scaffolders, boilerplate generators, and framework CLIs are some of the highest-leverage surfaces in agentic discovery precisely because they fire once and persist indefinitely.

The Sequence Summary

To put it plainly:

Step	What It Is	ARD Covers It?
1. Train	Training data & knowledge cutoff	❌ No
2. Search	Web search surface & domain surfacing	❌ No
3. Fetch	Content fetched, claims verified/killed	❌ No
4. Environment	AGENTS.md, CLAUDE.md, cursor rules	❌ No
5. Registry	ARD catalog query at runtime	✅ Yes

ARD is critical infrastructure for step 5. But steps 1–4 are where most tools are selected — or eliminated — before an agent gets anywhere near a registry.

Where ARD Fits in the Full Agentic Discovery Stack

We published our 11-play Agentic Discovery Playbook before ARD was announced. ARD formalizes two of those plays. The other nine remain entirely outside any standard.

Here's how it maps:

The 4-Stage Agent Journey

Every agent that chooses a product runs four stages: find → research → shortlist → act. Here's where ARD lands — and what it misses.

Find (Play 1 + Play 2 + Play 11) — Getting into the running. Play 1 is agent web search: rank for the agent's own fan-out queries, survive the fetch cut, make every claim corroborable. Play 11 is evals and leaderboards: public benchmarks that rank in search and get cited as sources. ARD covers Play 2 (registries) in this stage — getting indexed so you surface in structured registry searches — but doesn't touch Play 1 (web search) or Play 11. This is about SEO for the agentic web, training data presence, and crawlability — none of which are registry concerns.

Research (Plays 1–2, 5–7) — Getting opened and read. The agent asks: "is this what I want?" This is where ARD's registry layer has a second moment: corroboration across parties and coverage for more queries. But the heavier work is Plays 5–7 — llms.txt, markdown docs, and snippet density — which determine whether what the agent opens is readable, credible, and self-contained. Our 48% claim kill rate means nearly half of what agents attempt to verify gets thrown out. ARD doesn't address Plays 5–7.

• Play 2 (AI Agent Registries & Directories): ARD formalizes this completely. Publish an ai-catalog.json and implement the well-known URI. Google's Agent Registry is the first major implementation; more will follow as the federation network grows.
• Play 3 (MCP Server Distribution): The ai-catalog.json manifest is now the standard way to distribute MCP servers. ARD supersedes earlier informal conventions — but only for the discovery mechanism. The docs-MCP and sandbox architecture are separate.

Shortlist (Plays 3–4, 6–7) — Winning the comparison: does it work, can I implement it, is it best? This is where MCP server operability (Play 3) and agent skills/AGENTS.md (Play 4) do their heaviest work. An agent that can operate you — not just read about you — has a fundamentally lower shortlist cut. ARD doesn't address shortlist-stage plays.

• Play 4 (AGENTS.md and Skills): Not addressed by ARD. The environment layer is yours to control — and our experiments show it may be the single highest-leverage surface in the entire stack.

Act (Plays 4, 6, 8–11) — Making integration effortless and locking in for next time. Directive docs (Play 8), scaffolder rules (Play 9), keyless onboarding (Play 10), and evals (Play 11) all operate here. A breaking change without a directive doc means agents keep calling endpoints you've already sunset. Once a scaffolder writes a CLAUDE.md into a project, that preference persists for the lifetime of the codebase. ARD doesn't address any Act-stage plays.

The Competitive Moat

ARD being standardized is good news for everyone who was already thinking about the registry and catalog layer. It removes the guesswork about format and gives you a clear publishing target. But it also means that layer is now table stakes — every competitor is going to publish an ai-catalog.json.

The differentiation moves up the stack. Plays 1, 4, and 5–11 are where the real leverage is, and they require deliberate strategy, not just spec compliance.

Build Your Full-Stack Agentic Discovery Strategy

The Agentic Resource Discovery specification is a genuine milestone. Google, Microsoft, and Hugging Face built something real, and the coalition behind it — Amazon, Cisco, GitHub, Salesforce, Snowflake, Nvidia — means this is going to become the registry standard. If you have an API, an MCP server, or an AI capability of any kind, you should be planning your ai-catalog.json now.

But publishing to a registry is Play 2 and Play 3 of eleven. The training prior that's already shaping agent recommendations, the web search surface where 94% of domains never get fetched, the environment files that flip selection outcomes entirely, the directive docs that determine whether breaking changes actually land — none of that is covered by ARD, and none of it goes away because ARD exists.

The full picture is in our Agentic Discovery Playbook — all eleven plays mapped across the four-stage agent journey (find → research → shortlist → act), and the experiments behind the numbers in this article.

To ensure your tools are selected, not just listed, explore how Synscribe implements the full stack for B2B SaaS companies, from training influence to scaffolder injection.

Frequently Asked Questions

What is the Agentic Resource Discovery (ARD) specification?

The Agentic Resource Discovery (ARD) is an open specification for publishing, discovering, and verifying AI capabilities like tools and APIs. Co-authored by Google, Microsoft, and Hugging Face, it standardizes how AI agents can dynamically find resources across a federated network through machine-readable ai-catalog.json files and searchable registries.

Why is ARD a significant development for AI agents?

ARD is significant because it solves the tool discovery problem at an infrastructure level, enabling agents to dynamically select tools at runtime. This reduces context pollution from pre-loading too many static tools, leading to more efficient and capable agents. It creates a standardized, global network for agent resources, moving beyond ad-hoc solutions.

How do AI agents discover tools using ARD?

AI agents discover tools by querying an ARD-compliant registry, which acts like a search engine for AI capabilities. These registries crawl and index ai-catalog.json files hosted by tool publishers. An agent can then perform a semantic search against the registry to find a verified, relevant tool for its current task, connecting to it on the fly.

What are the main limitations of the ARD specification?

The main limitation of ARD is that it only addresses tool discovery at the moment an agent decides to query a registry. It does not influence the crucial preceding steps, such as the agent's pre-existing training data, its web search behavior, or environmental configurations. These factors often determine tool selection before a registry is ever consulted.

How can I optimize my tool for discovery within an ARD registry?

To optimize your tool for ARD, create a detailed ai-catalog.json file and focus on crafting high-quality representativeQueries. This field is key to ranking in a registry's semantic search. The queries should accurately reflect the problems your tool solves, as this is what an agent will search for. Also, ensure your trust manifest is complete.

What other factors influence tool selection besides ARD registries?

Besides registries, tool selection is heavily influenced by an agent's training data, web search results, and local environment files. An agent may rely on outdated information from its training, be influenced by documentation it finds via web search, or be directed by an AGENTS.md file in its local environment. These surfaces often override or precede a registry query.