Google Just Made the Agentic Internet Official

Every agent system I have built in the last eighteen months has the same structural problem: the agent knows what it can do within its own toolset, but it has no reliable way to discover what other agents or services can do outside of it. We solve this by hardcoding integrations, maintaining private registries, or simply not connecting the systems at all. None of those are real solutions. They are workarounds. Google just published the spec that removes the need for them.

The Agentic Resource Discovery specification defines two things: how organizations publish what their agents and tools can do, and how other agents find and verify those capabilities before connecting to them. It is not a Google product. It is an open standard with a straightforward mechanism at its center.

What ARD actually is

From my perspective, think of it as the equivalent of DNS for AI agents. When a browser needs to reach a server, it does not require a hardcoded IP address and a private agreement between the two parties. It queries a shared resolution layer that any domain can register with. ARD does the same thing for agent capabilities.

An organization publishes an ai-catalog.json file at a standardized path on their domain. That file describes what the organization exposes: MCP servers, agents, OpenAPI tools, or nested catalogs pointing to partner systems. Any agent that knows the domain can fetch this file directly. A registry can index it. The catalog becomes the authoritative source of truth for what that domain offers to the agentic layer.

Discovery works in two directions. An agent can query a registry with a natural language intent, "I need a capability that can process medical claims data", and the registry returns matching catalog entries with cryptographic metadata to verify the publisher before the connection is made. Or an agent can fetch a known partner's catalog directly and load its capabilities on demand. Both paths work. Neither requires a custom integration built ahead of time.

That last sentence is the one that matters.

The manifest format and what it actually contains

The ARD spec defines the catalog manifest as a structured JSON document with a small set of required fields and a richer set of optional descriptors. At minimum, a valid catalog declares the organization name, a schema version, and at least one entry in the resources array. Each resource entry carries a type (agent, mcp-server, openapi, or catalog for nesting), a human-readable name and description, and an endpoint URI.

Beyond the minimum, entries can carry capability descriptors: what the resource can do, what input formats it accepts, what output formats it produces, what authentication mechanism it requires, and what rate limits apply. This last part, rate limit negotiation in the manifest itself, is something I want to call out specifically. It means an agent can check whether it has budget to use a capability before initiating the call. That is a genuine architectural improvement over the current state, where you discover rate limits by hitting them.

Trust anchors are the security primitive. The spec uses domain ownership verified via TLS as the root of trust, the same chain that browsers use for HTTPS. A resource published at a domain is cryptographically tied to whoever controls that domain. An agent consuming a catalog can verify the signature chain before executing anything. That does not solve the problem of a legitimate organization publishing a malicious capability, but it does eliminate impersonation as a surface.

The problem it solves is real and it is costing teams right now

Every agent team building today is maintaining their own internal registry. It lives in a config file, a database table, or a shared Notion document that someone updates when they remember to. The agent ecosystem is fragmented into silos not because the technology cannot connect things, but because there was no standard for how to describe and find what exists. The tools are capable. The discovery layer was missing.

This fragmentation has a compounding cost. When two agent systems from different organizations need to collaborate, a client's CRM agent working with a vendor's fulfillment agent, for example, someone has to write a custom bridge. That bridge is built once, maintained indefinitely, and breaks every time either side ships a change. The integration tax on multi-organization AI workflows is enormous, and it is entirely caused by the absence of a shared discovery layer.

ARD does not eliminate integration work. It eliminates the discovery and negotiation step that precedes it. That is the part that scales poorly.

ARD sits on top of A2A, and that matters

From my perspective, google published the Agent-to-Agent protocol earlier this year as the mechanism for agents to communicate once they have found each other. ARD is the layer that comes before A2A. It is the registry layer, the directory service, the lookup mechanism. Without ARD, A2A calls require you to know the endpoint ahead of time. With ARD, an agent can discover what endpoints exist, what they offer, and whether they are trustworthy, before initiating any A2A communication.

The combination changes what multi-agent architectures look like in practice. Today, building a system where Agent A hands off to Agent B from a different organization requires three things: a business agreement, an integration contract, and a maintained endpoint configuration. With ARD plus A2A, you need the business agreement and nothing else. The technical coordination happens at runtime through published catalogs and standardized protocol calls.

