Google's ARD Gives AI Agents a Search Layer

The missing map for agents

Agents do not need another demo. They need a map.

Google announced the Agentic Resource Discovery specification this week with Microsoft, GitHub, Hugging Face, GoDaddy, Cisco, Snowflake, and other infrastructure companies circling the same problem: AI systems are getting good enough to use tools, skills, APIs, MCP servers, workflows, and other agents, but bad at finding the right capability at the right moment. That sounds unsexy. It is not. Discovery is what turns a pile of integrations into a platform.

The specification, usually shortened to ARD, is an open protocol for publishing, indexing, searching, and verifying agentic resources across federated registries. The official site describes the core question simply: what is available for this task? That is the question every useful agent eventually hits. The model may know how to reason. The runtime may know how to call a tool. The enterprise may have already approved a database agent, a support-workflow agent, and a tax-compliance agent. None of that matters if the user, client, or orchestrator does not know those resources exist.

ARD matters because the agent stack is splitting into layers. Anthropic’s Model Context Protocol standardized how AI applications connect to external systems, and Anthropic later donated MCP to the Linux Foundation’s Agentic AI Foundation alongside Block’s goose and OpenAI’s AGENTS.md. Google’s Agent2Agent protocol targets another layer, giving agents a way to communicate and coordinate across enterprise systems (Google Developers). ARD sits before both. It does not tell an agent how to invoke a tool. It helps the agent decide which tool deserves to be invoked.

That distinction is the story. The first agent era was about capability: Can the model browse, code, call a function, or operate a desktop? The second era is about routing: Which capability should it use, under whose authority, with what trust metadata, and against which approved registry? Microsoft says ARD creates a common discovery layer for publishing, indexing, and finding AI capabilities so clients can tap new tools dynamically (Microsoft Command Line). In plain English, the agent world is moving from “install the plugin” to “search the capability graph.”

The timing is not accidental. The last two weeks have shown how fast the agent market is hardening into infrastructure. OpenAI bought Ona to give Codex cloud agents a durable execution home, which I covered as the shift from coding assistant to persistent agent runtime (internal). SpaceX then agreed to buy Cursor for $60 billion, turning an AI coding editor into a strategic distribution layer (internal). ARD attacks the same stack from a different angle. Instead of owning the editor or the runtime, it tries to define the discovery substrate every editor and runtime can query.

Here is the proprietary math. If a large company builds 500 internal agents and uses 10 AI clients across engineering, sales, finance, support, and operations, manual wiring creates up to 5,000 client-resource relationships before a single vendor integration enters the picture. A domain-anchored ARD catalog plus one governed discovery endpoint changes the problem from pairwise integration to registry curation: 500 resources, 10 clients, and one policy plane. That does not eliminate governance work. It moves governance to the place where it can actually be audited.

This is why the launch list matters. The official ARD specification names Google, Microsoft, and Hugging Face among its authors and describes a v0.9 draft aligned with the broader AI Catalog standard (ARD spec). Hugging Face frames it as the missing discovery layer in front of MCP, Skills, and A2A, explicitly stressing that it is not a product or marketplace (Hugging Face). GitHub is already shipping an implementation through Copilot agent finder, which lets Copilot search an approved registry for MCP servers, skills, canvases, agents, and tools instead of loading every possible capability into context (GitHub Changelog).

That is the first sign ARD is more than a white paper. Standards become real when a distribution surface makes them useful. GitHub has the developer surface. Google has Gemini and the web-standard muscle. Microsoft has Copilot, enterprise procurement, and the person who co-created much of the semantic web vocabulary, R.V. Guha, as the named author of its announcement. Hugging Face has the open model and tool community. Snowflake has governed enterprise data. Together, they are not declaring victory. They are naming the next bottleneck.

The bottleneck is not intelligence. It is addressability.

Discovery becomes the control plane

The most important layer in AI may be the one users never see.

