Select Page

Google ARD: How AI Agents Could Discover Trusted Tools Online

by | Jul 2, 2026 | AI | 0 comments

Abstract illustration of AI agents discovering trusted tools across a secure network

AI agents are quickly moving from simple chatbots to systems that can call tools, use APIs, search company knowledge, and hand work to other specialised agents. That shift creates a basic but important problem: how does an AI agent know which outside capability is real, useful and safe to connect to?

Google has put a name to that missing layer with Agentic Resource Discovery, or ARD, an open specification for publishing, discovering and verifying AI capabilities across the web. The proposal is still early, but it matters because it points to a more interoperable future for AI agents, especially in businesses where tools are spread across cloud platforms, internal systems and third-party services.

Background: AI agents need a discovery layer

Today, many agentic apps are built by manually connecting a model to a fixed set of tools. A developer might wire a support assistant to a ticketing system, a documentation search tool, a CRM, and a few internal APIs. That works for a controlled product, but it does not scale well when every team, vendor and platform publishes its own agents, MCP servers, OpenAPI tools or workflows.

The web solved a similar discovery problem for information with pages, links, search engines and domain-based identity. ARD aims to do something narrower for callable AI resources. Instead of discovering articles or websites, an agent could discover capabilities it can actually use for a task.

What Google announced

On 17 June 2026, Google announced Agentic Resource Discovery as an open specification for finding and verifying tools, skills and agents across the web. The specification was developed with industry partners, with contributors named across the broader ecosystem including Microsoft, GitHub, Hugging Face, Cisco, Databricks, GoDaddy, NVIDIA, Salesforce, ServiceNow and Snowflake.

Google describes ARD as a way for organisations to publish available AI capabilities under their own domain, while registries index those resources and make them searchable. In practical terms, a provider can expose a structured catalog file that describes resources such as MCP servers, A2A agents, OpenAPI tools, skills, APIs, workflows or even other catalogs.

Catalogs and registries

ARD is built around two core ideas: catalogs and registries. A catalog is a machine-readable description of the capabilities an organisation offers. Google’s example refers to an ai-catalog.json file hosted at a well-known path on the publisher’s own domain. Hosting the catalog on the organisation’s domain gives the discovery process an identity anchor: the domain itself helps establish who published the resource.

Registries then act like search engines for the agentic web. They crawl catalogs, index the available resources and respond when an AI client asks for a capability. The agent can search by intent, receive matching resources, inspect trust metadata, and then connect directly to the selected resource using its native protocol.

Why Agentic Resource Discovery matters

The most useful AI agents will not live inside one neat app. They will need to coordinate across calendars, files, databases, code repositories, cloud services, support desks, analytics platforms and other specialised agents. Without a standard discovery mechanism, each connection becomes another custom integration that must be maintained and trusted separately.

ARD could reduce that friction. If the ecosystem matures, software makers may be able to publish their agent-ready capabilities once and make them discoverable across multiple AI clients. Developers could spend less time hard-coding tool lists and more time deciding policies, permissions and user experience.

For Google, ARD also connects to its enterprise AI ambitions. Google says Agent Registry in the Gemini Enterprise Agent Platform is designed to help organisations search, host and govern agentic resources such as agents, skills and MCP servers. Native ARD support is positioned as part of that wider federated network.

Practical impact for developers and businesses

For developers, the immediate takeaway is not that every website needs an ARD catalog tomorrow. This is mainly relevant to teams that publish callable capabilities: APIs, AI tools, MCP servers, workflow automations or agents that other systems might use. Those teams should watch the specification because it may become a standard way to make their tools discoverable by AI clients.

For businesses, the bigger issue is governance. As employees adopt more AI assistants, companies will need answers to questions such as: which tools can an agent use, who approved them, what data can they access, and how can the organisation verify that a resource is really from the claimed publisher? ARD’s emphasis on domain ownership and cryptographic trust metadata is important because discovery without verification would create obvious security risks.

Creators and smaller software companies should also pay attention. If agent discovery becomes a meaningful traffic and integration channel, being listed in trusted registries could become similar to being visible in an app marketplace or developer directory. However, that opportunity is still speculative and depends on adoption by major AI clients.

Risks, limitations and open questions

ARD is not an execution runtime. It does not replace MCP, OpenAPI, A2A, plugins or an organisation’s own API security model. It sits before invocation, helping an AI client find a suitable resource. The resource still needs its own authentication, permission checks, rate limits and safety controls.

There are also adoption questions. A discovery standard only becomes valuable if many publishers create catalogs and many registries index them well. Ranking, spam prevention, access control and trust scoring will matter. An open registry that accepts everything may become noisy, while a locked-down registry may limit interoperability.

Security is the other major concern. If AI agents can dynamically find and connect to tools, attackers will try to abuse that discovery process. Enterprises will need strict allowlists, review workflows, signed metadata and monitoring before letting agents connect to newly discovered resources in production.

What to watch next

The next step is ecosystem proof. Watch whether GitHub Copilot, Google Gemini tools, Microsoft Copilot, Hugging Face and enterprise platforms make ARD discovery visible in real workflows. Also watch whether the specification changes as developers test it with MCP servers, internal enterprise agents and public APIs.

If you build AI tools, it is worth reading the specification and tracking reference implementations. If you run a business, the practical move is to inventory which internal tools an AI agent should be allowed to discover and which should remain private or blocked. The agentic web will need good discovery, but it will need stronger governance even more.

Conclusion

Google’s Agentic Resource Discovery is an early but significant attempt to standardise how AI agents find and verify useful capabilities online. It will not transform everyday browsing overnight, and it is not aimed at ordinary content sites in the same way search engines are. But for developers, cloud platforms and companies building agent-ready tools, ARD could become an important building block for the next phase of AI software.

Sources

Submit a Comment