What Is Agentic Resource Discovery?
Agentic Resource Discovery (ARD) is an open specification for publishing, indexing, finding, and verifying agent-accessible resources — tools, skills, APIs, MCP servers, and other agents — so that an AI agent can locate a capability it needs and confirm the capability is genuine before using it. Google introduced the specification in its announcement of the Agentic Resource Discovery specification on the Google Developers Blog, framing it as shared infrastructure rather than a proprietary store.
The ARD specification has four moving parts:
- Catalogs. Organizations publish the resources they offer under domains they control, so the source of a capability is tied to an owner.
- Registries. Indexes that crawl and aggregate catalogs, making capabilities searchable for agents that do not already know where to look.
- Domain anchoring. Entries are signed and tied to an owned domain, so an agent can verify that a listing genuinely belongs to the party it claims to.
- Federation. Multiple registries coexist. There is no single marketplace and no central gatekeeper; discovery is distributed across the parties that choose to participate.
The cleanest way to read ARD is by analogy. DNS let machines resolve names to addresses; service discovery let distributed systems find each other without hard-coded endpoints. Agentic Resource Discovery is becoming the same kind of layer for agents: a federated, verifiable way to answer “what capabilities exist, and where?” at runtime instead of by manual configuration. That is a real and useful piece of infrastructure. It is also strictly a discovery layer.
ARD vs MCP vs A2A
ARD slots alongside two protocols that already define how agents act, and the cleanest way to keep them straight is by the question each one answers:
- ARD answers “Where is it?” — how an agent finds and verifies a capability.
- MCP (the Model Context Protocol) answers “How do I use the tool?” — the interface for invoking a discovered tool or server.
- A2A (Agent2Agent) answers “How do these agents communicate?” — the protocol for agents to exchange messages and delegate work.
Together these three cover finding, invoking, and coordinating. The question none of them answers is the one that decides outcomes: who decides whether the resulting action is allowed? A capability can be discoverable, verified, correctly invoked, and coordinated across agents, and still produce a change that violates a project’s architecture. Discovery and protocol are necessary plumbing. They are not a decision.
Discovery and Identity Are Necessary, Not Sufficient
A valid ARD catalog entry is a strong claim, and worth taking seriously. It proves a capability exists, that it is owned by the domain it is published under, that its metadata is unmodified, and that its endpoint is reachable. For supply-chain integrity that is genuine progress: it closes off impersonation and tampering, the way a signed package closes off a substituted binary.
It also stops exactly there. A verified entry cannot decide whether the tool fits this repository, whether using it conflicts with an architectural decision record, whether it introduces an unapproved dependency, whether the action crosses an architectural boundary the team has drawn, whether it sends sensitive code off-site, whether the change needs human approval, or whether it meets the project’s verification rules. Those are properties of the use, not of the capability. Identity tells you the tool is what it says it is. It says nothing about whether this agent should reach for it, here, now.
A trusted capability can still be used in an untrusted way. Verified identity authenticates the tool. It does not authorize the change that calling the tool produces.
Platform Governance vs Architectural Governance
Google is not naive about this, and it is worth being precise about what the platform layer does cover. Around ARD, an Agent Registry handles inventory, Agent Identity handles who is requesting, and an Agent Gateway handles access control, tool-call policy, and auditing. That is real platform governance, and most enterprises will need it. The distinction that matters is not platform governance versus nothing; it is platform governance versus architectural governance — whether the resulting change is compliant with how the system is supposed to be built.
| Layer | Question it answers | Where it lives |
|---|---|---|
| Discovery | What capabilities exist? | ARD catalogs and registries |
| Identity | Who is requesting? | Agent Identity |
| Access control | May it connect? | Agent Gateway |
| Tool-call policy | May it invoke this? | Agent Gateway |
| Architectural governance | Is the resulting change compliant? | Mneme |
| Verification | Is there evidence to accept it? | Mneme |
The platform handles the top four rows well. Discovery, identity, connection, and invocation policy are about whether an agent may reach a capability. The bottom two rows are about whether what the agent did with that capability is allowed to stand. A gateway can confirm an agent is permitted to call a code-generation tool; it cannot read the diff that tool produced and decide whether the diff respects the project’s boundaries. That is the layer governance infrastructure has to add, and it is where Mneme sits.
Why Dynamic Discovery Increases the Governance Requirement
Before ARD, an agent’s toolset was configured by hand. A platform team decided which tools an agent could see, wired them in, and reviewed that list as a static artifact. The set of things an agent could do was known in advance, which meant configuration itself was a form of governance: if a capability was not in the config, it could not be used.
Dynamic discovery changes that. Capabilities are found and added at runtime, the set expands while the agent is working, registries differ in what they expose, and agents select tools mid-reasoning based on the task in front of them. A capability can be authentic, verified, and entirely unsuitable for the change being made. The window where a human could have vetted the toolset has closed before the work starts.
The implication is direct. The more dynamically agents discover capabilities, the less static configuration can serve as the governance model. What a fixed allowlist used to provide has to move to where the action actually lands — the moment a change is produced. This is the case for runtime governance: governance that evaluates the actual change at the point of generation, not a list of permissions decided weeks earlier.
How Mneme Complements ARD
ARD and Mneme operate on different questions, which is exactly why they compose cleanly. Trace a single agent action through both:
- ARD exposes the capabilities an agent can discover and verify.
- The platform confirms identity and connectivity — the agent is who it claims and is allowed to connect.
- The coding agent uses a discovered capability to propose a change to the codebase.
- Mneme evaluates that change against the project’s recorded decisions and engineering rules — the architectural boundaries, approved dependencies, and patterns the team has committed to.
- Verification runs before the change is accepted, applying governance before generation is folded into the workflow rather than caught in retro review.
- The result is an auditable governance decision: accept, or reject with a reason tied to a specific rule.
The division of labor is clean. ARD helps agents discover what they can call. Mneme governs what their changes are allowed to become. Discovery widens the set of execution surfaces an agent can act through; governance keeps the changes those surfaces produce consistent with the system you meant to build. If you want to see that evaluation run against a real change, the live demo walks through a single agent edit, the decision, and the reason behind it.