The ARD architecture is deliberately modest. Snowflake describes four steps: publish a standard ai-catalog.json manifest on a domain, let discovery services curate collections, allow clients to search those collections, then have the client connect directly to the chosen resource over its native protocol (Snowflake). The discovery service does not stay in the invocation path. It is a broker of knowledge, not a runtime tollbooth.

That design choice is strategically important. If ARD tried to become the execution layer, it would collide with MCP, A2A, REST, proprietary agent frameworks, and every cloud provider’s managed tooling. By staying before invocation, it becomes easier for rivals to accept. MCP can remain the tool connection standard. A2A can remain an agent-communication standard. Skills can remain instruction bundles. APIs can remain APIs. ARD becomes the search and trust layer above them.

The AI Catalog standard provides the metadata spine. Its manifest pattern uses a well-known location, /.well-known/ai-catalog.json, to advertise resources from a publisher’s own domain, including identifiers, resource types, endpoints, descriptions, and optional trust metadata (AI Catalog). That domain anchoring is not decorative. In an agent economy where a malicious tool can steal data, execute code, or poison a workflow, identity is part of product quality. A resource that cannot prove where it comes from should not be treated like a resource at all.

Help Net Security caught the security angle clearly: agents already depend on tools, skills, and other agents scattered across teams and platforms, but those capabilities live in fragmented registries with limited ways to discover or verify them across boundaries (Help Net Security). ARD’s promise is not just convenience. It is a governed answer set. If the registry only indexes approved resources, the agent’s world becomes smaller, safer, and more legible.

That makes ARD a procurement story as much as a developer story. Enterprise AI buyers already know how tool sprawl ends. Someone connects a plugin for a pilot. Another team wires a different MCP server to a different assistant. A vendor ships a specialized agent with its own registry. Security eventually discovers that nobody has a complete map of which autonomous systems can touch which data. ARD gives the enterprise a place to make the map explicit.

It also changes context economics. Today’s agent configurations often stuff tool schemas, instructions, and endpoint knowledge into context before the model knows whether it needs them. That wastes tokens and expands the blast radius. GitHub’s agent finder announcement makes the operational logic concrete: agents can load what the work calls for instead of carrying every tool just in case. In a world where long-context windows are expensive and fragile, discovery at runtime is a cost-control mechanism.

The deeper shift is ranking. Search engines did not merely make web pages findable. They decided which pages mattered. ARD-compatible discovery services will do the same for tools and agents. They will choose what gets indexed, how results are ranked, which trust signals matter, which vendors are allowed, and which internal capabilities surface for which employees. That is why the “open” label should not lull anyone into thinking the layer is neutral by default. A protocol can be open while every implementation has politics.

The quantified takeaway is that ARD moves the unit of competition from the connector to the catalog. The Linux Foundation said MCP had more than 10,000 published servers and AGENTS.md had already been adopted by more than 60,000 open source projects when the Agentic AI Foundation launched (Linux Foundation). Those numbers were already too large for manual selection. Add enterprise workflows, private agents, SaaS actions, database agents, security responders, and vertical compliance tools, and the next scarce asset is not another integration. It is the ranked, governed index of integrations.

That is why ARD should worry marketplaces. If an AI client can query any approved discovery service, the default app-store model weakens. Value moves toward the party that owns trust, ranking, and workflow context. GitHub can rank developer resources. Snowflake can rank governed data agents. Microsoft can rank workplace capabilities. Google can rank web-scale resources. The protocol creates interoperability, but it also creates a battlefield for curation.

Where the open layer can bend

Open standards solve one problem by creating another.

The obvious failure mode is fragmentation. ARD explicitly allows many discovery services, each with its own index, ranking, access policies, and trust model. That flexibility makes enterprise adoption possible, but it also means two ARD-compatible clients may see very different worlds. A sales assistant using a Microsoft-curated registry, a developer using GitHub’s catalog, and an analyst using Snowflake’s internal endpoint may all ask the same task question and get different resources. That is governance by design. It is also a new source of invisible inconsistency.

