What Is A2A? The Agent2Agent Protocol Explained

Most companies will not run one agent. They will run many: a support agent, a billing agent, a research agent, some built in-house and some bought. Getting them to cooperate without custom glue for every pair is the problem the Agent2Agent protocol, A2A, is designed to solve.

A2A is an open protocol for communication between AI agents, including agents built on different frameworks by different vendors. Google introduced it in 2025 and later moved it to the Linux Foundation, so it is developed as a vendor-neutral standard.

The core ideas

sequenceDiagram
    participant C as Client agent
    participant R as Remote agent
    C->>R: Fetch agent card
    R-->>C: Skills, endpoint, auth
    C->>R: Send message (creates task)
    R-->>C: Status updates (streamed)
    R-->>C: Artifact (result)

• Agent card. A JSON file, usually served from a well-known URL, that describes an agent: its name, skills, endpoint and how to authenticate. This is how one agent discovers what another can do.
• Task. The unit of work. A task has a lifecycle, such as submitted, working, input required, completed or failed, so long-running jobs are first class.
• Message and parts. Agents exchange messages made of parts: text, files or structured data.
• Artifact. The output of a task, such as a document or a data file.
• Transport. A2A builds on web standards: JSON-RPC over HTTP, with streaming for progress updates. Later versions also added gRPC support.

A key design choice: agents stay opaque. The client agent does not see the remote agent’s prompts, memory or tools. It only sees the card and the messages. That protects intellectual property and keeps each team free to change internals.

A2A, MCP and AG-UI

Protocol	Boundary
MCP	Agent to tools and data
A2A	Agent to agent
AG-UI	Agent to user interface

They are complementary. An agent may use MCP to call a database tool, A2A to hand a subtask to a specialist agent, and AG-UI to show progress to the user.

When A2A is worth it

• Agents are owned by different teams or vendors.
• Tasks run long enough to need status updates and input-required pauses.
• You want to swap one agent for another without rewriting the caller.

You probably do not need it for a single app where one agent calls a few functions. A normal function call or an MCP tool is simpler.

Practical advice

1. Treat remote agents as untrusted. Validate their output like any external API response.
2. Authenticate per agent. Use the schemes declared on the card, and scope access narrowly.
3. Design for failure. Tasks can stall or fail. Set timeouts, and handle the input-required state.
4. Log task IDs end to end so a request can be traced across agents.
5. Version your agent card. Callers depend on the skills it advertises.

The takeaway

A2A is the shared language for agents that did not start out together. If your roadmap includes more than one agent, learning its cards and tasks now will make later integration far cheaper.