Select Page

Google has introduced Agentic Resource Discovery (ARD), an open specification that could become a key building block for the next wave of AI agents. Instead of every agent platform relying on its own private directory of tools, ARD is designed to help agents find capabilities across the web, verify who published them, and connect using the tool’s native protocol.

That may sound technical, but the idea is important: as AI assistants move from answering questions to taking action, they need a safer and more standard way to discover APIs, Model Context Protocol (MCP) servers, enterprise tools, skills and even other agents. Google’s announcement also lands as the company pushes developers toward more agent-first products, including Antigravity CLI and Gemini Enterprise Agent Platform.

What is Agentic Resource Discovery?

Agentic Resource Discovery is an open specification for publishing, discovering and verifying AI capabilities across the web. Google describes it as a way for tools and services to be shared and connected securely, regardless of the underlying framework, protocol or provider.

The problem ARD tries to solve is fragmentation. Today, many AI tools live inside separate registries, marketplaces or enterprise platforms. A coding agent may know about one set of plugins, a customer support agent may use another private system, and a cloud operations agent may depend on internal documentation, observability dashboards and ticketing tools. Those resources often cannot be discovered or trusted in a consistent way outside their original environment.

ARD proposes a web-like discovery model for that agent ecosystem. Organisations publish machine-readable catalogs under their own domains, while registries crawl and index those catalogs so agents can search for capabilities and verify them before connecting.

How ARD works

Google says ARD is built around two core ideas: catalogs and registries.

Catalogs publish available capabilities

A catalog is a file hosted by an organisation that describes the AI resources it offers. According to Google’s example, this could include MCP servers, Agent-to-Agent (A2A) agents, OpenAPI tools or nested catalogs. Because the catalog is hosted under the organisation’s own domain, domain ownership becomes part of the trust model.

Registries make those capabilities searchable

Registries act like search engines for agentic resources. They crawl published catalogs, index the contents and return matching capabilities when an agent requests a tool or service. Crucially, the registry can return metadata that helps the agent verify the publisher before making a direct connection.

Verification happens before connection

Google emphasises cryptographic verification as a production requirement. The goal is not just for an agent to find a tool, but to confirm that the tool really belongs to the organisation it claims to represent. Once trust is established, ARD steps out of the way and the agent connects directly using the resource’s native API or protocol.

Why this matters for AI agents

AI agents are becoming more useful because they can use tools. A research agent can search documents, a developer agent can modify code, and an operations agent can inspect logs or file support tickets. But as soon as agents start taking actions across multiple systems, discovery and trust become major risks.

Without a common discovery layer, every platform has to build its own integration directory. That slows adoption, locks developers into specific ecosystems and makes governance harder for businesses. With a standard such as ARD, the long-term promise is that agents could discover the right capability at runtime while still respecting organisational controls.

For users, this could mean more capable assistants that can safely work across apps and services. For developers, it could mean fewer one-off plugin integrations. For businesses, it could create a cleaner way to publish approved tools for internal and external agents while maintaining visibility and policy control.

Google’s enterprise angle: Gemini Agent Registry

Google is connecting ARD to its Gemini Enterprise Agent Platform through Agent Registry. The company says Agent Registry will support searching, discovering and hosting agentic resources, including agents, skills, MCP servers and other tools.

That enterprise framing matters. Large organisations do not just need agents to find tools; they need governance, access controls, identity and auditability. Google says Agent Registry will support features such as globally unique namespaced identifiers, agentic egress policies, specification pinning and secure resource management using Agent Identity.

In plain English: businesses want AI agents, but they also want to know which tools those agents are allowed to use, where data is going and whether a discovered resource is legitimate. ARD is the open specification, while Google’s Agent Registry is the managed product layer built around that vision.

Practical impact for developers and businesses

For developers building AI tools, ARD could make discoverability a first-class feature. Instead of waiting for every platform to manually approve an integration, a company could publish a catalog that describes what its service can do and how agents should connect to it.

For teams already experimenting with MCP servers, OpenAPI-based tools or agent-to-agent workflows, ARD may become a useful way to expose those resources beyond a single app. It also aligns with the broader shift toward multi-agent workflows, where different specialised agents collaborate rather than one assistant doing everything alone.

Google’s separate announcement about moving Gemini CLI users toward Antigravity CLI reinforces that direction. The company says developer workflows have moved beyond a single terminal assistant and now require multiple agents communicating through a unified backend. ARD fits naturally into that kind of world: agents need to find capabilities, verify them and compose them into workflows.

Risks and limitations to watch

ARD is promising, but it is still early. Standards only matter if enough developers, platforms and enterprises adopt them. If ARD becomes mostly a Google Cloud feature, its open-web potential will be limited. The real test is whether non-Google platforms, independent tool makers and enterprise software vendors publish compatible catalogs and support interoperable registries.

Security will also be critical. A searchable web of agent tools creates obvious abuse opportunities if verification is weak, policies are misconfigured or agents are allowed to connect too freely. Businesses will need strong approval workflows, monitoring and data-loss protections before allowing agents to discover and use resources dynamically.

There is also the user trust problem. If an AI agent chooses tools automatically, people need clear visibility into what it connected to, what permissions were granted and what data was shared. Discovery should not become a black box.

What to watch next

The next signs to watch are partner adoption, developer tooling and real-world examples. ARD will become more interesting if major AI platforms, SaaS vendors, open-source agent frameworks and cloud providers begin publishing catalogs or running compatible registries.

Developers should also watch how ARD interacts with MCP, A2A, OpenAPI and enterprise identity systems. The winning agent ecosystem is unlikely to be a single protocol. More likely, it will be a stack of complementary standards where discovery, trust, permissions and tool execution each have their own layer.

Conclusion

Google’s Agentic Resource Discovery specification is not just another AI announcement. It points to a bigger shift: AI agents need infrastructure that looks more like the web, with discoverable resources, verifiable publishers and standard ways to connect.

If ARD gains broad support, it could make agentic AI more useful for developers, safer for businesses and less fragmented for users. The challenge will be turning an open specification into a trusted ecosystem that works across companies, platforms and protocols—not just inside one vendor’s cloud.

Sources