The second risk is registry capture. Whoever controls the default catalog gains a powerful lever. They can privilege first-party tools, bury competitors, or require commercial terms for visibility. The web learned this lesson through search and app stores. Discovery layers start as maps and become toll roads when distribution concentrates. ARD’s best defense is federation, but federation only matters if clients actually make it easy to query multiple registries and compare results.

The third risk is false trust. A signed manifest is not the same as a safe agent. Domain control proves provenance, not quality. A vendor can honestly publish a dangerous tool. An internal team can accurately describe an agent that still has excessive permissions. A registry can rank a resource highly because it is popular, not because it is appropriate for the data in front of the model. ARD can carry trust metadata, but metadata is not judgment. Enterprises still need security review, role-based access, audit logs, revocation, and incident response.

The fourth risk is stale discovery. Agents operate in changing environments: APIs move, permissions expire, tools are deprecated, model-routing policies shift, and compliance attestations age. A discovery layer is only as good as its freshness. If ARD catalogs become another static inventory that nobody maintains, they will create a new kind of failure: agents confidently selecting resources that no longer behave as advertised.

The fifth risk is over-automation. Runtime discovery feels elegant until an agent chooses a capability the user did not expect. GitHub’s implementation wisely says agent finder does not auto-install resources and that users stay in control of what gets wired in. That boundary should become a norm. Discovery should recommend. Installation and permission grants should remain explicit, especially when the resource can touch customer records, production systems, financial data, or source code.

There is also a competitive tension under the open rhetoric. Google, Microsoft, GitHub, Hugging Face, Snowflake, Cisco, Databricks, Nvidia, Salesforce, ServiceNow, and GoDaddy all have rational reasons to support an open discovery layer. They also have rational reasons to make their own implementation the most important one. The same company can champion interoperability at the protocol level and compete aggressively at the catalog level. That is not hypocrisy. It is how infrastructure markets mature.

The biggest counterpoint is that ARD may be too early. Many enterprises still do not have enough production agents to need agent discovery. Some have pilots, demo workflows, and disconnected MCP servers, not a discoverability crisis. For those companies, ARD will feel like plumbing ahead of demand. The practical answer is that standards often arrive before the flood. DNS, RSS, OAuth, and Kubernetes all looked overbuilt to some users before the complexity they managed became unavoidable.

The other counterpoint is that existing platforms may solve discovery inside their own walls. Microsoft can make Copilot good at finding Microsoft-approved skills. Google can make Gemini good at finding Google and Workspace actions. Salesforce can make Agentforce good inside Salesforce. Why does the market need an open layer? Because useful work does not respect vendor boundaries. Incident response may need Datadog, GitHub, Slack, Snowflake, PagerDuty, and an internal runbook agent. Finance analysis may need ERP data, a spreadsheet model, policy documents, and a vendor-risk workflow. The workflow is cross-platform even when the vendor would prefer it not to be.

ARD is therefore a bet on heterogeneity. It assumes the agent economy will not collapse into one universal assistant or one all-powerful app store. It assumes companies will keep many AI clients, many SaaS systems, many internal agents, and many trust boundaries. That is the conservative view of enterprise software, which is why it is probably right.

The practical counterweight is scope discipline. ARD should not become a dumping ground for every half-built automation a team can publish. A useful discovery layer needs standards for naming, versioning, representative queries, retirement, ownership, and incident response. Otherwise the registry becomes a more formal version of the same mess it was supposed to fix. The winning implementations will make publishing easy but make trust earned.

What operators should wire now

The smartest move is to treat ARD as a governance rehearsal, not a mandate.

Start by inventorying resources as if ARD already existed. List every MCP server, internal agent, SaaS action, API workflow, coding skill, support bot, analytics assistant, and automation that an AI system can call. For each one, record the owner, domain, endpoint, data access, authentication method, task description, allowed users, audit trail, and revocation path. Even if you never publish a single ai-catalog.json, that inventory will expose the agent sprawl already forming inside the company.

