A2A (Agent2Agent Protocol)

Most agent protocols so far — MCP included — focus on connecting a model to tools and data. A2A addresses a different problem: letting one autonomous agent hand off a task to a separate agent, potentially built by a different vendor, running on different infrastructure, without either side needing custom integration code for the other.

A2A originated at Google and has since moved toward broader, more vendor-neutral governance, positioning it as a named, real interoperability effort rather than a single company's proprietary format. As of 2026 it's still an actively developing area, and how much any given agent ecosystem actually implements it varies.

The core idea is an agent card — a published description of what an agent can do, similar in spirit to a service's API description — that another agent can fetch to learn a remote agent's capabilities before delegating a task to it. Tasks are then tracked through the protocol as they're worked on, potentially over an extended, asynchronous exchange rather than a single request/response.

How it works

A client agent discovers a remote agent's capabilities by fetching its agent card, which describes what kinds of tasks it can handle and how to reach it. The client then submits a task, and the two agents exchange messages over the protocol as the task progresses — which may involve multiple back-and-forth steps rather than a single call, since agent tasks (unlike a single tool call) can take an extended, multi-step process to complete. This makes A2A a complement to protocols like MCP rather than a replacement: MCP typically connects an agent to tools and data it uses internally, while A2A connects one agent to another agent as a delegate.

How it differs

Common misconceptions

FAQ