The Agent Registry Gaps No One Is Talking About

Two of the largest cloud providers — AWS (AgentCore Runtime) and Microsoft (Azure AI Foundry Agent Service) — have made A2A (Agent2Agent) protocol support generally available. Both hold seats on the A2A Technical Steering Committee. Both are in production in enterprises around the world. And the vast majority of teams building on top of their registries are quietly making the same mistake: treating the registry as a catalog rather than a compliance enforcement layer. There is, as of now, no clear framework for choosing a compliance enforcement layer that does the job.

This article is the practical evaluation guide. It covers what a registry has to validate to be more than a CRUD catalog, where the platform-native registries from AWS and Azure fall short today, and the features to look for whether you are evaluating off-the-shelf or building your own.

For purposes of clarity: the registry is the catalog plane. It holds what agents exist, their declared capabilities, owners, and policies. The gateway is the data plane. It enforces those policies at invocation time. The two are not interchangeable; the full treatment of that split lives in Agent Registry vs. Agent Gateway: Two Roles, One Control Plane. This article is exclusively about the registry's job, and the compliance validation almost no registry does today.

The A2A protocol reached 1.0 under the Linux Foundation in March 2026. The TSC includes AWS, Cisco, Google, IBM, Microsoft, Salesforce, SAP, and ServiceNow — the enterprise-software industry establishing a common standard for inter-agent communication. The 1.0 spec is transport-neutral but highly opinionated about the contract every agent has to satisfy: a well-formed AgentCard, a documented authentication scheme, and a discoverable URL where callers can find it. The registry is the mechanism for enforcing that contract at registration time.

The problem: both AWS and Microsoft currently ship A2A at v0.3 only — the pre-1.0 version. The spec has moved. The platforms have not caught up. And most registries have no mechanism to track which version of the spec each registered agent operates under, let alone validate whether its declared capabilities are actually compliant.

A2A v0.3 defined three transport options — JSON-RPC 2.0, HTTP+JSON, and gRPC — declared optionally via preferredTransport and additionalInterfaces[] on the AgentCard. A2A v1.0 consolidated these into a single ordered supportedInterfaces[] array, where the first interface is preferred and each entry carries url, protocolBinding, and protocolVersion. The schema changed. The enum values changed (breaking: jsonrpc became JSONRPC). A client that does not negotiate versions before sending a request will silently send a v1.0 payload to a v0.3 server, get a response, and fail to parse it.

AWS AgentCore Runtime deliberately chooses JSON-RPC 2.0 over HTTP as the single transport for inter-agent communication. The official AgentCore A2A protocol contract documents JSON-RPC 2.0 over HTTP exclusively; HTTP+JSON and gRPC are not implemented. Each AgentCore agent publishes a root POST endpoint plus a .well-known/agent-card.json discovery endpoint.

Azure AI Foundry Agent Service publishes an explicit transport-support table listing HTTP+JSON and JSON-RPC. gRPC is not supported — but that is an infrastructure constraint of standard enterprise web stacks (ALB, API Gateway, even uvicorn over HTTP/1.1), not a Foundry-specific choice. The A2A protocol version is stated explicitly: "0.3 only."

Neither platform is wrong — both are perfectly rational engineering choices. The problem is that a registry which stores an AgentCard claiming gRPC support without verifying it against the runtime produces a misconfigured catalog entry that fails on first invocation. And a registry that doesn't track A2A spec version per agent cannot safely route a v1.0 caller to a v0.3 agent — and no translation layer exists. The registry is the unique part of the system that sees all agents, which makes it the right place to enforce transport-declaration accuracy and flag version mismatches before they reach production.

The A2A specification describes the OAuth 2.0 Client Credentials flow for machine-to-machine scenarios, which in principle is supported through RFC 7591 Dynamic Client Registration. In practice, DCR support varies widely across IdPs, and neither major cloud platform uses DCR as an automated registration mechanism.

