Quick answer: Agent2Agent (A2A) is an open protocol that lets one agent communicate with another over JSON-RPC. It defines an agent card that describes the remote service, a set of task methods for sending work and reading or cancelling it, and optional streaming over SSE. The desktop can verify a card, exercise the methods, and generate a local A2A server, but A2A is a supporting capability rather than the core of the product.
The problem A2A addresses
Without a shared protocol, every agent integration is bespoke. One agent calls another through a custom shape, parses a private response, and has to be rebuilt the moment the other side changes. There is no standard way to describe what the agent can do, track a task that takes time, or cancel work already in flight.
A2A fixes those points with a small, task-based contract so agents from different systems can interoperate without a point-to-point design.
The core pieces
| Piece | Role |
|---|---|
| Agent card | Describes the agent's skills, endpoints, and security |
| JSON-RPC methods | Carry the task requests and responses |
| Task | The unit of work sent to the remote agent |
| SSE streaming | Optional channel for progress and status updates |
| Cancel | A method to stop a task that is still running |
The card is the entry point. A caller fetches it first, reads what the agent offers and how it is secured, then uses the task methods rather than guessing at the shape.
How a task moves
A2A is built around a task that can take time rather than a single immediate response.
- The caller fetches and verifies the agent card.
- It sends a task using the declared method.
- The remote agent returns a task reference and status.
- The caller polls the status or subscribes over SSE.
- It can cancel the task before it reaches a terminal state.
Because the work is long-running, the status is a first-class part of the protocol rather than something the caller invents. A task moves through defined states, and the final result is read separately from the initial acceptance.
Where security sits
The agent card carries the security information, and the protocol supports signed requests. A JWS signature lets the caller verify the message, but signature checks have limits, and a valid signature does not make the payload correct or safe. Treat the signature as an authentication and integrity check, not as proof the task behavior is right.
The desktop can check a card locally, including its structure and security fields, before you trust the remote agent. It also handles the case where a JSON-RPC error arrives inside an HTTP 200, which a status-only check would miss.
Honest scope
A2A is a supporting capability behind the two core workflows. It matters because agents increasingly call one another, and those calls need the same kind of verification as any other API, but it is not a reason to position the product as a general client. A generated A2A server is a local scaffold for testing, not a production deployment, and it does not replace the real remote agent.
Powerduck treats A2A as another surface to verify, with the same evidence and idempotency discipline used across the rest of the desktop.
Frequently asked questions
Is A2A a transport or a full protocol? It is a protocol over JSON-RPC, with an agent card, task methods, status, and optional SSE streaming, rather than just a wire format.
Why is the agent card fetched first? It describes the skills, endpoints, and security so the caller knows how to interact before sending a task.
Does a valid signature mean the task is safe? No. A JWS signature checks integrity and origin, not the correctness of the payload or the behavior.
The bottom line
A2A is an open, task-based protocol for agents to communicate over JSON-RPC, built around an agent card, task methods with status, and optional SSE streaming and cancellation. It removes the need for bespoke point-to-point integrations while still requiring real verification, because a signed or accepted task is not a verified behavior. Keep it in its lane as a supporting capability, and verify the card and the responses the same way you would any API. Read more in the A2A guide.
Top comments (0)