Google’s Agentic Resource Discovery specification, or ARD, is a new attempt to solve one of the least glamorous but most important problems in AI: how autonomous agents find the right tools, verify they are trustworthy, and connect to them safely.
That may sound like plumbing, but it matters. As AI shifts from chatbots that answer questions to agents that can plan, call tools, inspect files, query business systems and coordinate with other agents, discovery becomes a real bottleneck. If every company, cloud provider and software vendor uses its own private catalogue, agents become trapped in silos. If discovery is too open and unverifiable, the risks are obvious: spoofed tools, data leakage, unsafe connections and unreliable automation.
Google’s ARD proposal is designed to create a common discovery layer for this “agentic web”. It gives organisations a way to publish catalogues of AI capabilities under their own domains, while giving registries and client agents a method to search, verify and connect using trust metadata rather than blind faith.
What is Agentic Resource Discovery?
Agentic Resource Discovery is an open specification for publishing, discovering and verifying AI capabilities across the web. In practical terms, it is a way for an organisation to describe resources such as MCP servers, A2A agents, OpenAPI tools, internal skills or even nested catalogues in a format that other agents and registries can understand.
Google’s explanation frames ARD around three questions every useful agent will increasingly need to answer:
- Where does the right capability live?
- Which capability should the agent actually use?
- How can the agent verify that the endpoint is safe and legitimate before connecting?
Today, those answers are usually buried inside platform-specific registries, private documentation, custom APIs or manually configured integrations. ARD tries to standardise the discovery step without forcing everyone to use the same runtime, model, framework or protocol.
How Google ARD works
The core idea is simple: a provider publishes a catalogue file on its own domain. Google’s example refers to an ai-catalog.json file at a well-known path. That catalogue describes the provider’s available capabilities, including what the resource does and how an agent should connect to it.
Catalogues under trusted domains
Hosting the catalogue under an organisation’s domain is important because domain ownership becomes part of the identity and trust model. If a bank, SaaS company or cloud provider publishes its agent tools under its own domain, a client agent has a stronger basis for checking that the resource is really associated with that organisation.
Registries act like search engines for agents
ARD also introduces the idea of registries that crawl and index published catalogues. A client agent can query a registry with a plain-language intent, such as needing an observability tool for a production incident or a support-ticket connector for a customer workflow. The registry can return matching capabilities along with the metadata needed to verify the publisher before any connection is made.
Native protocols still matter
ARD is not presented as a replacement for every existing tool protocol. Instead, it is a discovery and verification layer. Once the agent finds and verifies the right capability, it can connect using the tool’s native protocol or API. That could include MCP servers, OpenAPI tools, A2A agents or other systems.
Why ARD matters now
The timing is not accidental. At Google I/O 2026, Google emphasised a broader move toward agent-first development. It announced updates across Gemini, Antigravity, Managed Agents in the Gemini API, Android and Chrome tooling. The common thread is that AI agents are expected to do more than generate text: they will build apps, inspect code, automate quality checks, migrate projects and coordinate workflows.
That future needs a discovery system. A coding agent might need documentation, testing tools, design systems, CI logs, cloud deployment APIs and issue trackers. A business operations agent might need a CRM, a calendar, support history, analytics dashboards and finance systems. Hard-coding every integration is not scalable, and letting agents randomly browse for tools is not safe.
ARD is an attempt to make agent capability discovery more like the web: distributed, searchable and based on published resources. The difference is that AI agents also need stronger verification because they may take actions, not just read pages.
Practical impact for developers and businesses
For developers, ARD could eventually make AI integrations easier to expose and easier to consume. Instead of writing custom onboarding instructions for every agent platform, a software provider could publish a structured catalogue that describes its available tools, supported protocols and trust metadata.
For businesses, the bigger opportunity is governance. Google says its Agent Registry product will support discovering and hosting agentic resources, including agents, skills, MCP servers and other tools. It also highlights enterprise controls such as namespaced URNs, egress policies, tool pinning and cryptographic resource management.
In plain English: companies want AI agents to be useful, but they also need to control what those agents can connect to, which tools are approved, and how access is audited. A discovery layer with verification and policy controls can help IT teams avoid a chaotic sprawl of unofficial agent integrations.
Risks and limitations
ARD is promising, but it is not magic. A discovery standard only works if enough providers adopt it. If major platforms build incompatible catalogues or keep capabilities locked inside private marketplaces, the agentic web may remain fragmented.
Security also depends on implementation details. Publishing catalogues under verified domains helps, but businesses still need access control, permission boundaries, monitoring and safe defaults. An agent that can discover more tools can also make bigger mistakes if it is over-permissioned or poorly supervised.
There is also a trust challenge around registries. If registries become the search engines of the agentic web, their ranking, indexing and verification practices will matter. Developers and enterprises will need transparency about how capabilities are selected and how malicious or outdated resources are handled.
What to watch next
The most important signal will be adoption. Watch whether cloud providers, SaaS vendors, open-source agent frameworks and enterprise software companies start publishing ARD-compatible catalogues. Also watch how ARD relates to MCP, A2A and browser-based efforts such as WebMCP, because developers do not want another isolated standard competing for attention.
Google says native ARD support will be available in Agent Platform in the coming months. If that arrives with strong developer tooling and real partner support, ARD could become a practical foundation for trusted AI agent discovery rather than just another specification.
Conclusion
Google’s Agentic Resource Discovery specification tackles a problem that will become more urgent as AI agents move into everyday software workflows. Finding a tool is easy for a human with a browser. For an autonomous agent that may connect to systems, exchange data and trigger actions, discovery must be structured, verifiable and governed.
ARD is worth watching because it focuses on the connective tissue of the AI ecosystem. If agents are going to work safely across organisations, they need more than powerful models. They need a trustworthy way to find and verify the capabilities around them.