Dev.to AI 🤖 Ai 👁 0 📖 3 min read

A2A 1.0 vs 0.3 Bindings

Quick answer: A2A 1.0 supports three bindings, JSON-RPC, REST/HTTP with JSON, and native desktop gRPC, while A2A 0.3 supports JSON-RPC only. The desktop does not silently translate between versions, and an unsupported ve

Quick answer: A2A 1.0 supports three bindings, JSON-RPC, REST/HTTP with JSON, and native desktop gRPC, while A2A 0.3 supports JSON-RPC only. The desktop does not silently translate between versions, and an unsupported version and binding combination is rejected rather than rounded into a working request. You build and debug the calls in the Debug surface with a generated body and the A2A-Version header.

Why the binding matters

A binding is the concrete way a message travels. The same task concept can be expressed over different wires, but the remote agent only accepts the ones its version defines. Sending a REST call to a 0.3 agent, or a gRPC call where only JSON-RPC is offered, does not produce a graceful fallback, and assuming otherwise leads to calls that fail in a way the caller did not anticipate.

The version and the binding are therefore a pair, not independent choices.

The two versions side by side

Version Supported bindings
A2A 1.0 JSON-RPC, REST/HTTP+JSON, native desktop gRPC
A2A 0.3 JSON-RPC only

JSON-RPC is the common ground. It is the one binding available on both versions, which makes it the safe choice when you do not control the remote side or need to work across versions.

Choosing among the three 1.0 bindings follows the context. JSON-RPC is the most portable and the natural default for a first integration. REST is the easiest to inspect with ordinary HTTP tooling and fits a team that already thinks in HTTP resources. Native desktop gRPC is for the local desktop path where that binding is offered, rather than a general-purpose choice. Without a reason to pick one of the others, JSON-RPC keeps the call simple and version-safe.

Why there is no silent translation

It would be convenient if the tool converted a 1.0 REST call into a 0.3 JSON-RPC call automatically, but that hides a real difference rather than resolving it. The two shapes do not carry every detail the same way, and an automatic translation could change the semantics while reporting success.

The desktop instead keeps the boundary explicit:

  1. Select the version that matches the remote agent.
  2. Choose a binding that version supports.
  3. Send the request with the A2A-Version header.
  4. If the combination is unsupported, the tool rejects it.
  5. Confirm the response against the declared contract.

Rejecting the unsupported combination is the honest behavior, because it keeps you from trusting a message the remote side never accepted.

How this looks in the Debug surface

The Debug surface generates the request body for the chosen version and binding, and it attaches the A2A-Version header so the remote agent knows which dialect it is receiving. Even when the HTTP layer returns 200, the body can still carry a JSON-RPC error, so a status-only check is not enough. Read the payload and distinguish a transport success from a protocol-level error.

This is the same boundary that keeps a 200 from being treated as a pass. A green transport status can sit beside a method-level rejection, and the two have to be read separately.

Powerduck keeps the version and binding rules in the tooling rather than papering over them, so the request you send matches what the agent actually supports.

Frequently asked questions

Can I call a 0.3 agent over REST? No. 0.3 supports JSON-RPC only, and the unsupported combination is rejected rather than translated.

What is shared between 1.0 and 0.3? JSON-RPC is the one binding available on both, so it is the safest default when the remote version is uncertain.

Does a 200 mean the A2A call succeeded? Not always. The body can carry a JSON-RPC error even when the HTTP status is 200, so read the payload rather than the status alone.

The bottom line

Match the binding to the version: 1.0 offers JSON-RPC, REST/HTTP+JSON, and gRPC, while 0.3 is limited to JSON-RPC. The tool rejects unsupported pairs instead of silently translating, which keeps the semantics honest, and the A2A-Version header carries the dialect. Remember that a 200 can still hold a JSON-RPC error, and verify the payload rather than the transport status. The version boundary is there to protect the call, not to inconvenience it. Continue in the A2A guide.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.