Agent2Agent Protocol (A2A)

What it is

The Agent2Agent (A2A) Protocol is an open standard for communication and collaboration between AI agents. One agent, acting as a client on behalf of a user, sends work to a remote agent that exposes an HTTP endpoint implementing the protocol. The remote agent does the work and reports progress and results, without either side needing to know how the other is built.

A2A and MCP

The two protocols are complementary. MCP is how an agent reaches tools and data: a function to call, a resource to read. A2A is how an agent reaches another agent: a peer that takes a task, may ask follow-up questions, and returns results over time. A typical system uses both, MCP inside each agent and A2A between them.

The distinction is practical. A tool call is expected to be quick and deterministic in shape. A task handed to another agent may run for minutes or hours, need more input partway through, and produce several outputs. A2A is designed for that second shape.

Agent Cards and discovery

An Agent Card is a JSON document that describes an agent: its identity, endpoint, capabilities, skills, and authentication requirements. The specification registers a well-known location for it, /.well-known/agent-card.json, so a client can discover what a remote agent offers before sending it anything.

For an open architecture, the Agent Card is the agent's public contract. It is the portable description another team, or another framework, relies on.

Tasks, messages, parts, and artifacts

• Task. A stateful unit of work with a unique ID and a defined lifecycle. States include submitted, working, input required, auth required, completed, failed, canceled, and rejected.
• Message. One turn of communication, with a role of user or agent.
• Part. The content container inside messages and artifacts, holding text, raw bytes, a URL, or structured data.
• Artifact. A tangible output of a task, such as a document, an image, or structured data.

The input-required and auth-required states matter most for governance. They give a remote agent a standard way to stop and ask, rather than guessing or acting on authority it was not given.

Bindings, streaming, and push

The specification defines three protocol bindings: JSON-RPC 2.0, gRPC, and HTTP+JSON (REST), and allows custom bindings. Clients can stream incremental results over server-sent events, and for long or disconnected work a server can call a client-supplied webhook with push notifications.

Governance and versions

A2A was originally developed by Google and donated to the Linux Foundation. A Technical Steering Committee with representatives from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow maintains it, and it is licensed Apache 2.0. The latest released specification version is 1.0.0.

Where it fits in an open stack

A2A belongs in the open standards layer next to MCP, Agent Skills, and AGENTS.md. Its job is to keep the boundary between agents replaceable: an agent built on one framework can delegate to an agent built on another, and either can be swapped without the other noticing, as long as the Agent Card and task behavior hold.

It is also the natural interface for a broker. A component that routes work to several agents can treat each one as an A2A server rather than integrating each framework separately.

Gotchas worth knowing

• Authentication is declared, not solved. The Agent Card states requirements; your identity and authorization design still has to carry the user's authority across the hop.
• Remote output is untrusted input. Text returned by another agent can contain instructions aimed at yours.
• Long tasks need records. Keep task IDs, state changes, and artifacts so a multi-agent outcome can be reconstructed later.
• Versions changed shape. Early versions differ from 1.0; check which version an SDK or server implements.

How it scores on openness

• Replaceable. Strong. Agents behind a stable Agent Card can be swapped.
• Inspectable. Good at the boundary: tasks, messages, and artifacts are explicit. Each agent's internals stay its own.
• Portable. Strong. An open spec with multiple bindings and SDKs.
• Bounded. Supported through declared authentication and input-required and auth-required states; enforcement is the implementer's job.
• Grounded. Neutral. Grounding depends on what each agent connects to.
• Auditable. Good when task histories and artifacts are recorded on both sides.

What it is not

A2A is not a replacement for MCP, and it is not an agent framework. It does not decide how an agent works inside; it only defines how agents talk to each other.