Agent cards, discovery, and the three bindings
Lesson 2 of 5 in A2A and Agent Interop — Honestly Sized.
Before one agent can delegate to another it has to answer two questions: what can you do, and how do I authenticate. A2A answers both with a single artefact — the Agent Card, a JSON metadata document the server publishes about itself.
Read it as the machine-readable version of a service’s README plus its OpenAPI security section. The client fetches the card, decides whether the remote agent has a skill matching the job, and learns which credential to present. No handshake, no registration protocol, no SDK dependency — just a document.
Identity — who is this agent, and whose is it?
Name, description, provider, version. This is the field set your catalogue and your traces will key on, and the field set an attacker would most like to spoof. Identity in the card is a claim; the trust comes from the domain that served it over TLS and the credential the caller must present back.
Skills — the unit a client matches against
Named, described units of work the agent offers. Skills are the closest thing A2A has to a tool schema, but deliberately looser: a skill describes what the agent will take on, not the exact arguments of one call — because the interaction is a conversation about a task, not a single typed invocation.
Capabilities — which optional protocol features are on
Feature flags such as capabilities.streaming, capabilities.pushNotifications, and capabilities.extendedAgentCard. Your client must branch on these, not assume them. This is where “supports A2A” stops being a boolean: two conformant agents can share a version and still support different update-delivery mechanisms.
Service endpoint and bindings — where to send work
The URL to call and the protocol binding(s) available there. A2A 1.0 defines three (next block), and cards in practice advertise only a subset — Foundry’s incoming endpoint advertises JSON-RPC alone — so “we both speak A2A 1.0” does not guarantee you share a transport.
Security schemes — how to authenticate
The card declares OpenAPI-style security schemes: APIKeySecurityScheme, HTTPAuthSecurityScheme, OAuth2SecurityScheme, OpenIdConnectSecurityScheme, MutualTlsSecurityScheme. A2A deliberately invents no new auth: failures land as HTTP 401/403, gRPC UNAUTHENTICATED/PERMISSION_DENIED, or JSON-RPC errors, so your existing identity stack and least privilege policy still apply. The spec additionally defines an in-task authorization mechanism for credentials a task needs mid-flight.
Those three discovery modes are not equivalent in production. The well-known URI is genuine open-web discovery: anyone who knows your domain can enumerate what your agent does. Curated registries are what enterprises actually want — an approved catalogue with ownership and review — but because no registry API is standardised, whichever registry you adopt is a component you own or a vendor you depend on, not a portable protocol feature. Direct configuration is the least glamorous and, for internal deployments, the most defensible: you pin the exact agents you trust.
JSON-RPC
The original binding, and the only one in the April 2025 draft — JSON-RPC over HTTP with SSE for streaming. Where a platform supports exactly one transport, the one verified example in this module is JSON-RPC: Microsoft Foundry’s incoming A2A endpoint supports only JSON-RPC for A2A 1.0 (Microsoft Learn, checked September 2026). Treat that as a single data point, not a survey — check each platform’s own docs for the bindings it actually exposes.
gRPC
A first-class binding in A2A 1.0, attractive where you already run gRPC service meshes and want typed stubs, streaming, and deadline propagation for free. The trade-off is reach: browser and edge clients, and platforms that proxy JSON payloads, may not offer it.
HTTP+JSON / REST
Plain REST semantics for teams that want to call an agent with curl and inspect it with the same tools they use for every other service. Conceptually the lowest-friction binding to operate, and the easiest to put behind an existing API gateway.
Equivalence and versioning
All three bindings are required to be functionally equivalent to a canonical model whose normative definition is the proto file spec/a2a.proto — the spec calls it the single authoritative definition of all protocol data objects. The spec also allows custom bindings under published guidelines.
Version negotiation uses an A2A-Version header/parameter in Major.Minor form; an empty value is interpreted as version 0.3. Pin the version you tested, log the negotiated value, and never let it be implicit.
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.