What is the Agent-to-Agent protocol?
A2A is a standard for one agent handing work to another agent it did not build. It covers three things: how an agent advertises what it can do, how a task is structured and tracked, and how both travel over the wire. It is the horizontal counterpart to tool protocols.
The governance history matters because it explains why the protocol has traction. Google announced A2A in April 2025. That June, it donated the specification and SDKs to the Linux Foundation, under Apache 2.0. Founding partners included Amazon Web Services, Cisco, Microsoft, Salesforce, SAP and ServiceNow. That removed the single-vendor question early, and that's usually the thing that kills a proposed standard.
By its one-year mark, the Linux Foundation reported more than 150 supporting organizations. The protocol had native integration in the major cloud agent platforms. It also had production deployments across supply chain, financial services, insurance and IT operations. IBM's Agent Communication Protocol was folded into the same effort in August 2025, which further reduced fragmentation. The protocol reached version 1.0 in 2026, and version 1.0.1 in May 2026 added an extension mechanism.
This page is the specification-level companion to agent interoperability. That page covers the four layers of cross-platform cooperation and where each stands. This one covers what A2A actually specifies, what it deliberately leaves out, and the consequence of its central design decision. If you want the landscape rather than the protocol, start there.
How does A2A actually work?
An agent publishes an Agent Card at a well-known URL declaring its skills and how to reach it. A client agent reads that card, submits a task, and tracks it through an eight-state lifecycle until an artifact comes back or the task fails.
The mechanics are deliberately unexotic, built on JSON-RPC 2.0 over HTTP with gRPC and HTTP-plus-JSON bindings also available. That conventionality is a feature, it means existing gateways, authentication and network controls apply.
The Agent Card
A JSON document published at a well-known path, describing the agent's skills, the content types it accepts, its transport bindings and its security schemes. This is the discovery mechanism, and it is deliberately simple: fetch a URL, read what the agent says it does. Note the phrasing. The card is self-declared, which is covered from the trust side at agent identity.
The task lifecycle
Work is modelled as a task moving through defined states, which is what makes long-running and multi-turn delegation tractable rather than requiring a synchronous call to stay open.
| State | What it means | What the client does |
|---|---|---|
| submitted | The task has been accepted and not started | Wait, or subscribe to updates |
| working | The remote agent is executing | Stream updates, or poll |
| input_required | The agent needs something more before it can proceed | Supply it. This is where multi-turn delegation happens |
| auth_required | Additional authorization is needed | Obtain it, which is the credential question this protocol does not answer |
| completed | Finished, with an artifact returned | Consume the artifact |
| failed | The agent could not complete it | Decide whether to retry. The protocol does not decide for you |
| canceled | Stopped before completion | Handle a partial result if one exists |
| rejected | The agent declined the task outright | Route elsewhere |
Long-running tasks are tracked across connections using server-sent events for streaming or webhook push notifications for genuinely asynchronous work. Failures surface either synchronously as a JSON-RPC error object or asynchronously as a transition to a failed or rejected state. Retry logic and circuit breaking are deliberately left to the client, which is a reasonable protocol decision and means the resilience work is yours.
How is A2A different from MCP?
MCP connects an agent downward to tools and data. A2A connects agents sideways to each other. The commonly used shorthand is that MCP is USB-C for tool connectivity and A2A is HTTP for agent collaboration, and production systems use both rather than choosing.
The directional framing is accurate and it understates the more consequential difference, which is what each protocol lets you see.
When an agent calls a tool over MCP, the tool acts like a function. It takes arguments, returns a result, and the calling agent's own trace records the whole exchange. When an agent delegates a task over A2A, things work differently. The remote agent is not a function; it is another agent making its own decisions. You receive its conclusion, not its reasoning. Both protocols abstract something. MCP abstracts an operation. A2A abstracts an actor.
The combination in practice is straightforward: A2A routes a task to the right specialist agent, and MCP gives that agent the context and tools it needs to do the work. They sit at different layers and there is no meaningful adoption trade-off between them. For the MCP side see agent frameworks, where convergence on MCP as the tool layer changed where framework lock-in sits.
Why does the remote agent being opaque matter?
Because everything you built to govern your own agents stops at the boundary. You get a task state and an artifact. You do not get the remote agent's steps, its tool calls, its cost, or the authority it exercised, so four of your controls go dark at once.
This is the consequence least discussed in A2A material, and it is the one that determines whether cross-boundary delegation is something you can defend. The opacity is not a flaw in the protocol; it is the point of the protocol. Cooperation between agents built by different organizations requires exactly this abstraction. It also has a bill.
- Your inventory does not cover it. The remote agent is not in your agent registry and cannot be. You can register the fact that you delegate to it, which is worth doing, and you cannot record what it is or who changed it last.
- Your traces stop at the boundary. Per-step tracing is what makes an agent failure investigable, and a delegated task returns a result rather than a span tree. A failure inside the remote agent is a status code to you. See AI agent observability.
- Your evaluation cannot score the trajectory. Agent evaluation depends on judging the path as well as the outcome. Across an A2A boundary you can score the artifact and nothing else, so a remote agent that reached the right answer by an unacceptable route passes.
- Your audit record loses the authority chain. The record can show that you delegated a task and what came back. It cannot show on whose authority the remote agent acted, because cross-organizational delegated authority is not standardised. See AI audit trail.
Traceability is an optional extension, not a core guarantee. Four official example extensions exist, one of which addresses traceability, and none addresses governance. That is the right architecture for a protocol and it tells you where the work sits: if you need a remote agent's trace, you negotiate it commercially and require the extension contractually. Treat cross-boundary observability as a procurement requirement rather than a protocol feature, because that is what it currently is.
The workable stance is to treat a delegated task the way you would treat a subcontracted service rather than an internal function call. Record the delegation, capture what you sent and what came back, define what an acceptable artifact looks like so you can evaluate the output even without the path, and accept that a portion of your evidence chain now depends on a counterparty rather than on your own instrumentation.
What does A2A not specify?
There are four things worth knowing before you plan around it. What a declared capability means. How agents should be coordinated. How governance travels across the boundary. And what words like customer or vendor mean to both sides. Each gap is deliberate, and each one lands on you.
Knowing the boundaries prevents the common planning error of assuming the protocol covers a layer it never claimed.
| The gap | What it means in practice |
|---|---|
| Capability semantics | An Agent Card declares skills in its own words. Two vendors both claiming to summarise documents mean different things, so automated agent selection is not reliable. Discovery is solved; matching is not |
| Shared meaning | The protocol governs communication, not knowledge. If two agents hold different definitions of "active customer" or "approved vendor," they will produce contradictory output while communicating perfectly. See data intelligence |
| Orchestration | A2A makes delegation possible and says nothing about which agent should handle which step, in what order, or what happens on partial failure. See multi-agent orchestration |
| Governance | Nothing in the core specification carries policy, risk classification, or an accountability chain across the boundary. The published extensions do not address it either |
Two smaller technical gaps are worth flagging for anyone implementing. The specification is described in prose rather than formally, so some constraints are ambiguous, including whether a canceled task may be resumed. And practitioner guidance consistently notes the need for application-level workarounds around per-skill schemas, token downscoping and registry standardisation. Adjacent protocol work is filling some of this in, including an agent payments effort extending A2A into regulated transactional settings, so expect the gap list to shorten.
Should you adopt A2A now?
Yes if you genuinely need agents from different vendors or organizations to cooperate, and it is a poor reason to restructure anything internally. The specification is stable and the adoption is real. The question is whether you have the problem it solves.
The honest assessment splits into three cases, and most organizations are in the third.
- Adopt it now if you are crossing a boundary. Multiple vendor agents that must cooperate, or delegation to a partner organization's agent. This is the problem A2A exists for, the alternative is a bespoke integration per counterparty, and the protocol is stable enough to build on.
- Adopt it opportunistically if your platform already speaks it. The major cloud agent platforms have integrated A2A natively, so you may be able to expose or consume agents over it at low cost. Worth doing for the optionality even without an immediate need.
- Do not restructure internal agents around it. Inside one estate you already have shared identity, shared tracing and shared governance, and A2A's central abstraction throws exactly those away. Using a cross-organizational protocol between two of your own agents buys interoperability you do not need and pays for it in the visibility you just built.
One planning note. Since cross-boundary observability, delegated authority and capability matching are all currently implementation problems rather than protocol features, the cost of an A2A integration is not the protocol work. It is the surrounding apparatus, and that is where the estimate usually goes wrong.