On June 17, 2026, Google and ten industry partners — Microsoft, Hugging Face, Cisco, Nvidia, Salesforce, Snowflake, GitHub, ServiceNow, Databricks, and GoDaddy — quietly published a spec that could change how every internal platform gets consumed by AI agents.

It’s called Agentic Resource Discovery (ARD). If you haven’t heard of it yet, you will. And as a Tech Lead, you have a decision to make sooner than you think.

The Problem ARD Solves

The standard model for integrating AI agents with services looks like this: a human developer reads docs, finds an MCP server or API, hardcodes it into an agent configuration, and ships. Repeat for every new tool, every new agent.

This worked fine when there were a handful of tools. It breaks when every company, every product team, and every developer can publish an MCP server or skill. At that scale, hardcoded integrations don’t scale — you need runtime discovery.

The analogy is DNS. Before DNS, you manually maintained a list of host addresses. DNS made discovery automatic. ARD is trying to do the same thing for AI tools.

ARD defines two primitives:

  1. ai-catalog.json — a machine-readable manifest your organization hosts at /.well-known/ai-catalog.json, listing available capabilities
  2. Registry API — federated registries that crawl, index, and search those manifests based on natural-language task intent

How It Works: The Discovery Lifecycle

Agent needs a capability
        ↓
Query ARD Registry (natural language: "send email with attachment")
        ↓
Registry returns ranked matches + trust metadata
        ↓
Agent verifies publisher identity (domain-based trust)
        ↓
Agent connects via native protocol (MCP, A2A, OpenAPI)
        ↓
Task executes

The key insight: ARD is not a new invocation protocol. It sits before MCP, before A2A, before OpenAPI. It answers the question “which tool should I use?” — not “how do I use it?”

If MCP is the USB-C port, ARD is the search engine that tells the agent which port to plug into.

The ai-catalog.json Structure

The manifest lives at /.well-known/ai-catalog.json — following RFC 8615 well-known URI conventions. A minimal example:

{
  "$schema": "https://agenticresourcediscovery.org/schemas/v0.9/ai-catalog.schema.json",
  "publisher": {
    "name": "Acme Corp",
    "domain": "acme.com",
    "contact": "platform@acme.com"
  },
  "capabilities": [
    {
      "id": "urn:ai:acme:platform:order-service",
      "type": "application/mcp-server+json",
      "name": "Order Management Service",
      "description": "Create, update, query, and cancel customer orders. Supports batch operations and webhook notifications.",
      "tags": ["orders", "ecommerce", "fulfillment"],
      "url": "https://platform.acme.com/mcp/orders",
      "trust": {
        "level": "verified",
        "certUrl": "https://acme.com/.well-known/ard-trust.json"
      }
    },
    {
      "id": "urn:ai:acme:platform:inventory-api",
      "type": "application/openapi+json",
      "name": "Inventory Query API",
      "description": "Real-time stock levels, SKU lookup, warehouse availability by location.",
      "tags": ["inventory", "stock", "warehouse"],
      "url": "https://api.acme.com/inventory/openapi.json"
    }
  ]
}

Key design decisions in the schema:

  • Artifact-agnostic envelopes — the type field is an IANA media type. ARD doesn’t redefine MCP or OpenAPI schemas; it just references them
  • URN-based identifiers — urn:ai:<publisher>:<namespace>:<name> ensures uniqueness across federated registries
  • Domain-based trust — since the manifest lives on your domain, domain ownership implies publisher identity. No central authority needed
  • Tag-based discoverability — agents and registries use these tags alongside the description for semantic search

ARD vs. MCP: Not Competitors

A common confusion I’ve seen in team discussions: “Do we need ARD or MCP?”

Both. They solve different problems at different stages.

ConcernMCPARD
WhenInvocation timeDiscovery time (before invocation)
Question answered”How do I call this tool?""Which tool should I use?”
What it definesRequest/response protocol, tool schemasManifest format, registry API, trust signals
AnalogyUSB-C port standardUSB device search / device manager

Think of it as a pipeline:

ARD Registry → discover tool
     ↓
MCP / A2A / OpenAPI → invoke tool
     ↓
Agent → use result

You need both layers. ARD makes discovery possible at scale; MCP (or A2A) makes invocation reliable.

What GitHub Is Doing With This

GitHub announced Agent Finder built on ARD — a capability within GitHub Copilot that lets agents dynamically discover and call the right MCP servers, skills, tools, and agents for a task at runtime, without the developer pre-installing anything.

The implication: if your internal services publish an ai-catalog.json, GitHub Copilot agents could discover and use them automatically. No manual integration required.

That’s a significant shift in how platform teams think about their services.

Practical Implications for Tech Leads

1. Start thinking about your services as agent-consumable assets

Every internal service your team owns is a potential agent resource. The question is no longer just “does it have a good REST API?” but “can an agent find it, understand what it does, and decide to use it?”