AWS AgentCore requires each runtime to be pre-configured with a customJWTAuthorizer pointing at your IdP's discovery URL. Every new AgentCore agent therefore requires infrastructure-team and identity-team coordination before its first M2M call.

Azure AI Foundry requires the calling agent's identity (managed identity, service principal, or agent identity) to be pre-granted the Azure AI User role on the target Foundry project. That RBAC role assignment is a manual operation in Azure RBAC. There is no support for dynamic registration of calling agents or for automated provisioning of OAuth 2.0 clients.

There is also a significant spec gap on top of these platform constraints: the A2A AgentCard has no field declaring client role (M2M vs user-delegated). A registry that receives an AgentCard cannot tell from the card alone whether the agent is intended for M2M invocation, user-delegated access, or both — that has to be tracked out of band.

The registry should own the auth-registration mappings for every agent: which IdP pre-config applies, which auth patterns are supported, which credentials have been coordinated. Without that, onboarding a new agent is a manual checklist with no enforcement.

The AgentCard is how an agent describes itself to other agents under A2A. A spec-compliant card lives at /.well-known/agent-card.json, contains a fixed set of required fields, and is publicly accessible without prior authentication. A2A v1.0 added an optional signatures[] field for JWS-based card authenticity (RFC 7515 + RFC 8785).

Here is how the two platforms diverge.

AWS AgentCore gets the discovery path right. The card at /.well-known/agent-card.json is unauthenticated, so standard A2A clients discover AgentCore agents out of the box.

Azure AI Foundry breaks both assumptions. The card lives at agentCard/v0.3 from the A2A base URL rather than the well-known root, and Foundry documentation states explicitly: "Both URLs require Microsoft Entra ID authentication. Anonymous access to the agent card isn't supported." A normal A2A client would read /.well-known/agent-card.json without credentials to learn how to authenticate. Foundry inverts this: the client must already have an Entra token with Azure AI User role for the project before retrieving the card. A standard A2A client has no way to know this in advance.

Microsoft's own documentation for calling a Foundry agent from the Python A2A SDK walks through manually configuring the httpx client with a Bearer token before creating the card resolver, then passing the custom agentCard/v0.3 path. Even Foundry-to-Foundry calls require a project connection created via REST API with the custom path in connection metadata — the Foundry portal does not yet support it.

This is not a Foundry bug. It is a deliberate security design choice that protects card metadata behind Entra authentication. The consequence is that any agent ecosystem including Foundry agents will fail standard A2A discovery unless the registry stores the non-standard path and auth prerequisites for each Foundry agent and conveys them to the caller before discovery is attempted.

The registry is the right place for this — it stores what the spec cannot assume about a particular deployment and makes it queryable. Custom card paths, auth prerequisites, transport restrictions, A2A spec version per deployment — all of it. Without that, every caller writes custom code for every possible target, which is operationally indistinguishable from having no standard at all.

Here is a concrete framework to apply when comparing, evaluating, or building an agent registry. Five questions are enough to separate a registry from a catalog with a better name.

If the answer to any of these is "no" or "not yet," you are running a catalog with a better name. The list also works as a scorecard for evaluating platform-native registries, open-source projects, and vendors — and as a requirements baseline if you decide to build one internally.

The issues described here are the ones that prompted us at ASCENDING Inc. to build Jarvis Registry as the central component of the Jarvis AI platform. The registry is open source.

Jarvis Registry is designed for the multi-cloud, multi-runtime world that native platform registries were not built for. The AWS Agent Registry is scoped to AgentCore and its related ecosystem. The Azure AI Foundry Agent Service publishes individual ARM resources per agent without a central catalog or cross-project A2A compliance validation. Neither provides a searchable, validated catalog of agents across boundaries. Jarvis Registry does — it validates AgentCard compliance at registration, tracks the metadata the spec cannot assume, and populates the Jarvis MCP Gateway with the enforcement context every invocation decision needs.