A2A

A2A (Agent2Agent) is an open protocol for communication and collaboration between independent, opaque agentic systems. It is neither a model nor a framework, but a common language for agents built by different teams. An agent is not a tool: wrapping it as one loses the dialogue and the stateful work.

The agent card and discovery

Every A2A server, the remote agent, publishes a JSON Agent Card: name and provider, the service endpoint (url), the optional capabilities (streaming, pushNotifications), the authentication schemes and the skills, each with an id, examples and input and output modes.

Public agents serve the card at /.well-known/agent-card.json. Curated registries and direct configuration are the other documented routes; no standard registry API is prescribed, so each operator designs its own. Sensitive cards should be authenticated, with no static secrets embedded.

Task, message, artifact

A stateless Message completes in one turn and leaves no trackable work. A Task is a stateful unit of work with an id and a lifecycle: working, input-required and auth-required as interrupted states, completed, failed, canceled and rejected as terminal ones. The contextId groups a conversation so follow-ups keep their thread, taskId values are always server-generated, and output is an artifact of parts: text, file references or structured data.

A terminal task cannot restart, so a refinement opens a new task in the same context. Artifact versioning is not part of the protocol, it belongs on the client side.

How updates arrive

Three complementary mechanisms:

• Polling: the client asks for state with GetTask. Simple, higher latency.
• Streaming: SendStreamingMessage, plus SubscribeToTask after a dropped connection. The server answers with text/event-stream and streams status and artifact update events, and several streams may attach to one task.
• Push notifications: the server sends a POST to a client webhook, so no connection stays open.

All three depend on a capability declared in the card, otherwise the call errors. SendMessage blocks by default until the task reaches a terminal or interrupted state, and requests carry an A2A-Version header.

How it relates to MCP

MCP deepens one agent by attaching tools, resources and data sources. A2A widens the system by connecting agents that run separately, possibly under another organization. The documentation frames this as a vertical and a horizontal layer: A2A agents partner on a task, while MCP lets an agent use capabilities. Well-defined skills can still be exposed as MCP-compatible resources.

In our stack MCP is the tool layer under the Hermes Agent, and A2A is the agent-to-agent side, where a Paperclip team hands tasks between agents.

What to watch

• Undeclared means unavailable. Capabilities are negotiated from the card, so a client checks support before calling.
• Identity sits outside the protocol. Payloads carry no user identity, authentication happens in HTTP headers, and all credentials are obtained out of band, including credentials requested mid-task.
• The webhook is an attack surface. A server should not POST blindly to a client-supplied URL, which enables SSRF or amplifies denial of service. Allowlisting, ownership verification and egress controls are the countermeasures; the receiver must verify signatures and drop replayed notifications.
• Error responses must not leak. A server must not distinguish a missing resource from one the client may not see.
• Open items. The roadmap lists dynamic modality negotiation inside a task, a possible QuerySkill() method and better streaming reliability.

At CyberElectro we use A2A at the boundary between agents, where a handover carries state and a lifecycle rather than being a single tool call.

Further reading

• A2A Protocol Specification - the official protocol text, versioned.
• A2A and MCP - how the two protocols relate.
• a2aproject/A2A - the project repository with its roadmap and SDK list.