Agent Cards Explained: How AI Agents Discover Other Agents

The agent ecosystem has a discovery problem, and it’s not the one most teams expect. MCP’s runaway success—97 million monthly SDK downloads as of March 2026—solved the tool-connectivity layer so well that it created the next bottleneck: how does an agent find the right agent, tool, or skill at runtime without someone hardcoding every connection? That’s the gap Agent Cards and the emerging discovery infrastructure are designed to fill.

Agent Cards Are the Identity Primitive the Agent Stack Was Missing

An A2A Agent Card is a machine-readable JSON document served at the well-known URL path /.well-known/agent-card.json (following RFC 8615), declaring an agent’s identity, capabilities, communication requirements, and authentication needs. Think of it as a business card that another agent can fetch, parse, and act on—no prior relationship required.

The A2A protocol uses Agent Cards as its core capability discovery primitive: client agents fetch and parse remote Agent Cards to determine if a remote agent can handle a delegated task before establishing a connection. This is the mechanism that makes cross-vendor agent orchestration possible without custom integration code between every agent pair.

What makes the design notable is where the description lives. The card puts the capability metadata on the agent’s own host, at a predictable path, rather than in some caller-side configuration store. When an agent moves or rehosts, callers follow. The single source of truth is the thing being described. That’s a meaningful architectural choice—it’s the same pattern that made security.txt, openid-configuration, and change-password work at scale.

Three Discovery Strategies, From Public to Private

A2A defines three standard discovery strategies, and the choice between them maps directly to your deployment model.

1. Well-Known URI — Host the Agent Card at /.well-known/agent-card.json on your domain. This is the default for public or internet-reachable agents. Any client that knows your domain can discover your agent without prior coordination.

2. Curated Registries — A central catalog service indexes Agent Cards by capability and skill. Clients query the catalog instead of crawling domains. This is the standard pattern for enterprise deployments where you want governance and policy enforcement over which agents are discoverable.

3. Direct Configuration / Private Discovery — Hardcoded URLs in config files. Suited to tightly coupled internal systems where you don’t need dynamic discovery at all.

The spec’s flexibility here matters. Not every agent needs to be publicly discoverable. A tightly coupled internal pipeline with two agents that always talk to each other doesn’t need a registry—it needs a URL in a config file. The spec accommodates that without forcing you into unnecessary infrastructure.

The Discovery Layer Is Fragmenting Into Competing Systems

Here’s where it gets complicated. A2A Agent Cards aren’t the only discovery game in town, and the landscape is fragmenting fast. The Agentic Resource Discovery (ARD) specification, published June 17, 2026 by Google and 11 industry partners (Microsoft, GitHub, Hugging Face, NVIDIA, Cisco, Databricks, GoDaddy, Salesforce, ServiceNow, Snowflake) under Apache 2.0 license, is an open standard for runtime discovery and verification of AI capabilities—tools, MCP servers, A2A agents, APIs—across organizational boundaries.

ARD relies on two core primitives. Catalogs (ai-catalog.json files hosted at a well-known path on an organization’s own domain) list available capabilities, with domain ownership serving as the cryptographic foundation for publisher identity and trust. Registries act as search engines for the agentic web—they crawl published catalogs, index contents, and return ranked, verified matches to natural-language discovery queries from agents.

The critical framing: ARD is explicitly designed as a complementary pre-invocation discovery layer, not a replacement for MCP, A2A, or Agent Skills. It discovers the correct capability, which is then invoked via its native protocol. That distinction matters because it means ARD sits above the protocol layer, indexing across MCP servers, A2A agents, and OpenAPI tools through a single query interface.

But ARD isn’t alone. The Linux Foundation launched the DNS-AID open source project in May 2026, a vendor-neutral decentralized alternative to centralized agent registries that uses existing DNS infrastructure for AI agent and MCP server discovery, with initial members including Cloudflare, Infoblox, and GoDaddy. Visa launched an Agentic Directory of verified agents and merchants for commerce. Microsoft Entra Agent ID provides enterprise identity-gated discovery. The MCP vs A2A piece covers how these protocols complement each other at different layers.

Trust Is the Harder Problem Than Discovery

Discovery without trust is just a directory. And trust is where the competing approaches diverge most sharply.

ARD and A2A use domain ownership and DNS as the cryptographic foundation for identity—control of a domain is treated as sufficient proof of publisher authority. Signed Agent Cards, introduced in A2A v0.3 and made load-bearing in v1.0, add a cryptographic trust layer that enables agents to verify a publisher’s identity before establishing a connection.

But institutional verification tells a different story. Visa’s Agent Score and Okta’s Agent Connections rely on institutional verification, behavioral scoring, and established identity providers rather than self-asserted domain ownership. Okta’s Agent-to-Agent Connections capability lets organizations define per-agent connection policies, which upstream services and agents can invoke an agent, agent scope, and session duration—governance primitives that pure domain-based trust doesn’t address.

The tension is structural: domain-based trust is open and self-service, which makes it easy to adopt but hard to govern at enterprise scale. Institutional trust is gated and auditable, which makes it enterprise-ready but introduces dependency on identity providers that may not be neutral. For teams operating across organizational boundaries, the AGENTS.md standard provides a complementary approach to agent configuration that’s worth understanding alongside the protocol layer.

What This Means for Your Architecture

The practical takeaway isn’t that you need to pick one discovery system—it’s that you need to understand which layer of the stack each system operates at.

Discovery System	Layer	Trust Model	Best For
A2A Agent Cards	Protocol (A2A)	Domain ownership + signatures	Agent-to-agent task delegation
ARD Catalogs	Above protocols	Domain ownership + trust metadata	Cross-org capability discovery
DNS-AID	Infrastructure (DNS)	DNS-based, decentralized	Scalable public discovery
Visa Agentic Directory	Application (commerce)	Institutional verification	Commerce agent trust
Okta Agent Connections	Identity (IAM)	Enterprise IdP	Governed enterprise multi-agent
MCP Registry	Protocol (MCP)	Varies by implementation	Tool and data source discovery

If you’re building agents that need to discover and delegate to other agents across organizational boundaries, start with Agent Cards as the baseline identity primitive. They’re the most widely adopted, they’re protocol-native, and they’re the foundation that other discovery systems build on top of.

If you’re operating at enterprise scale with compliance requirements, layer identity-gated discovery on top—don’t rely on domain ownership alone. The teams that get this right will be the ones that treat discovery and trust as separate problems with separate solutions, not as a single feature to check off.

The open question is whether the ecosystem converges on ARD as the universal pre-invocation layer, or whether discovery fragments permanently along protocol, identity, and application boundaries. The smart bet is on fragmentation—and on building agents that can speak multiple discovery protocols depending on context.