This means descriptions matter more than ever. The description field in your ai-catalog.json entry is what agents use for semantic matching. Vague descriptions = poor discoverability.

2. Create a platform ai-catalog.json now

This is low-effort, high-value work you can do today. Even without ARD registries deployed internally, publishing the manifest positions your platform for the moment your organization starts deploying ARD-aware agents.

Steps:

  1. Inventory your team’s services: MCP servers, REST APIs, internal tools
  2. Write the manifest at /.well-known/ai-catalog.json for your domain
  3. Add meaningful tags and descriptions to each entry
  4. Optionally submit to public ARD registries if services are external-facing

3. Treat discoverability as a first-class concern in API design

When writing an OpenAPI spec or MCP tool definition, ask:

  • “If an agent searched for this by describing what it needs in natural language, would it find this service?”
  • “Is the name and description specific enough that the agent wouldn’t confuse it with a different service?”
  • “Does the tag list include the terms agents are likely to search for?”

This is the semantic SEO for your APIs.

4. Plan your internal registry strategy

ARD supports federated registries — you can run a private registry that only indexes your internal services, without exposing them to public registries. For enterprises with internal platforms, this is likely the architecture you’ll want:

Internal ARD Registry
    ├── Indexes company-internal ai-catalog.json manifests
    ├── Only accessible within corporate network / VPN
    └── Feeds into internal agent orchestration platforms

Public ARD Registry (e.g., Hugging Face, GitHub)
    ├── Indexes public-facing services
    └── Accessible to GitHub Copilot, third-party agents

5. Add trust metadata for production use

The spec supports cryptographic trust signals. For internal production use, you’ll want to define:

  • Who is authorized to publish capabilities under your domain
  • Which registries are trusted by your agents
  • How trust signals are validated before an agent connects to a new tool

Without this layer, you’re vulnerable to catalog poisoning — a malicious actor publishing a fake catalog that impersonates your services.

Code Example: Annotating an Existing ASP.NET API for ARD

If you’re running .NET services (as many teams I work with do), here’s how to approach making them ARD-discoverable:

Step 1: Add a well-known endpoint

// Program.cs
app.MapGet("/.well-known/ai-catalog.json", () =>
{
    return Results.Json(new
    {
        schema = "https://agenticresourcediscovery.org/schemas/v0.9/ai-catalog.schema.json",
        publisher = new
        {
            name = "MyCompany Platform",
            domain = "platform.mycompany.com"
        },
        capabilities = new[]
        {
            new
            {
                id = "urn:ai:mycompany:platform:customer-service",
                type = "application/openapi+json",
                name = "Customer Data Service",
                description = "Query and update customer profiles, subscription status, and purchase history. Supports filtering by date range, customer segment, and region.",
                tags = new[] { "customers", "profiles", "subscriptions", "purchase-history" },
                url = "https://platform.mycompany.com/customers/openapi.json"
            }
        }
    });
});

Step 2: Write better OpenAPI descriptions

[HttpGet("{customerId}/orders")]
[EndpointSummary("Get customer order history")]
[EndpointDescription(
    "Returns paginated order history for a customer including order status, " +
    "line items, fulfillment tracking, and refund status. " +
    "Use when an agent needs to look up what a specific customer has purchased " +
    "or check the status of recent orders.")]
public async Task<IActionResult> GetCustomerOrders(string customerId, ...)

The description in your OpenAPI spec flows directly into how agents understand your tools — both via ARD discovery and once they’re using the tool.

The Bigger Picture: The Agentic Web

ARD represents a philosophical shift worth naming: the web is being restructured for agents, not just humans.

The robots.txt / sitemap.xml pattern — well-known files that tell crawlers how to interact with your site — is the model ARD follows. But instead of telling Google’s crawler what pages exist, you’re telling AI agents what capabilities exist.

The llms.txt convention emerged in 2025 to help LLMs understand what’s on your site. ai-catalog.json is the next layer: what your site can do.

As a Tech Lead, this is not something you can defer indefinitely. When your organization starts deploying AI agents that use ARD registries — and that timeline is measured in months, not years — the teams that have their catalogs published will have their services used. The ones that haven’t will be invisible.

Summary: What to Do This Week

ActionEffortValue
Publish /.well-known/ai-catalog.json for your servicesLow (hours)High
Audit existing API descriptions for agent-discoverabilityMedium (1-2 days)High
Set up internal ARD registryMedium-HighHigh
Add trust metadata and signingHighCritical for production

ARD v0.9 is a draft spec. It will evolve. But the core pattern — a manifest at a well-known path, indexed by federated registries, queried by agents at runtime — is sound and has enough industry backing that betting against it seems unwise.

Publish your catalog. Write better descriptions. Make your services visible to the next layer of the stack.

ARD specification (v0.9): agenticresourcediscovery.org — Apache 2.0 license InfoQ announcement: Google and Industry Partners Announce ARD GitHub Agent Finder: commandline.microsoft.com

Export for reading

Comments