In short
The Agent2Agent (A2A) protocol standardizes direct communication between independent AI agents. Announced by Google in April 2025, it fills a blind spot that MCP (Anthropic’s Model Context Protocol) does not cover: not the agent→tool relationship, but the agent→agent relationship. Since June 2025, A2A has been governed by the Linux Foundation. In August 2025, IBM’s competing ACP protocol merged into it, preventing fragmentation of the standard.
Why an agent-to-agent protocol?
Two agents built on different frameworks — LangGraph on side A, CrewAI on side B — do not speak the same language by default. Without a shared standard, every inter-agent integration requires an ad hoc translation layer that is non-reusable and fragile whenever either agent evolves. A2A provides the minimal contract: transport (HTTP/JSON-RPC 2.0), task lifecycle, agent discovery, and declared authentication.
In short: MCP is the interface between an agent and its tools (calculator, database). A2A is the interface between agents that subcontract work to each other. Both are complementary: an agent can use MCP internally to do its job and A2A to talk to another agent.
MCP does not solve this problem. It defines how an agent queries a tool or data source —
the scope of a single agent. A2A operates one layer above: a client agent delegates a task
to a remote server agent, which can itself use MCP internally to complete it. The two protocols
are designed to coexist, not replace each other. The official documentation
(a2a-protocol.org/topics/a2a-and-mcp/) and independent analyses (Auth0, Composio,
TrueFoundry) converge on this complementarity position — with no documented contradiction
between the two specifications.
Architecture in three building blocks
The Agent Card is the entry point for any A2A exchange. Each server publishes a JSON document describing its identity, its skills, its service endpoint, and its authentication requirements (OAuth 2.0, API keys via HTTP headers). In version 0.3, these cards can be cryptographically signed — a measure that addresses agent authenticity but does not cover the full set of compliance concerns. Discovery can be done via a normalized URI (well-known), a centralized registry for enterprise deployments, or direct configuration for tightly coupled systems.
The Task is the atomic unit of work. It carries a unique identifier and passes through
explicit states: submitted → working → input-required → completed → failed → canceled. This
stateful lifecycle enables asynchronous and parallel workflows without temporal coupling
between agents. A server-generated contextId groups related tasks and preserves context
across multiple exchanges.
Interaction modes number four, selected based on latency and task duration constraints:
- synchronous request/response — short operations, complete response in a single exchange
- asynchronous polling — client receives an acknowledgment with a task ID, queries until completion
- Server-Sent Events (SSE) — persistent connection for partial results in real time
- webhooks (push notifications) — server notifies a callback URL registered by the client
The client does not need to know the server’s internal implementation. This deliberately opaque design reduces dependencies and allows each agent to evolve independently. The outputs produced by an agent (Artifacts in A2A terminology) are composable into parts (text, files, JSON) and streamable incrementally via SSE.
In short: only three pieces to remember. An ID card (Agent Card), a service request (Task) with its lifecycle submitted → in progress → completed, and a choice of channel (synchronous, polling, streaming, webhook) depending on whether the task lasts 2 seconds or 2 hours.
| Interaction mode | Typical latency | When to use it |
|---|---|---|
| Synchronous request/response | < 1 second | Simple lookup, short task (search, computation). |
| Asynchronous polling | Seconds to minutes | Medium-length task, the client can poll periodically. |
| Server-Sent Events (SSE) | Continuous streaming | Long generation with partial results (writing, analysis). |
| Webhooks | Hours to days | Very long task, the server calls back when it is done. |
Timeline and governance
Google announced A2A on April 9, 2025 with 50+ partners at launch: Atlassian, Box, Cohere, Intuit, LangChain, MongoDB, PayPal, Salesforce, SAP, ServiceNow, UKG, Workday. At Google I/O 2025 (May), version 0.2 appeared with an official Python SDK and OpenAPI-style authentication support. Google’s Agent Development Kit (ADK) integrates A2A natively — the Python ADK v1.0.0 was declared production-ready on that occasion.
In June 2025, Google transferred the protocol to the Linux Foundation at the Open Source Summit North America. The Technical Steering Committee includes IBM, Google, Microsoft, AWS, Cisco, Salesforce, and SAP. In August 2025, IBM’s ACP protocol (BeeAI), architecturally similar (JSON-RPC over HTTP/WebSockets, dedicated control plane for dynamic discovery), officially merged into A2A. [UNVERIFIED: concrete architectural influence of IBM’s contributions on the A2A specification post-merger — no source documents the deltas]
Version 0.3 adds gRPC support in addition to SSE, cryptographic signing of Agent Cards, and an extended client SDK. Anthropic is not a member of the A2A TSC. [UNVERIFIED]
Security: documented deficits
Two arXiv papers (2505.12490, 2505.02279) and the Cloud Security Alliance threat modeling (MAESTRO framework, April 2025) identify structural vulnerabilities.
Prompt injection: A2A endpoints exposed to the Internet are vulnerable if implementations do not treat inputs as untrusted. The fact that the expected clients are themselves LLMs aggravates the risk — models are susceptible to following instructions injected in messages received from remote agents.
Long-lived credentials: a systemic weakness in distributed architectures. A compromised long-lived token opens unauthorized access between agents. Agent Card signing in v0.3 partially reduces the attack surface without covering this vector.
Compliance: [UNVERIFIED — single source] A2A v0.3 would not natively provide mechanisms for regulations such as PSD2: no native transaction logging, no consent auditing. The concrete OAuth2/OIDC flows within A2A are not detailed in the secondary sources available.
In short: A2A sets the communication standard, not agent security. If you deploy an A2A agent exposed to the Internet, you inherit the same risks as a public API — injection, stolen credentials, abuse — with the added specificity that the client is another LLM that can be manipulated via prompt injection.
Limits of current adoption
Examples documented in the literature focus on Google’s demos (codelabs, ADK) and stock information systems. Third-party implementations (LangChain, ServiceNow, Salesforce) cited as partners are not detailed in the sources collected. Large-scale production stability remains untested (arXiv:2505.02279).
[UNVERIFIED — single source]: “there are not many A2A implementations in production currently” and “A2A likely benefits aggregators and foundational model providers more than individual SaaS applications.”
A competing protocol, ANP (Agent Network Protocol), is cited in arXiv:2505.02279 but is not covered by the available sources — its positioning relative to A2A remains undocumented. [UNVERIFIED]
What to remember
A2A standardizes the communication layer that MCP does not cover: direct task delegation between heterogeneous AI agents, across different frameworks and separate servers. The protocol relies on HTTP/JSON-RPC 2.0, publishes agent identity via Agent Cards, and supports four interaction modes suited to varying latency constraints. Linux Foundation governance and the merger with IBM’s ACP reduce the risk of standard fragmentation — the major players (Google, IBM, Microsoft, AWS, Cisco) sit on the same TSC.
Points of vigilance remain: the security of endpoints exposed to prompt injection, long-lived credentials in distributed architectures, and the absence of production deployment feedback at scale beyond Google’s official demonstrations.