AI agents depend on tools, skills, and other agents spread across many teams, organizations, and platforms. These capabilities live in separate systems with their own registries, and an agent working in one environment has limited means to locate and connect to a resource hosted somewhere else.

Google addressed this gap with Agentic Resource Discovery, an open specification for publishing, discovering, and verifying AI capabilities across the web. It allows tools and services to be shared and connected across organizations regardless of their underlying framework, protocol, or provider.

The problem ARD targets

An operations agent investigating a production incident illustrates the case for the specification. Resolving the issue could require the agent to query observability systems, search engineering documentation, review deployment history, open support tickets, and consult specialized troubleshooting agents. Many platforms already run custom registries for such capabilities, and those registries stay fragmented and siloed within specific ecosystems. ARD supplies a standard way for agents to discover capabilities across organizational boundaries and establish trust in what they find.

“For this ecosystem to scale, agents need reliable answers to three questions: Where does the right capability live? Which capability should I actually use? And how do I verify it’s safe to connect to?” Google Software Engineers explained.

Catalogs and registries

ARD relies on two building blocks. An organization publishes a catalog that describes its available capabilities, hosted as an ai-catalog.json file at a well-known path under the organization’s own domain. Ownership of that domain serves as the cryptographic foundation for identity and trust. A catalog can list MCP servers, A2A agents, OpenAPI tools, or nested catalogs.

Registries operate as search engines for the agentic web. They crawl published catalogs, index the contents, and make them searchable. When an agent submits a discovery request, a registry returns matching capabilities along with the metadata needed to verify the publisher before any connection occurs.

The ARD workflow moves through four stages. A provider publishes its catalog at a well-known path on its domain. An agent that needs a capability either queries a registry with a plain-language intent or fetches a catalog directly from a known partner’s domain. Publishers can attach verifiable trust metadata for production environments, letting the agent or registry confirm the publisher’s cryptographic identity before connecting. The agent then loads the capability, interacts with it through its native protocol or API, and returns the result to the user.

Support in Gemini Enterprise Agent Platform

Google Cloud backs the specification through Agent Registry in Gemini Enterprise Agent Platform, which forms part of the federated network. Agent Registry provides hosted support for searching, discovering, and hosting agentic resources, including agents, skills, MCP servers, and other tools. Users can onboard capabilities directly onto it, and authenticated publisher onboarding is planned.

Agent Registry also carries enterprise governance functions. It assigns globally unique namespaced URNs, enforces agentic egress policies, and pins tools and specifications. It manages secure resources using Agent Identity to verify the trust manifest, the cryptographic layer that proves agent authenticity and meets compliance standards such as HIPAA. Native ARD support will reach Agent Platform in the coming months.

Availability

The ARD specification is available now under the Apache 2.0 license and builds on the AI Catalog data model from the AI Catalog Working Group under the Linux Foundation. Developers can publish a catalog using the quickstart guide, read the schemas and federation model, or contribute through the project’s GitHub repository.

Download: The IT and security field guide to AI adoption