Before A2A, a Salesforce agent delegating a sub-task to a ServiceNow agent required hand-written glue code on both sides. Neither system had a shared interface - custom integration was the only option, and A2A replaces that one-off effort with a single open standard.
That is the practical problem the protocol solves. Whether it solves it well is a longer answer.
What the A2A protocol actually specifies
A2A is an open standard Google announced in April 2025 that enables AI agents built by different vendors to discover each other, delegate tasks, and coordinate work across enterprise systems.
It uses HTTP, Server-Sent Events, and JSON-RPC 2.0 for transport, and Agent Cards for capability advertisement.
The protocol defines three key concepts. Agent Cards serve as a discovery mechanism through which each agent publishes a machine-readable description of its capabilities, input and output modalities, and authentication requirements - analogous to a service descriptor in microservice architectures. Tasks represent units of work with a defined lifecycle, progressing through states such as submitted, working, input-required, completed, canceled, and failed, and carrying structured payloads that can include text, files, and structured data.
The relationship to MCP is worth stating plainly. A2A enables peer-to-peer agent coordination for multi-agent workflows through a client-server architecture where agents act as both clients and servers, while MCP implements a hub-and-spoke model connecting a single agent to multiple tools and data sources. A2A solves the horizontal problem of enabling agents to collaborate across platforms; MCP solves the vertical problem of augmenting a single agent's capabilities through standardized tool integration. Running both is the intended architecture, not a choice between them.
What v1.0 changed - and why it matters for production
Launched by Google Cloud in April 2025 and donated to the Linux Foundation, A2A grew further when IBM's Agent Communication Protocol merged shortly after , consolidating what had been competing standards. The protocol advanced from v0.3.0, which introduced streaming-first transport and enhanced Agent Cards with capability negotiation, to v1.0, which marked the transition from experimental to production-ready status, introduced signed Agent Cards for cryptographic verification, and codified the discovery and trust mechanisms identified as gaps in earlier analyses.
The most important v1.0 change is Signed Agent Cards. By adding a cryptographic signature to the Agent Card, a receiving agent can verify that the card was actually issued by the domain owner. Without this, an attacker could stand up a fake Agent Card and redirect other agents - a card forgery attack. Signed Agent Cards are effectively the trust model that makes decentralized discovery viable at all.
The current production version, v1.0, released March 12, 2026, formalized cryptographically signed Agent Cards using JWS (RFC 7515) with JCS canonicalization (RFC 8785) for domain verification.
Three other v1.0 changes are worth tracking if you are building now:
- Multi-tenancy: a single endpoint can now host multiple agents, letting SaaS providers serve different agents per tenant.
- Multi-protocol bindings: three concrete bindings ship with v1.0 - JSON-RPC 2.0 over HTTPS, gRPC, and HTTP+JSON/REST.
- Version negotiation: spec-level guarantees for backward-compatible migration from v0.3 to v1.0.
Beagle in action#eng-ops, 10:41amWhat the benchmarks say (and what they leave out)
ProtocolBench - an arXiv paper that measured A2A, ACP, ANP, and Agora across task success, latency, throughput, and failure resilience - gives the clearest empirical picture yet.
On the GAIA document-QA task, A2A achieved the highest task utility with an average quality score of 2.51 and a success rate of 9.29, outperforming the next best by 7.7% in quality and 27.6% in success.
GAIA stresses hierarchical, planner-driven multi-hop coordination rather than raw throughput, and A2A fits this pattern because its lightweight HTTP+JSON-RPC envelopes and Agent Cards make turn-based coordination cheap and easy to bind to a planner's role manifest.
The protocol is not uniformly better, though. In the Streaming Queue test, ACP demonstrated superior latency performance, achieving the lowest mean response time of 9.66 seconds with the smallest variance.
From a stability perspective, ACP exhibits the most consistent quality performance with minimal variance across evaluation runs, while A2A shows greater variability in success rates, indicating potential sensitivity to environmental conditions in complex coordination scenarios.
| Scenario | Best protocol | A2A result | Note |
|---|---|---|---|
| Multi-hop reasoning (GAIA) | A2A | 9.29 success | +27.6% over ACP |
| Streaming queue latency | ACP | 9.70s mean | ACP: 9.66s, narrower variance |
| Fail-storm resilience | A2A | 98.85% retained | ACP: 92.4%, ANP: 87.0% |
Under the fail-storm scenario, A2A exhibited exceptional resilience, retaining 98.85% of its pre-failure answer discovery capability, significantly outperforming ACP at 92.41%, ANP at 86.96%, and Agora at 81.29%.
The non-obvious read here: A2A is the right choice for planner-heavy, cross-vendor workflows with tolerance for run-to-run variance. If your workload is a high-throughput streaming queue where consistency beats peak task quality, ACP's narrower variance profile is worth the lower task success ceiling.
The security gap that Signed Agent Cards do not fully close
A2ASecBench - the first comprehensive security benchmark designed specifically for A2A - identified six novel attack vectors, and for five out of the six (Capability Cloaking, Task Flooding, Cycle Overflow, Agent-Side Request Forgery, and Agent Task State Injection), the Attack Success Rate reached 100% across all tested domains.
Signed Agent Cards address AgentCard Spoofing specifically. They do not close Capability Cloaking. In Capability Cloaking, the adversary registers AgentCards that advertise only benign functionality while operating backends with hidden or conditional malicious behaviors - the goal is to pass admission checks but later exploit runtime trust. A correctly signed card can still lie about what the agent actually does once admitted.
Researchers at Trustwave SpiderLabs demonstrated a related attack in 2025: a rogue agent presents an inflated Agent Card with a description designed to manipulate the host agent's LLM-based selection logic into choosing it for all tasks. Because the host agent evaluates cards using a language model, injecting persuasive text into the card's description field could hijack task routing.
Attack patterns were also shown to be transferable: re-instantiating the same attack patterns on LangGraph and ANP yielded 100% success for most, proving these are general multi-agent protocol weaknesses rather than A2A implementation bugs.
The practical upshot: if you are wiring cross-vendor agent workflows today, A2A v1.0 is the right transport layer to standardize on. Build your security posture assuming signed discovery is necessary but not sufficient - add runtime capability verification and rate-limit task-flooding paths explicitly.
A2A protocol: common questions
What is the A2A protocol and how does it differ from MCP?
A2A (Agent2Agent) is an open protocol for AI agents to discover each other and delegate tasks across vendor and framework boundaries, using HTTP, SSE, and JSON-RPC 2.0. MCP connects a single agent to tools and data sources. A2A is the horizontal coordination layer; MCP is the vertical tool-access layer. Most production multi-agent systems will use both.
Is A2A v1.0 production-ready?
V1.0 introduced multi-protocol support, enterprise-grade multi-tenancy, modernized security flows including Signed Agent Cards, and a defined migration path for early adopters. The SDK ecosystem expanded from one Python implementation to five production-ready languages: Python, JavaScript/TypeScript, Java, Go, and .NET. It is production-ready for coordination workflows; security hardening beyond signed discovery still requires custom runtime monitoring.
Who governs the A2A protocol?
The Linux Foundation launched the Agent2Agent project in June 2025. The protocol is a collaborative effort with growing support from more than 100 leading technology companies. Governance is vendor-neutral under the Linux Foundation, with Google, Microsoft, Salesforce, and ServiceNow among the supporting organizations.
What is an Agent Card in A2A?
An Agent Card is a public JSON document served at /.well-known/agent-card.json per RFC 8615. It describes an agent's name, skills, accepted authentication schemes, and endpoint URL. In v1.0, cards are cryptographically signed using JWS so a calling agent can verify domain ownership before trusting the declared capabilities.
Does A2A work with LangGraph, Google ADK, and other frameworks?
A2A-compliant servers can be built with frameworks including Google ADK, LangGraph, and BeeAI. The five official SDKs cover Python, JavaScript, Java, Go, and .NET, and the spec is transport-agnostic enough that any framework capable of serving HTTP can expose an A2A endpoint.