A2A has no standard agent registry API, and AAIF hasn’t closed the gap in 3 months

What you expect

The A2A protocol is governed by the Linux Foundation’s Agentic AI Infrastructure Foundation (AAIF), co-founded in December 2025 by OpenAI, Anthropic, Google, Microsoft, AWS, and Block. Agent discovery is listed on the A2A roadmap. Vendor-neutral governance with all major AI vendors as co-founders is the natural convergence mechanism for a shared agent registry standard.

What actually happens

We traced the A2A GitHub discussion history and registry ecosystem. The A2A spec explicitly defers: “The current A2A specification does not prescribe a standard API for curated registries.” Discussion #741 (“Agent Registry - Proposal”) has accumulated 29+ comments over 9 months — the same unresolved architectural disputes are present from month 1. The July 2025 roadmap listed a registry API as a 3-6 month item; that window ended January 2026 with no delivery.

AAIF launched December 2025 with all major AI vendors. Three months later, it has produced no shared registry spec. Community registry implementations exist (prassanna-ravishankar/a2a-registry, A2ABaseAI/A2ARegistry) but chose incompatible federated vs. centralized architectures with no coordination — fragmentation started before the spec exists.

The leading MCP-to-A2A bridge, GongRzhe/A2A-MCP-Server (143 stars), was archived March 3, 2026 with no stated reason and no migration path. The highest-adoption integration layer between MCP clients and A2A agents is now gone.

Three structural disputes block convergence in Discussion #741:

1. Scope model — enterprise entitlements vs. open internet vs. federated (mutually exclusive design choices)
2. Trust primitive missing — Agent Card JWS signatures exist in the spec since v0.3 but trust anchors and key infrastructure are undefined
3. Path fragmentation — /.well-known/agent.json (pre-v0.3) vs. /.well-known/agent-card.json (v0.3+) broke backward compatibility

The crawlable surface is ~15 registered agents, all in a single community directory. One independently confirmed live Agent Card exists at a .well-known URI (Luminary Lane). Community registries exhibit three consistent query-time failures: freshness gap (stale data between 30-minute health checks), silent since filtering (time-bounded queries fail without error), and binary gap responses (full results or nothing, no ranked output).

What this means for you

Agent discovery in A2A requires manual Agent Card exchange today and for the foreseeable future. Any builder planning to use A2A-based agent discovery as an architectural foundation is betting on a spec gap that has been open 9 months with no convergence path. The leading MCP-to-A2A bridge is archived. The natural governance mechanism (AAIF) has not closed the gap. The community registry implementations that do exist have incompatible architectures and three confirmed operational failure modes.

Building a registry now means building twice: the v1.0 RC breaking changes (SCREAMING_SNAKE_CASE enums, supportedInterfaces[] AgentCard restructure, /v1/ URL prefix removed) will require registry implementations targeting v0.3 to rebuild for v1.0 when it stabilizes.

What to do

1. Do not build agent discovery on current community registries. They have no query contract, incompatible architectures, and freshness gaps.
2. Use direct Agent Card exchange. For multi-agent systems today: distribute Agent Cards out-of-band (config files, CI environment variables, service registries you control).
3. Pin to v0.3.0 until v1.0 stabilizes. Building against the v1.0 RC (no formal GitHub Release yet) before the spec stabilizes means absorbing additional breaking changes.
4. Watch Discussion #741 for TSC convergence, and AAIF for a joint MCP/A2A registry spec announcement.
5. Replace GongRzhe/A2A-MCP-Server if you were using it: evaluate yw0nam/mcp_a2a_gateway or implement a direct Agent Card exchange instead.

Falsification criterion: This finding would be disproved by a merged registry API in the A2A spec (Discussion #741 resolved, spec updated), a joint MCP/A2A registry spec published by AAIF, or a community registry reaching 1,000+ registered agents with stable query semantics.

Evidence

Tool	Version	Evidence	Result
a2aproject/A2A	v0.3.0 (stable, March 2026)	source-reviewed	Discussion #741 open 9 months, 29+ comments, no registry API merged; July 2025 3-6 month roadmap window elapsed
GongRzhe/A2A-MCP-Server	143 stars at archival	source-reviewed	Archived March 3, 2026, no stated reason, no migration path
prassanna-ravishankar/a2a-registry	v1.0.0 (Feb 27, 2026)	source-reviewed	~15 registered agents; freshness gap, silent filtering, binary responses confirmed
A2ABaseAI/A2ARegistry	14 stars	source-reviewed	Chose centralized model; incompatible with prassanna federated approach; no coordination
AAIF	Launched December 2025	source-reviewed	OpenAI, Anthropic, Google, Microsoft, AWS, Block co-founders; no joint registry spec after 3 months
Apicurio Registry	Feb 5, 2026	source-reviewed	Added AGENT_CARD artifact type — enterprise-scoped, not open discovery

Confidence: empirical — 6 environments reviewed via source inspection of GitHub repos, discussions, press releases. No independently confirmed third-party validation of registry operational failure modes beyond prassanna-ravishankar/a2a-registry live testing.

Strongest case against: The AAIF governance structure is new (3 months) and may need more time. The v1.0 RC is still stabilizing — registry implementations rationally wait for the spec to finalize. The architectural disputes in Discussion #741 reflect genuine design tradeoffs, not intractable conflict. A registry spec could ship rapidly once v1.0 formally releases.

Open questions: Will AAIF produce a joint MCP/A2A registry standard before community implementations diverge further? Will Discussion #741 converge on a federated or centralized model? Does Apicurio’s AGENT_CARD support signal an enterprise-scoped registry emerging independently of the spec process?

Seen different? Contribute your evidence — share a repro or counter-example and we’ll review it against this finding. Reader evidence is what keeps these findings accurate.