Agent Resource Discovery(ARD) - A framework to discover Agentic resources in the world of AI

How we used to find things

Before the internet, if you needed a plumber, you didn’t personally know every plumber in town. Then Yellow pages happened, where the Plumbers listed themselves there: name, number, specialization, service area. You found one, called them. Done.

With Yellow pages, you didn’t need prior knowledge. The directory sat between “I need a plumber” and “here’s one.”

Without it? You’d have to already know someone, or drive around looking for signs.

Then Google came along and made it better. You search plumber near me and get results ranked by relevance. Each result has ratings from past customers, reviews describing their experience, and trust signals like verified business badges. You don’t just find a plumber. You find the best plumber for your situation, backed by evidence from people who’ve used them before.

That progression, from knowing someone personally, to a static directory, to ranked search with trust signals, is the same path agents need to travel. Most agent systems today haven’t even reached the Yellow Pages stage. Every connection is still someone’s number saved in a config file.

Agents have the same gap

Right now, when an orchestrator agent needs a specialist (one that processes invoices, or searches medical literature, or books flights) it has to already know who to call. The endpoint is hardcoded in config. Someone put it there at build time.

This means:

• A better specialist shows up? Nobody knows unless a human notices and redeploys.
• A partner launches a new capability? Your orchestrator won’t find it on its own.
• The current specialist goes down or changes URLs? Things break quietly.

Every agent-to-agent connection today is like having a plumber’s number saved in your phone. Fine, as long as that plumber stays in business and you never need a different one.

So, What’s missing

There’s no standard way for an agent to say “I exist, here’s what I do, here’s how to reach me.” And no standard way for another agent to search for that at runtime.

Organizations build agents. Other organizations need those agents. But there’s no directory connecting them.

ARD fills the gap

Agentic Resource Discovery (ARD) is a specification from Google, Microsoft, and Hugging Face. It defines three things:

Catalog. Each organization publishes a JSON file at /.well-known/ai-catalog.json on their domain. Lists their agents with identity (a domain-anchored URN), capabilities, how to reach them, and trust signals. This is the Yellow Pages listing. The publisher owns it and updates it on their own schedule.

Registry. A service that crawls catalogs from multiple organizations, indexes the entries, and exposes a search endpoint. You POST a query (“find me an agent that processes invoices”) and get back ranked results with scores. This is the directory company that collects all the listings and lets you search.

Resolution. The top search result points to an Agent Card, basically a business card with the endpoint and auth info. You fetch it, confirm it matches what you need, and invoke the agent.

What this changes

Without ARD,

• adding a new agent to your ecosystem is a code change.
• you pick a specialist at deploy time and hope it’s the right choice indefinitely.
• trust is “someone gave me this URL.”

With ARD,

• it’s a catalog update. The orchestrator finds it next time it searches.
• the orchestrator evaluates options at runtime based on relevance.
• identity is anchored to a domain. You know who published it.

When discovery doesn’t apply

You wouldn’t search the Yellow Pages to call your colleague sitting two desks away. You know them. You have their number.

Agents work the same way. If you built it, you deployed it, it’s running in your account, you already know where it is. Just call it. No search needed.

Discovery matters when you’re reaching outside your own boundary. A partner’s agent. A third-party service. Something that showed up last week on a domain you’ve never interacted with. That’s where ARD earns its keep.

In practice, most systems will have both: agents you call directly because they’re yours, and agents you discover because they’re not.

In short

Agents need a way to find each other across organizational lines without hardcoding. ARD gives them that: catalogs for advertising, registries for searching, resolution for connecting. A Yellow Pages for agents.

What’s next

In the upcoming posts, I’ll build this end-to-end in AWS. A three-agent system where an orchestrator discovers a partner’s specialist agents via ARD at runtime, invokes it over the A2A protocol, and also calls a local agent directly, showing both patterns in one working system.

The stack: Amazon Bedrock AgentCore for hosting agents, a serverless ARD registry on Lambda, and the A2A protocol for agent-to-agent communication.

The series will cover:

• Building an ARD-compliant registry and catalog on AWS (API Gateway + Lambda + S3)
• Deploying A2A agents on Bedrock AgentCore with Strands
• Wiring an orchestrator that discovers at runtime vs invokes directly