The closest analogy is what OpenAPI did for REST APIs a decade ago. Before OpenAPI, you consumed an API by reading documentation and writing a custom client. After OpenAPI, you consumed an API by loading a machine-readable spec and generating the client. ARD does the same thing for agent discovery: it turns the "what can you do" question from a documentation problem into a protocol problem. Documentation problems do not scale. Protocol problems do.

Why the design is right

The use of domain ownership as the cryptographic foundation for identity is the correct architectural decision. It means trust is anchored to something that already has an enforcement mechanism: domain registration and TLS certificates. An organization cannot fake a catalog at a domain it does not control. This is not a novel idea, it is how the web has handled identity verification for thirty years. Reusing that foundation for agent trust is the right call because it avoids building a parallel identity infrastructure from scratch.

The catalog file format sitting at a well-known path also means any system that can serve HTTP can participate. There is no proprietary SDK required to publish. A static JSON file on a CDN is a valid ARD publisher. The lowest implementation barrier possible for the widest possible adoption. Standards succeed when adoption is cheap. This one is designed that way.

How ARD compares to how agents are discovered today

The current state of agent discovery is one of three things: hardcoded URLs in environment config, a proprietary internal service catalog maintained manually, or no discovery at all and the agent simply knows about every capability it will ever use from the moment it is written. None of these approaches survives contact with scale. The hardcoded URL breaks when the endpoint moves. The proprietary catalog drifts out of sync with what services actually expose. The static approach means adding a new capability requires a code change and a deployment.

Compare that to how the web solved the analogous problem for services. OpenAPI gave teams a machine-readable contract for REST APIs. Before OpenAPI, consuming an API meant reading documentation in a browser and writing a custom HTTP client. After OpenAPI, you loaded the spec and the client generated itself. ARD does the same thing one layer up: it gives the agent a machine-readable contract not just for one service, but for everything a domain exposes across all of its agent-compatible resources. The catalog is the OpenAPI spec for the entire organization's agentic surface area.

The practical difference for a builder is meaningful. Today, connecting two agent systems from different organizations requires business alignment, an integration document, an engineering sprint to write the bridge, and an ongoing maintenance commitment. With ARD in place on both sides, the engineering sprint shrinks to reading a catalog and verifying trust anchors. The integration tax drops from weeks to hours, and the ongoing maintenance moves from custom bridges to catalog freshness.

What is still missing from the spec

From my perspective, aRD in its current form does not specify how auth delegation works when an agent discovers a capability at runtime and needs to authenticate on behalf of a user. The catalog can tell you that a resource requires OAuth 2.0. It does not tell you how a downstream agent should obtain, store, or pass the token. That is a meaningful gap for enterprise deployments where every action taken by an agent needs to be attributable to a specific user or service account.

Version pinning is the second gap. The manifest can declare a version string, but there is no mechanism for a consuming agent to specify which version it was validated against or to receive notifications when the capability spec changes. In a static integration you manage this with dependency locking. In a dynamic discovery model you need a different mechanism. The spec does not define one yet.

Rate limit negotiation is partially addressed. The manifest can declare limits, but there is no standardized way for an agent to reserve capacity in advance or to queue requests when limits are approached. That matters in agentic pipelines where you do not want a workflow to fail mid-execution because a downstream capability ran out of quota three steps in.

These are not reasons to wait. They are gaps worth tracking in the GitHub issues on the spec repository. The core mechanism is solid. The edge cases around enterprise auth and rate management will get filled in as more teams implement it and surface real requirements.

What this means for the infrastructure layer

If ARD achieves broad adoption, and the involvement of Google Cloud's enterprise infrastructure is a strong forcing function for that, the mental model for building multi-agent systems changes. Instead of designing integrations upfront and maintaining them as contracts between specific systems, you design agents that can discover what is available at runtime and compose workflows dynamically. The difference is the same as the difference between writing a directory of phone numbers on paper and using a search engine.

For teams building agent infrastructure right now, there are two immediate decisions. First: whether to publish a catalog now, even a minimal one describing what your systems expose. Getting into the pattern early, before registries are searching for you, is a low-cost way to build operational familiarity with the spec. Second: whether to build your internal agent registry against ARD conventions rather than a proprietary schema. A private registry that follows the catalog format can be made discoverable externally when the time comes, with no migration required.

The teams that will benefit most from this standard are not the ones who wait for it to mature. They are the ones who build against it now and have functional catalogs ready when other agents start querying them.

The plumbing layer is here. The question now is whether your systems are ready to be found.