A2A v1.0 defines exactly what an Agent Card looks like. It says nothing about how to find one. The specification — backed by 150+ supporting organizations and stewarded by the Agentic AI Foundation (AAIF), which has surpassed 170 total members across all its projects — explicitly states that “the current A2A specification does not prescribe a standard API for curated registries.”1 Every team building multi-agent pipelines in production is inventing that layer from scratch.
What A2A v1.0 Actually Specifies About Discovery (and What It Doesn’t)
The A2A specification defines the Agent Card schema: a structured JSON document describing an agent’s capabilities, authentication requirements, and endpoint URLs. What it does not define is any mechanism for finding, indexing, querying, or federating those cards across organizational boundaries.2
The gaps are not incidental. The agent-discovery documentation is explicit: the spec prescribes no standard API for curated registries1, and the governance documentation leaves approval-process details unspecified. This is a deliberate scoping decision: the working group standardized the format of agent advertisements without standardizing the infrastructure that makes those advertisements discoverable.
The analogy to DNS is useful but imprecise. DNS was designed as a distributed directory from the start; A2A has a directory format with no directory protocol. The consequence: an agent registered in one organization’s system is invisible to another’s unless both sides have independently agreed on a lookup mechanism.
The Governance Gap: Three Infrastructure Layers Every Team Must Build Themselves
Solo.io — which sells infrastructure products for this space, a context worth keeping in mind — identifies three components that every A2A production deployment must build independently3:
-
Agent Registry: an approved-agent catalog with onboarding workflows, skill attestation, and metadata indexing. A2A defines what goes in a card; the registry decides which cards are trusted, versioned, and searchable.
-
Agent Naming Service: a capability-based semantic search layer. Locating an agent by endpoint URL is different from querying “which agents can handle PCI-compliant invoice extraction” — the latter requires a naming service with a defined vocabulary, ranking logic, and availability state.
-
Agent Gateway: name resolution combined with policy enforcement and observability. When Agent A calls Agent B across an organizational boundary, something must resolve B’s identity, verify A’s authorization, apply rate limits, and log the exchange. A2A’s wire protocol carries the call; it specifies no layer to govern whether the call should happen.
The spec’s position on all three is consistent: they are “up to you.”3
MCP Dev Summit Evidence: The Registry Problem in Production
At the MCP Dev Summit North America, held in New York City on April 2–3, 2026, enterprise production deployments from Amazon, Uber, Duolingo, Nordstrom, and Bloomberg were all presented.4 The dominant architectural pattern documented across those deployments was: a curated server catalog, a central registry for discovery and compliance, and an MCP gateway for authentication, policy enforcement, and audit logging.4
Every major enterprise deployer independently built the registry layer that the standard does not specify.
This pattern is consistent with MCP’s broader trajectory. As of April 2026, MCP has reached 110M+ monthly SDK downloads.4 Adoption is accelerating regardless of governance gaps, which means proprietary registry implementations are proliferating faster than any eventual standard can rationalize them.
Why the AAIF’s Registry Roadmap Item Doesn’t Resolve This Yet
The A2A Protocol’s one-year anniversary press release, published in April 2026, lists “consolidation of efforts for registry” as a roadmap item.5 It provides no API designs, no delivery timeline, and no architectural decisions.
This vagueness reflects the genuine state of the working group’s thinking. GitHub Discussion #741, the active A2A Agent Registry proposal thread as of April 22, 2026, shows a community still debating foundational architecture: centralized versus decentralized federation (“Federation of Catalogs” vs. “Federation of Peers”), multi-tenancy namespacing, and search semantics. The working group is documented as still establishing “foundational decisions before finalizing API design.”6
To be precise about the membership figures: the AAIF has surpassed 170 total member organizations across all its projects, while A2A specifically counts 150+ supporting organizations.7 These are related but distinct figures. The governance body has institutional scale; its registry specification does not.
The practical implication: teams deploying A2A today will lock in registry architecture decisions months or years before a standard exists. By the time AAIF ships a concrete registry spec, most enterprises will have existing implementations to migrate — or won’t.
The Fragmentation Cost: Cross-Vendor Agent Authorization Across Org Boundaries
The registry problem is manageable inside a single organization. IT can maintain its own catalog, enforce its own approval workflow, and index its own agents. The cost materializes when agents cross organizational boundaries.
Consider an enterprise that wants to invoke a vendor’s specialized pricing agent from within its own orchestration pipeline. The two sides must bilaterally negotiate: which endpoint, which authentication scheme, which trust signal, which rate limit, which audit trail. None of that handshake is specified by the protocol. Every cross-org agent integration is a custom integration — the same situation that made pre-LSP IDE plugin ecosystems a maintenance burden for every editor vendor.
O’Reilly Radar frames this as systemic: A2A and related protocols have removed technical friction from agent communication while leaving governance friction entirely in place, creating “a new class of integration debt — one where organizations borrow speed today at the cost of accountability tomorrow.”8 The article calls for an “Agent Treaty” layer above the wire protocols — a governance specification meaningfully distinct from a wire-format standard.
What a Neutral Registry Layer Would Actually Need to Specify
The GitHub Discussion #741 thread surfaces the design questions that need answers before a standard is possible6:
-
Federation model: is a neutral registry a single global directory (centralized, with governance questions about who controls it), a federated network of organizational registries that can query each other, or a peer-to-peer discovery mesh? “Federation of Catalogs” and “Federation of Peers” represent genuinely different trust architectures, not implementation preferences.
-
Namespacing: in a multi-tenant registry, how are agent identifiers scoped? An agent named
invoice-processorin one organization’s namespace is not the same agent in another’s. Collision semantics and namespace delegation are unresolved. -
Search semantics: querying by endpoint URL is trivial. Querying by capability requires either a controlled vocabulary or semantic embedding — and either choice encodes assumptions about who defines the capability taxonomy.
-
Trust and attestation: a registry entry is only as trustworthy as its attestation mechanism. Who signs an Agent Card? Who revokes it? How does a consumer verify that the card it retrieved corresponds to the agent it actually reaches?
Until those decisions are made and codified, a “registry” is a bespoke service that happens to store Agent Cards.
FAQ
Does A2A v1.0’s silence on registry mean the standard is incomplete?
Not necessarily. Wire-protocol standards routinely scope to the communication layer and leave directory infrastructure to implementers: HTTP does not specify DNS, SMTP does not specify LDAP. The question is whether the A2A ecosystem will converge on shared registry infrastructure before proprietary implementations entrench. The MCP Dev Summit evidence — every major enterprise deployer building its own catalog layer — suggests convergence is not yet happening.4
If every enterprise is already building its own registry, why does a standard matter?
Cross-organizational agent authorization. Within a single organization, proprietary registries work adequately. Across organizational boundaries — a customer invoking a vendor’s agent, two enterprises sharing an automated procurement workflow — the absence of a shared registry model means every integration is a bespoke bilateral agreement. That cost is manageable at low integration counts and compounds as multi-agent workflows extend beyond organizational perimeters.
Is Solo.io’s three-layer taxonomy the authoritative framing of what’s missing?
It’s a useful framing, and the taxonomy (Registry, Naming Service, Gateway) maps cleanly onto the specification gaps. But Solo.io sells infrastructure products that fill exactly those gaps3, which means their analysis is directionally reliable while their architectural recommendations should be read with that context in mind. GitHub Discussion #741 is a more neutral, if less tidy, source for the actual unresolved design questions.6
Footnotes
-
Agent Discovery, Naming, and Resolution — The Missing Pieces to A2A — Solo.io ↩ ↩2 ↩3
-
Main Themes from MCP Dev Summit — Long Island NY (April 21, 2026) ↩ ↩2 ↩3 ↩4
-
A2A Protocol Surpasses 150 Organizations, Lands in Major Cloud Platforms — PR Newswire ↩
-
Agent Registry — Proposal · a2aproject/A2A · Discussion #741 ↩ ↩2 ↩3
-
MCP Dev Summit 2026: AAIF Sets A Clear Direction With Disciplined Guardrails — Futurum Group ↩