Agentic Resource Discovery (ARD) Changes How AI Finds Tools Online: What Businesses Should Do Now
Google, Microsoft, and others backed a draft open spec called Agentic Resource Discovery (ARD) to help AI agents discover and verify tools, APIs, and other agents at runtime. Here’s what changed, why it matters for SMEs and agencies, and how to prepare—without chasing hype.
AI is moving from “answering questions” to doing work—booking, buying, filing, configuring, and connecting to other software. That shift creates a new operational requirement: AI systems need reliable ways to discover and verify tools on the web.
A draft open specification called Agentic Resource Discovery (ARD), backed by a coalition that includes Google and Microsoft, aims to standardize how AI agents find tools, APIs, MCP servers, and even other agents at runtime. This is not a Google Search update—and it won’t change your rankings tomorrow. But it’s a strong signal about where the “machine-readable layer” of the web is headed and what businesses will be asked to publish next.
In this editorial, I’ll break down what ARD is, why it matters, what can go wrong, and what SMEs and agencies should do now—without wasting cycles on speculative work. I’ll also explain where AYSA.ai fits as an execution system for SEO/AEO/GEO: we monitor, prepare, ask for approval, and then execute accepted changes on your site.
Concise summary
- ARD is a draft open spec for how AI agents discover and verify “callable capabilities” (tools, APIs, MCP servers, agents) across the web.
- The key change is moving from pre-installed/pre-wired integrations to runtime discovery via machine-readable catalogs on publisher domains + registries that Crawl and index them.
- Most content sites don’t need to implement anything today—ARD targets tool publishers and platforms more than traditional publishers.
- But the strategic direction matters: discovery, identity, and trust metadata may become go-to-market requirements for software-enabled businesses.
- Practical preparation for SMEs is still largely “classic” AEO/GEO/technical hygiene: clean catalogs of offerings, Structured data, governance, Monitoring, and an execution workflow that doesn’t break your site.
Key takeaways (my POV)
- ARD is more “App Store plumbing” than “SEO tactic.” It’s infrastructure for agents, not a new content trick.
- Don’t confuse agent discovery with human search. For now, Google Search isn’t using ARD, and ARD isn’t a Ranking factor.
- The winners won’t be the loudest marketers. They’ll be the most verifiable: clear ownership, clear permissions, clear capability metadata.
- Execution will matter more than strategy decks. If the ecosystem shifts, the businesses that can ship changes safely (with governance) will outperform those who just “talk AI.”
Table of contents
- What ARD is (and what it isn’t)
- What changed: from “pre-wired tools” to runtime discovery
- How ARD works: catalogs, registries, verification
- Why this is happening now (context for the agentic web)
- Who should care most (and who shouldn’t)
- The business impact: discovery is becoming a competitive surface
- What can go wrong: security, spam, governance, and “registry power”
- A concrete SME scenario: when agents start choosing tools for you
- What agencies should rethink: from pages to capabilities
- An SME-ready action plan (90 days) to prepare without wasting time
- Where AYSA.ai fits: monitor → prepare → approve → execute
- What to do next (checklist)
- Sources and further reading
What ARD is (and what it isn’t)
Agentic Resource Discovery (ARD) is a draft, open specification describing how AI agents can discover and verify online resources they can call: tools, skills, APIs, MCP servers, and other agents. The idea is to avoid a future where every agent needs to be manually configured with every possible integration upfront.
According to reporting by Search Engine Journal, the draft spec was published by a coalition including Google, Microsoft, GitHub, and others, with reference implementations released at the same time. ARD is described as Apache 2.0 licensed and built on an “AI Catalog” data model maintained in a Linux Foundation working group context. (That last detail is important: it suggests the intent is broad ecosystem adoption, not a single-vendor feature.)
What ARD is not:
- Not a Google Search feature (at least as described in the source). You shouldn’t expect “publish ARD → rank higher.”
- Not a content optimization standard like schema markup or page experience signals. It targets callable capabilities.
- Not something most SMEs must implement today unless they publish tools or APIs meant to be used by other software.
If you’re a typical local business, ecommerce store, or B2B service provider, ARD won’t be your highest ROI task this quarter. But ignoring it entirely would miss a bigger strategic trend: the web is being re-indexed for machines that take actions, not just for humans who read pages.
What changed: from “pre-wired tools” to runtime discovery
To understand why ARD exists, think about how software integrations work today.
The pre-wiring problem
Most “agent” experiences right now are built like this:
- A product team chooses a fixed set of tools (APIs, plugins, MCP servers).
- Developers integrate them, map permissions, and maintain them.
- Users get a curated list of actions the agent can perform.
This works—until it doesn’t. The moment a business wants an agent to use many specialized tools across industries and geographies, the integration work explodes. Each new tool adds onboarding, authentication, governance reviews, security evaluation, and ongoing maintenance.
Runtime discovery as the new default
ARD’s promise is a shift in posture:
- Publishers describe what they offer in a machine-readable catalog file hosted on their domain.
- Registries crawl, index, and answer natural-language discovery queries from agents.
- Agents select a capability at runtime and then connect using the tool’s protocol.
In business terms: ARD aims to turn integrations into a discoverable marketplace layer—more dynamic, more scalable, and (hopefully) more governable.
How ARD works: catalogs, registries, verification
Based on the source summary and extracted text, ARD is built around two concepts: catalogs and registries.
1) Catalogs: “ai-catalog.json” on a well-known path
A publisher (an organization that offers tools, APIs, MCP servers, or agents) hosts an ai-catalog.json file at a well-known path on its own domain. This catalog lists the capabilities it makes available.
That detail matters because it echoes a familiar web pattern: prove control by publishing on your domain. It’s similar in spirit (not function) to verification via DNS or hosting specific files for ownership validation.
2) Registries: crawl, index, and answer agent discovery requests
Registries crawl those catalogs, index them, and then answer discovery requests from agents in plain language. This is the “search layer,” but not necessarily a public search engine in the consumer sense.
In practice, you can imagine multiple registries:
- Enterprise registries (internal-only, governed)
- Industry registries (healthcare tools, ecommerce tools, dev tools)
- General registries (broad coverage)
3) Verification and trust metadata
ARD uses domain ownership as a baseline verification: if the catalog is on your domain, you likely published it. For production, publishers can attach trust metadata so an agent/registry can confirm cryptographic identity before connecting.
This is where the real business stakes live. Not in the JSON file itself—but in the trust and governance model around it.
4) The handoff: ARD discovers; the tool’s protocol executes
Once a capability is selected, ARD hands off and the agent connects directly using the tool’s own protocol. That means ARD is not trying to replace existing API standards; it’s aiming to standardize discovery and verification.
Why this is happening now (context for the agentic web)
ARD didn’t appear out of nowhere. It’s part of a pattern: the web is being augmented with structured, machine-usable layers designed specifically for AI systems.
The Search Engine Journal coverage notes that Google published the Open Knowledge Format shortly before ARD, and frames ARD as another step in “open specs aimed at the machine-readable layer of the web.” (I’m intentionally not adding details about Open Knowledge Format beyond what’s in the provided context; if you’re considering it, use the official Google documentation directly.)
Zoom out and the direction is consistent:
- Humans read pages.
- Crawlers index pages.
- Agents need to discover capabilities, verify identity, request permissions, and then act.
That last bullet is the key. Agents aren’t just “new search boxes.” They’re workflow engines. Which means they need a supply chain: catalogs, registries, trust, governance, permissions, and logs.
Who should care most (and who shouldn’t)
One of the most important lines in the source coverage is the practical boundary: ARD mainly affects companies that publish tools and agents, not typical content sites “for now.”
You should care a lot if you are:
- A SaaS company with an API that you want agents to call.
- An ecommerce platform offering programmatic catalog, inventory, pricing, or fulfillment endpoints.
- A marketplace or aggregator exposing partner capabilities.
- An enterprise building internal agents that must safely discover internal tools.
- A developer platform or tooling provider competing on integration reach.
You can mostly watch from the sidelines (for now) if you are:
- A local business whose “capabilities” are still primarily human-delivered (clinic, hotel, trades, restaurant).
- A content publisher whose value is editorial content, not callable APIs.
- A small ecommerce shop without a platform-level API strategy.
But “watch from the sidelines” doesn’t mean “do nothing.” It means: prepare your fundamentals, monitor the ecosystem, and avoid premature technical debt.
The business impact: discovery is becoming a competitive surface
Search changed business because it made discovery scalable: people could find products and services without knowing you existed.
Agentic discovery is similar—but the unit of value is different.
From pages to actions
Classic SEO rewarded pages that best matched queries. Agentic systems will increasingly reward providers that best match tasks:
- “Book a last-minute hotel within policy.”
- “Reorder supplies under $X.”
- “Pull performance by location and flag anomalies.”
- “File a warranty claim and schedule pickup.”
To perform tasks, agents need trustworthy endpoints. That’s why ARD focuses on callable resources: it’s essentially “SEO for capabilities” (with a major caveat: discovery may be mediated by registries, not open web search).
Your competitive set may widen
In traditional search, your competitors were mostly “other companies ranking for the same keyword.” In an agentic world, your competitor can be:
- a software vendor with tighter governance metadata,
- a platform with better discovery presence in registries,
- or a provider whose tool is simply easier/safer to connect.
This is why I’m paying attention: the winners may be chosen by a chain of machine decisions long before a human ever sees a webpage.
What can go wrong: security, spam, governance, and “registry power”
Any discovery system that becomes widely used becomes a target. If ARD adoption grows, expect familiar problems—just shifted from web pages to capability catalogs.
1) Spam and impersonation attempts
If registries crawl catalogs, bad actors will try to publish misleading capabilities. The spec’s reliance on domain ownership helps, but doesn’t eliminate risk (domains can be compromised, typosquatted, or misconfigured).
2) Trust metadata burden becomes a barrier to entry
Cryptographic identity verification is good for safety, but it can become a barrier for SMEs if the tooling is complex or expensive. If the “trusted catalog” path becomes mandatory for top registries, smaller vendors may struggle—similar to how app store policies and compliance requirements shape markets.
3) Permissions and governance become the bottleneck
The more powerful agents get, the more dangerous “one-click connect” becomes. Enterprises will demand policy controls, audit logs, and approval gates. Search Engine Journal’s coverage notes that Google’s role includes an Agent Registry in Gemini Enterprise Agent Platform, with enterprise governance as part of the value proposition (support planned for coming months, per the source).
That’s a clue: governance is not an afterthought. It’s the product.
4) Registry power and “ranking” dynamics
Even if ARD is open, registries will make choices:
- Which catalogs to crawl
- How frequently to refresh
- How to filter low-quality or risky capabilities
- How to rank results for an agent’s natural-language request
That starts to look like search—except now the “SERP” is an API response that can trigger actions. This is a new kind of gatekeeping risk, and businesses should be realistic about it.
5) The caution: specs don’t automatically create differentiation
The source coverage highlights an ongoing debate: Google’s John Mueller has previously argued that LLM systems can’t use files like llms.txt to distinguish one site from another, advising focus on current needs rather than future strategies. While ARD is different in purpose (tools and agents, not content), the principle holds: publishing a file alone rarely creates a moat.
What creates differentiation is adoption, governance, and user outcomes—plus how ecosystems actually route demand.
A concrete SME scenario: when agents start choosing tools for you
Let’s make this real with a scenario that a non-SEO business owner can understand.
Scenario: a multi-location clinic operator
Imagine a regional clinic group with five locations. Today, their marketing stack might include:
- a scheduling platform,
- a CRM,
- call tracking,
- reputation management,
- and analytics.
They’re also experimenting with an internal AI assistant to:
- summarize daily appointment fill rates,
- recommend which locations need promotion,
- and propose budget shifts.
Where discovery fits
As soon as that assistant needs to “do” something (pull a report, create an ad experiment, update a location page), it must connect to tools. Without a discovery layer, every connection requires manual wiring and ongoing maintenance.
With an ARD-like approach, the clinic’s IT/ops team could enforce a governed registry for approved tools. The assistant could request: “Find a reporting capability that can fetch appointment fill rate by location” and the registry could return a safe, vetted tool endpoint.
Notice what changes: visibility is no longer just “ranking for orthodontist near me.” Visibility becomes “being the capability the agent is allowed to use.”
What this means for SMEs even if they never publish a tool
Even if the clinic never publishes a tool catalog, they still need to operate in a world where:
- software choices are increasingly mediated by AI copilots and agents,
- governance and permissioning become central,
- and web presence must be structured and reliable for machines.
That’s why I keep pulling the conversation back to fundamentals + execution. The businesses that win won’t be the ones who “implemented ARD” first—they’ll be the ones who can safely adapt as standards settle.
What agencies should rethink: from pages to capabilities
Agencies (and in-house SEO teams) are being pushed into a broader role: not just content and links, but machine-readability and operational integration.
1) New deliverables: inventories, catalogs, and governance
In the ARD direction of travel, the deliverable isn’t just a content plan. It’s:
- a capability inventory (what can be done programmatically),
- documentation and endpoints,
- ownership and verification,
- and change control.
This starts to overlap with product marketing, developer relations, and security. Agencies that can operate cross-functionally will have an advantage.
2) Measurement changes: from clicks to completions
Traditional SEO reporting focuses on impressions, clicks, rankings, and traffic. Agentic systems may shift value toward:
- task completion rates,
- agent-mediated referrals,
- API usage,
- and assisted conversions.
I’m not claiming those metrics are standardized today—they aren’t in the provided context. I’m saying agencies should be ready for a world where “traffic” is an incomplete success measure.
3) The execution gap becomes the agency killer
Most organizations don’t fail because they lack ideas. They fail because execution is slow, risky, or blocked.
If the agentic web adds new files, schemas, endpoints, verification steps, and governance policies, the teams that can implement safely—without breaking analytics, indexing, or conversion flows—will win.
That is exactly why we built AYSA as an approved execution system: strategy is cheap; shipping is hard.
An SME-ready action plan (90 days) to prepare without wasting time
You don’t need to “implement ARD” to be ready for the direction ARD implies. Most SMEs should focus on a practical plan that strengthens your machine-readability and operational safety.
Days 0–30: Stabilize your foundation (technical + tracking)
- Make sure your analytics and conversions are trustworthy. If you can’t measure leads/sales reliably, you won’t detect agent-driven changes later.
- Audit critical templates. Product pages, location pages, service pages—make them consistent and crawlable.
- Reduce accidental complexity. Too many plugins, broken redirects, duplicated pages, and inconsistent canonicalization create machine confusion.
- Set up monitoring. You need ongoing visibility into what changed and what broke. (This is where AYSA Monitoring is designed to help.)
Days 31–60: Improve “machine-usable” clarity (AEO/GEO basics)
- Clarify your offerings. Be explicit about services, coverage areas, SKUs, policies, shipping/returns, appointment rules—things agents need to execute tasks.
- Structured data where it makes sense. Not as a hack, but as operational truth: products, organization, local business info, FAQs where appropriate.
- Build authoritative support content. Agents and AI answers rely on clear, consistent sources. Create pages that reduce ambiguity (pricing ranges, process, eligibility, specs).
- Unify NAP/location consistency. For multi-location businesses, inconsistency is poison for both humans and machines.
If you want a broader framework for this, start with AI Search Visibility and the execution playbooks under AYSA’s AI SEO tools.
Days 61–90: Operationalize governance + execution
- Create an “AI change policy.” Who can publish new pages? Who can push template changes? Who approves structured data changes? Who owns verification files?
- Define your “source of truth.” A single place where your offerings, pricing rules, and availability are maintained, so your site doesn’t drift.
- Speed up safe shipping. The companies that can ship improvements weekly (with guardrails) will beat the ones that ship quarterly (with chaos).
This is the core AYSA operating model: we monitor, propose improvements, request approval, and then execute accepted changes—reducing the risk that “AI-driven optimization” breaks your site or your measurement.
Where AYSA.ai fits: monitor → prepare → approve → execute
ARD is a tool-discovery spec. AYSA is not an ARD registry, and we’re not here to sell you speculative implementation work that doesn’t apply to your business. Our role is more practical: help you win in AI-mediated discovery (AEO/GEO/AI Search) by making your web presence clear, trustworthy, and operationally maintainable.
1) Monitor what changes (before it hurts)
New standards create new kinds of breakage: missing files, misconfigured endpoints, unintended noindex, template regressions, tracking drift. Ongoing monitoring is how you stay ahead. Start here: AYSA Monitoring.
2) Prepare improvements aligned to outcomes
We focus on changes that improve real business outcomes: qualified leads, sales, bookings—plus visibility across AI answers and search experiences. See the approach: AI Search Visibility.
3) Ask for approval (governance by default)
Agentic systems raise the cost of mistakes. The “approved execution” model matters because it keeps changes intentional, reviewable, and accountable—especially when multiple stakeholders (marketing, IT, legal) are involved.
4) Execute accepted website changes (the hard part)
Most businesses don’t need more audits. They need changes shipped. AYSA is built to execute—cleanly and safely—so your site becomes more machine-usable without breaking what already works.
If you want to explore whether AYSA is a fit, pricing is transparent: AYSA Pricing. For more editorials like this, see AYSA Blog.
What to do next (checklist)
- If you publish tools/APIs: assign an owner to track ARD’s evolution and evaluate whether you should publish an ARD catalog once the ecosystem matures.
- If you don’t publish tools: don’t chase ARD implementation—focus on site clarity, structured data where appropriate, and governance.
- Set monitoring baselines: know what “normal” looks like for traffic, conversions, and indexing so you can detect shifts.
- Strengthen trust signals: clear policies, contact info, entity consistency, and authoritative pages that reduce ambiguity for AI systems.
- Build an execution cadence: ship improvements weekly or biweekly with approvals—avoid big-bang redesigns.
- Educate your team: make sure marketing and IT share a vocabulary: discovery, verification, governance, permissions.
Sources and further reading
- Search Engine Journal: Google, Microsoft Back Draft AI Agent Discovery Spec (primary research input for this editorial)
- Search Engine Journal: Latest news (context and ongoing coverage)
- Search Engine Journal: SEO section (related reporting on AI and search)
- AYSA.ai: AI SEO tools
- AYSA.ai: AI search visibility
- AYSA.ai: Monitoring
- AYSA.ai: Pricing
- AYSA.ai: Blog
Note on primary sources: The provided research context references the ARD draft spec and related implementations, but does not include direct links to the spec repository or vendor documentation. Where you need implementation-level accuracy (paths, fields, cryptographic identity formats), use the official spec repository and vendor docs directly and treat this editorial as strategic guidance, not a technical standard.
Continue the AI search topic inside AYSA.
Use these pages to connect the article with AI SEO tools, AI visibility monitoring, AI Overviews and approved website execution.
Turn this topic into a website action plan.
Use these AYSA hubs to move from reading to technical fixes, AI visibility monitoring, research, glossary context and approval-first SEO execution.
