Wiki · Concept · Last reviewed June 25, 2026

A2A Protocol Bindings

A2A protocol bindings are the layer that maps the shared Agent2Agent data model and operations onto concrete network interfaces such as JSON-RPC, gRPC, HTTP+JSON/REST, and custom transports.

Category: Concept / Agent Infrastructure Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: A2A, AI Agents, Protocol Bindings, JSON-RPC, gRPC, REST, Governance

Definition

A2A protocol bindings are the concrete wire forms used by Agent2Agent Protocol. The A2A specification separates a data model, protocol operations, and protocol bindings. The data model names objects such as tasks, messages, parts, artifacts, agent cards, and extensions. The operations describe actions such as sending messages, getting tasks, listing tasks, canceling tasks, subscribing to task updates, and retrieving extended agent cards. The binding says how those operations move across a particular transport.

This distinction matters because an agent workflow can look interoperable at the product level while hiding incompatible wire behavior. A client that supports JSON-RPC is not automatically a gRPC client. A REST gateway may expose the same underlying task operation but produce different logs, headers, content types, retry behavior, and error surfaces.

Standard Bindings

The official A2A custom-bindings page says the protocol ships with three standard bindings: JSON-RPC, gRPC, and HTTP+JSON/REST. The specification gives each binding its own section.

JSON-RPC. The JSON-RPC binding uses JSON-RPC 2.0 over HTTP(S), application/json request and response bodies, PascalCase method names such as SendMessage and GetTask, and Server-Sent Events for streaming. It is the binding most similar to many current agent and tool-integration APIs.

gRPC. The gRPC binding uses Protocol Buffers over HTTP/2. It is useful when implementers want generated clients, strongly typed service contracts, streaming support, and deployment patterns already common in service meshes and internal platforms.

HTTP+JSON/REST. The REST-style binding maps operations to ordinary HTTP endpoints, including POST /message:send, POST /message:stream, GET /tasks/{id}, GET /tasks, POST /tasks/{id}:cancel, and POST /tasks/{id}:subscribe. The specification also registers application/a2a+json for the HTTP+JSON/REST binding.

Service Parameters

A2A v1.0 made service-parameter handling more explicit. For HTTP-based bindings, the protocol version and extension list travel as HTTP headers such as A2A-Version and A2A-Extensions. The specification notes that multiple extension values should be comma-separated in a single header field. The header layer is therefore part of the evidence record, not a decorative transport detail.

Agent Cards can also advertise supported interfaces. The definitions page says an interface's protocolBinding is an open-form string, with the core official values JSONRPC, GRPC, and HTTP+JSON, and a protocolVersion value such as 1.0. Clients should not guess binding support from brand or endpoint shape alone.

Custom Bindings

Custom protocol bindings let implementers expose A2A operations over transports beyond the three standard bindings. The custom-bindings page frames this as an extension point for additional communication patterns. That flexibility is useful, but it raises the bar for documentation: a custom binding should preserve the A2A operation semantics, data model, version handling, authentication expectations, streaming story, and error mapping.

In governance terms, custom does not mean invisible. A custom binding should be named in the Agent Card, versioned, tested for interoperability, and documented well enough that an auditor can tell whether it preserves the same task, message, artifact, cancellation, and authorization boundaries as the standard bindings.

Governance Requirements

A governed A2A deployment should log the selected binding, endpoint URL, protocol version, extension headers, content type, operation name, task or context ID, authentication scheme, caller identity, response status, A2A error code, stream lifecycle, retry behavior, and gateway or adapter identity. If a gateway translates between bindings, the audit trail should record both sides of the translation.

Authorization must survive binding changes. A task that is inaccessible through GetTask in JSON-RPC must not become visible through GET /tasks/{id} in REST. Likewise, extension negotiation, tenant routing, and cancellation behavior should not silently change when an implementation exposes a second binding.

Failure Modes

Binding drift. The JSON-RPC, gRPC, and REST endpoints implement slightly different behavior for the same operation.

Header loss. A proxy strips A2A-Version or A2A-Extensions, causing version or extension assumptions to disappear from the request.

Gateway laundering. A translation layer hides the original caller, endpoint, or error surface, weakening incident reconstruction.

REST overexposure. A convenient HTTP endpoint makes task listing, history retrieval, or artifact access broader than the authorization model intended.

Custom-binding ambiguity. A nonstandard transport claims A2A compatibility but does not clearly preserve streaming, cancellation, errors, or task-state semantics.

Source Discipline

Claims about JSON-RPC, gRPC, HTTP+JSON/REST, service headers, media types, and operation mappings should cite the versioned A2A specification. Claims about the purpose and limits of custom bindings should cite the official custom-bindings page. Claims about protocolBinding and protocolVersion fields should cite the A2A definitions page.

Spiralist Reading

A protocol binding is where agent collaboration becomes mundane network traffic.

The same delegated request can wear several costumes: a JSON-RPC method, a gRPC call, a REST endpoint, a streaming response, or a custom transport. Spiralism's concern is continuity of responsibility. If the costume changes, the record must still show the same work, authority, refusal points, artifacts, and side effects.

Open Questions

Sources

Return to Wiki