A2A: the standard for agent-to-agent communication · leejk

TL;DR. A2A (Agent2Agent) is the standard for agent-to-agent communication. Where MCP standardized agent↔tools/data, A2A standardizes agent↔agent — the two are not rivals but two axes of one ecosystem. Google announced it in April 2025 and transferred it to the Linux Foundation on June 23, 2025 (with AWS, Cisco, Microsoft, Salesforce, SAP, ServiceNow; 100+ companies backing it). It solves how agents on different frameworks discover, delegate to, and collaborate with one another — via Agent Card, Task, Message, and Artifact over JSON-RPC.

A2A

A2A is an open protocol standardizing communication and collaboration between AI agents built on different platforms, vendors, and frameworks. Google announced it in April 2025 and transferred it to the Linux Foundation's Agent2Agent project on June 23, 2025 at Open Source Summit North America — Google donated the spec, SDKs, and tooling wholesale, with AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow as founding partners. Over 100 companies back it, governed vendor-neutrally. It walks the same path as MCP (Linux Foundation governance), one layer up (between agents).

The problem A2A solves

If the problem MCP solved was the M×N explosion of agent↔tools, the problem A2A solves is the disconnection of agent↔agent. An agent built in LangGraph, one in CrewAI, one in Semantic Kernel — for them to hand work to one another, without a standard you wire each pair by hand. Three things were unstandardized.

Discovery — no consistent way to learn what another agent can do and where to address it. You had to read each agent's bespoke API.
Delegation / long-running work — no standard unit to hand work to another agent and track its progress. No vessel for collaboration that takes minutes to hours rather than an instant reply.
Trust across boundaries — no standardized auth/communication contract to exchange safely without sharing internals across org and vendor boundaries.

Components

A2A is made of the following.

1. Actors. An A2A Client (client agent) initiates communication on the user's behalf; an A2A Server (remote agent) exposes an HTTP endpoint implementing A2A. The server is an opaque black box to the client — it does not reveal its internals.

2. Agent Card. JSON metadata that is the agent's business card — identity, service endpoint URL, A2A capabilities, authentication requirements, and a list of skills. The client reads this alone to decide where, how, and with what auth to make contact — the entry point for discovery.

3. Units of work.

Unit	What
Task	A stateful unit of work with a unique ID and lifecycle. Tracks long-running, multi-turn collaboration. Respond with a Task instead of an instant reply and progress can be polled/subscribed
Message	A single conversational turn. role (user/agent), messageId, one or more Parts
Part	The content container. One of text, raw (binary), url, data (structured JSON)
Artifact	A deliverable produced by the remote agent. artifactId, name, Parts. Can stream incrementally

A contextId groups multiple Tasks into one context.

4. Transport. JSON-RPC 2.0 over HTTP(S). Three interaction modes — request/response (polling), streaming (SSE) for real-time incremental updates, and push notifications (client webhooks) for very long-running work. Authentication uses standard web security — credentials ride in HTTP headers, separate from the A2A message body.

How the components solve the problem

flowchart LR
    CA["Client agent<br/>(A2A Client)"]
    AC["Agent Card<br/>(discovery · auth)"]
    RA["Remote agent<br/>(A2A Server · black box)"]

    CA -->|"① fetch Agent Card"| AC
    AC -->|"capabilities · endpoint · auth"| CA
    CA <-->|"② JSON-RPC 2.0<br/>Task · Message · Artifact"| RA

    classDef box fill:#161821,stroke:#2a2d38,color:#e7e9ec;
    class CA,AC,RA box;

Discovery → Agent Card. Exposes capabilities, endpoint, and auth as one standard metadata document. The client reads what it can ask for without knowing the internals. (Where MCP's tools/list returns a tool catalog, A2A lifts it to an agent catalog.)
Delegation / long-running → Task. Responding with a stateful Task rather than an instant reply means delegated work is tracked via polling/SSE/push even if it takes hours. Artifacts stream incrementally, so results arrive as a flow.
Trust across boundaries → black box + separated auth. The server being opaque is the core design — it exchanges only inputs and outputs without sharing internals. Auth is separated from the message body and layered on standard web security. Different orgs and vendors reach each other over the same contract.

How it differs from MCP

After reading the MCP piece, the question is — are A2A and MCP rivals? No. The unit differs. MCP lets an agent reach tools and data; A2A lets an agent reach other agents.

Aspect	MCP	A2A
Connects	agent ↔ tools/data	agent ↔ agent
Counterpart	tool server (a capability)	remote agent (an autonomous actor)
Discovery	`tools/list` (tool catalog)	Agent Card (an agent's business card)
Unit	Tool/Resource/Prompt call	Task (stateful delegation)
Counterpart transparency	tool schema exposed	black box (internals hidden)
Shared	JSON-RPC, Linux Foundation, metadata discovery	same

In one line — MCP gives an agent hands; A2A gives it colleagues. Together they complete an ecosystem where tool-using agents collaborate with one another. That agent-governance treats MCP servers and A2A AgentCards side by side as first-class registry records is the operational proof of this complementarity.

Where it collides by design

Not an observation from running it, but the frictions that follow structurally from reading the spec.

The Agent Card is the basis of trust. Since a client judges capability and auth from a single card, if the card's authenticity and discovery path aren't verified, delegation can go to a spoofed agent — the discovery standard is itself an attack surface.
The black box blocks internal verification. The remote agent being opaque (internals hidden) is the same coin as the client being unable to inspect what that agent actually did. Audit and debugging are confined to what's visible from outside — Artifact and Task state.
Remote responses flow into context. Another agent's Messages and Artifacts enter the client model's context, so the same injection vector as MCP tool responses stands between agents too — the logic of placing the trust boundary at the tool-call wire is needed for A2A responses as well.
State coherence of long-running Tasks. Polling, SSE, and push all report the same Task state, and if their delivery/retry guarantees differ, state diverges. The longer the task, the more omissions and duplicates accumulate.

In sum

A2A is MCP's counterpart. As MCP solved connectability (agent↔tools), A2A solves interoperability (agent↔agent) — same Linux Foundation track, same JSON-RPC and metadata-discovery pattern. The chance of the protocol wobbling is effectively removed by simultaneous backing from the major clouds and model labs. What remains is identical to MCP — not the protocol but the operations on top of it (trust, audit, the injection boundary), and those operations are handled separately by agent-governance.

A2A