What is the A2A protocol?
The Agent2Agent Protocol is an open standard for communication between agentic applications that were built by different teams, on different frameworks, and that do not trust each other with their internals. Google published it in April 2025 and announced the donation to the Linux Foundation on June 23, 2025 at Open Source Summit North America, handing over the specification, the SDKs and the developer tooling. AWS, Cisco, Google, Microsoft, Salesforce, SAP and ServiceNow were named alongside that move. The design constraint worth remembering is the word opaque: an A2A server is a black box to its client, so agents collaborate without sharing memory, tools or proprietary logic. That is what makes it usable between companies rather than only inside one codebase.
How does the A2A protocol work?
There are three actors. A user sets a goal, an A2A client (the client agent) acts on their behalf, and an A2A server (the remote agent) exposes an HTTP endpoint that accepts work. The client finds the server by reading its Agent Card, sends a Message, and gets back either an immediate Message or a stateful Task with its own id and lifecycle. Long jobs are followed in one of three ways: polling, a Server-Sent Events stream for incremental updates, or push notifications to a webhook the client supplies for cases where it will not stay connected. Version 1.0 defines three protocol bindings: JSON-RPC 2.0 over HTTPS as the primary, gRPC with Protocol Buffers, and plain HTTP/JSON REST.
What is an agent card in A2A protocol?
The Agent Card is a JSON metadata document that works as an agent’s business card: its identity, its service endpoint URL, its A2A capabilities, its skills, and the authentication it expects. Clients parse it to decide whether this agent can do the job at all and how to call it securely. Version 1.0 added Signed Agent Cards, which is the change that matters commercially: the card can now be cryptographically signed, so a client can verify an agent’s claimed identity across an organizational boundary instead of taking a JSON file at its word. If you plan to let an outside agent do paid work for you, the signed card is the hook your audit trail should be recording.
What does the A2A protocol enable?
Five elements do the work. An Agent Card handles discovery. A Task is a stateful unit of work with an id and a lifecycle. A Message is one turn of conversation with a role of user or agent. A Part is the content container inside messages and artifacts, holding exactly one of text, raw bytes, a URL or structured JSON data, plus an optional mediaType and filename. An Artifact is the deliverable an agent actually produces, streamable as it is generated. A contextId groups related tasks so a series of interactions hangs together. Read that list again and notice what is not in it: there is no amount, no currency, no invoice and no receipt.
What is A2A protocol vs MCP?
They answer different questions and the split is clean once you see it. MCP standardizes how one agent reaches a tool or resource: a database query, an API call, a weather lookup, mostly stateless primitives with structured inputs and outputs. A2A standardizes how one agent reaches another agent: an autonomous peer that reasons, plans, holds state across a long interaction and may take many turns to finish. The protocol’s own documentation frames them as complementary rather than competing, and the reference picture is an application using A2A to talk to remote agents while each of those agents privately uses MCP for its own tools. We cover the money side of the tool layer separately in MCP payments.
Can A2A replace MCP?
No, and building as if it could produces a mess. If you wrap a calculator or a SQL query in an A2A server you have paid the cost of task lifecycles, agent cards and long-running state for something that returns in 40 milliseconds and holds no state. If you expose a genuine multi-turn agent as an MCP tool you lose the task id, the streaming updates and the ability to come back to a job an hour later. The practical test is whether the thing on the other end reasons and remembers. If it does, A2A. If it just computes, MCP. Most real systems end up running both at the same time.
Is the A2A protocol open source?
Yes. The specification, the SDKs and the developer tooling sit with the Linux Foundation, and the reference implementations live under the a2aproject GitHub organization with production SDKs for Python, JavaScript, Java, Go and .NET, plus community work in Rust. As of the version 1.0 announcement the core repository carried more than 22,000 GitHub stars. Neutral governance is the reason competitors could adopt it: Microsoft integrated A2A into Azure AI Foundry and Copilot Studio, and AWS added support through Amazon Bedrock AgentCore Runtime, neither of which happens for a protocol still owned by Google Cloud.
Is the A2A protocol production ready?
Version 1.0 landed on April 9, 2026, exactly a year after the original release, and the Linux Foundation put concrete numbers on it: more than 150 organizations participating, up from roughly 50 at launch, with named production use across supply chain, financial services, insurance and IT operations. The v1.0 release notes cover four areas: multi-protocol transport support, multi-tenancy, Signed Agent Cards, and a more web-aligned architecture. Version 1.0 also means the versioning promise now exists at all, which is the part that lets a risk team sign off. What is still immature is everything financial, which is the next section.
Does the A2A protocol handle payments?
Not in the core specification, and this is the single most common misconception about A2A. A Task has a lifecycle but no price. An Artifact is a deliverable with no invoice attached. Authentication requirements are declared in the Agent Card and credentials travel in ordinary HTTP headers, deliberately kept separate from A2A messages, so the protocol never sees a payment instrument. If you are running agents that buy things, A2A gives you interoperability and gives your finance team nothing. That gap is exactly what agentic payments infrastructure exists to fill.
How do agents pay each other over A2A?
Through the extension mechanism, which is worth understanding because it is how every payment story on A2A actually works. An agent declares extensions in its Agent Card as AgentExtension objects inside AgentCapabilities, each with a uri, a description, a required flag and optional params. A client asks for one by sending an A2A-Extensions HTTP header listing the extension URIs it wants active, and the agent echoes back the ones it turned on. Extension payloads then ride in the request metadata field under namespaced keys. Extensions are promoted through a tiered governance process so the core spec stays small. Payment is one of these extensions, never a core feature.
What is the a2a-x402 extension?
The a2a-x402 extension is the most concrete answer to agent-to-agent payment on A2A today. Maintained by Google Agentic Commerce under Apache 2.0, still at specification v0.1, it borrows the HTTP 402 Payment Required idea and turns it into three A2A message states: payment-required, where the serving agent says the work costs money; payment-submitted, where the client agent signs and returns payment details; and payment-completed, where the server verifies, settles on chain and hands over the artifact. It is a clean fit for machine-scale amounts, which is the same reason we look at x402 separately. Treat v0.1 as what it says it is: early.
Where does AP2 fit with the A2A protocol?
AP2, the Agent Payments Protocol, is the card and mandate answer where a2a-x402 is the stablecoin answer. Google announced it on September 16, 2025 with more than 60 partners under Apache 2.0, and it is built as an extension on top of A2A rather than a replacement for it, which is why the two names keep appearing together. Its job is proving that a human authorized a specific purchase, using signed mandates, and on April 28, 2026 it was donated to the FIDO Alliance alongside Mastercard’s Verifiable Intent. A useful mental model for a whole autonomous purchase: A2A finds and commissions the work, AP2 authorizes the money, and x402 or a card rail settles it.
Does LangGraph or Claude support the A2A protocol?
Framework support is broad because A2A was designed to be framework neutral. The protocol documentation names LangGraph, CrewAI and Semantic Kernel as examples of platforms that interoperate, and Google’s own Agent Development Kit is one option rather than a requirement. On the model side the honest answer is that A2A support is a property of the agent runtime you build, not of a model vendor: any model can sit behind an A2A server, and Anthropic’s contribution to this stack is MCP on the tool side rather than a competing agent-to-agent standard. If a vendor tells you their model speaks A2A, what they mean is their agent framework does.
Is the A2A protocol stateless?
No. That is close to the whole point of it. A Task is explicitly a stateful unit of work carrying an id and a defined lifecycle, and a contextId groups multiple related tasks into one longer thread. Statelessness is an MCP tool property, not an A2A property. The operational consequence is that a task can stay open across minutes or hours, which is why the spec bothers with push notifications to a webhook, and which is also why unsupervised spend is a real risk: a task your agent opened this morning can still be spending money for you this afternoon.
What the A2A protocol does not give a finance team
Everything A2A standardizes is horizontal: discovery, task lifecycle, message format, transport. Nothing in it is cumulative. There is no running total of what an agent has spent this month, no per-agent budget, no merchant allowlist, no human approval step above a threshold and no ledger that survives the task ending. Extensions negotiate per request, so even a2a-x402 sees one payment at a time and has no memory of the last hundred. That is the layer we build: per-agent spend controls, scoped virtual cards, approval thresholds and an audit trail that reconciles, sitting underneath whichever protocol your agents happen to speak. If your agents are already delegating paid work to each other, agent-to-agent payments is the specific shape of that problem.