Then separate invocation from discovery in your architecture. If your agent client hardcodes every tool, the client becomes the policy surface. That does not scale. The better pattern is a governed registry that answers which resources are eligible for a task, followed by a separate invocation layer that uses MCP, A2A, REST, or a native workflow protocol. ARD formalizes that split. Adopting the mental model now will make future migration easier.

Third, decide who gets to rank. Ranking is policy in disguise. A security team may want the safest tool first. A business unit may want the fastest. A platform team may prefer first-party resources for supportability. A procurement team may prefer contracted vendors. Those priorities will collide. The registry should make the ranking logic legible enough that teams can argue about policy instead of debugging mysterious agent choices.

Fourth, treat trust metadata as a starting point. A catalog entry should include provenance, resource type, representative queries, compliance attestations, and permission requirements where possible. But the runtime should still enforce least privilege. A discovered agent should not inherit broad access just because it was found. Authentication, authorization, logging, and policy checks belong in the call path, not only in the catalog.

Fifth, keep an exit path. The healthiest version of ARD lets organizations query multiple discovery services and move catalogs between clients. The unhealthy version becomes yet another proprietary marketplace with an open veneer. When evaluating Copilot, Gemini, Claude, ChatGPT, Snowflake CoWork, or any internal agent client, ask whether it can consume your registry, respect your ranking rules, and export catalog decisions in a durable format.

Operators should make a short checklist:

• Create an agent inventory. Name every AI-callable resource and assign an owner before the registry becomes too large to reason about.
• Publish one internal catalog. Start with non-sensitive resources and learn how descriptions, representative queries, and resource types affect results.
• Define ranking policy. Decide whether safety, cost, speed, vendor status, freshness, or business-unit ownership wins when multiple resources match.
• Separate search from permission. Discovery should never imply access. Authorization belongs at invocation time.
• Measure context savings. Compare hardcoded tool bundles against runtime discovery for token use, error rate, and task success.
• Audit stale entries. Treat catalogs like production infrastructure with owners, review dates, and deprecation paths.

My base case is that ARD becomes important slowly, then suddenly. In 2026, it will look like a developer convenience and enterprise governance experiment. By 2027, if agent deployments keep multiplying, discovery will become one of the main control planes of AI work. The winners will be the companies that make resources findable without making them reckless.

The strategic lesson is simple. Agents are leaving the era of handcrafted integrations. They are entering the era of searchable capability networks. The company that owns the model can answer. The company that owns the runtime can execute. But the company that owns discovery decides what the agent even knows it can do.

In other news

OpenAI hires Gemini’s co-lead - Noam Shazeer, a Google vice president, Gemini co-lead, and Character.AI founder, is leaving to join OpenAI (Business Insider). The move lands less than two years after Google paid roughly $2.7 billion for a Character.AI technology license and leadership return, making elite model builders look more like strategic assets than employees.

Odyssey raises for world models - Odyssey raised a $310 million Series B at a $1.45 billion valuation, with Amazon, AMD Ventures, GV, and others participating in the round (TechCrunch). The funding keeps world models in the center of the robotics and video generation debate, where spatial prediction may matter more than chat fluency.

Pramaana funds verifiable AI - Pramaana Labs announced a $27 million seed round led by Khosla Ventures to bring formal verification techniques into high-stakes AI workflows (TechCrunch). The interesting signal is not the seed size alone; it is investor appetite for systems that make AI outputs provable instead of merely plausible.

Anthropic joins Frontier - Anthropic became the first pure AI startup to join Frontier’s carbon-removal coalition, contributing to a new $915 million funding tranche that brings total pledges to $1.8 billion (TechCrunch). The energy bargain around frontier AI is becoming part of the product narrative, not a sustainability appendix.