Google's A2A Protocol: Cross-Vendor Agent-to-Agent Interoperability in 2026

In April 2025, Google announced the Agent2Agent (A2A) protocol — an open standard for AI agents built by different vendors, on different frameworks, running on different servers to discover each other and collaborate as peers. Fifteen months later, A2A has reached version 1.0, been donated to the Linux Foundation’s Agentic AI Foundation (AAIF), and reportedly garnered support from 150+ organizations including Microsoft, AWS, Salesforce, SAP, and ServiceNow. It is, by most measures, the leading open protocol for inter-agent communication.

A2A’s architectural proposition is straightforward but ambitious: complement Anthropic’s Model Context Protocol (MCP) — which connects agents to tools and data — by standardizing how agents talk to each other across organizational boundaries. Where MCP is the “USB-C for AI integrations” (one agent plugging into many tools), A2A is the protocol that lets a Salesforce agent delegate a task to a ServiceNow agent without either side exposing its internal prompts, reasoning traces, or tool implementations.

But the gap between A2A’s adoption narrative and its production reality is wide. An empirical probe of 50 publicly listed agents claiming A2A support found that 0% responded to a correctly formatted A2A request. The “150+ organizations” figure measures support-signups, not production deployments. Security researchers have demonstrated working attacks where malicious agents inject instructions across A2A sessions to exfiltrate data and execute unauthorized trades. And the semantic layer — what agents actually mean when they communicate — remains unsolved, just as it was for SOAP, CORBA, and every prior interop protocol.

This report examines A2A from seven perspectives: its technical architecture, its relationship to MCP and framework-level orchestration, the practitioner experience, enterprise deployment realities, the ecosystem strategy, its security implications, and the historical lessons that predict its trajectory.

The Architecture: How A2A Works Under the Hood

Three-Layer Protocol Design

A2A is structured into three specification layers, a separation that ensures new transport bindings can be added without changing the core data model:

• Layer 1 — Canonical Data Model: All protocol objects are defined as Protocol Buffers messages in a single file (a2a.proto). This is the normative source — all SDKs, JSON schemas, and derived forms MUST be generated from it.
• Layer 2 — Abstract Operations: Eleven binding-independent operations: SendMessage, SendStreamingMessage, GetTask, ListTasks, CancelTask, SubscribeToTask, plus push-notification configuration operations.
• Layer 3 — Protocol Bindings: These operations map to concrete transports: JSON-RPC 2.0 over HTTP(S), gRPC over HTTP/2, and HTTP+JSON/REST.

This is a familiar pattern from distributed systems history — CORBA separated IDL from wire protocol, SOAP separated WSDL from transport, and A2A separates protobuf definitions from JSON-RPC/gRPC bindings. The difference is that A2A uses modern, web-native primitives rather than inventing its own encoding format.

Agent Cards: The Discovery Mechanism

Every A2A server MUST publish an Agent Card — a JSON metadata document at /.well-known/agent-card.json. The card is the agent’s digital business card, declaring identity, supported interfaces (protocol bindings and URLs), capabilities (streaming, push notifications), security schemes (OAuth2, API key, mTLS, OpenID Connect), and skills (each with id, name, description, tags, and input/output MIME types).

In v1.0, Agent Cards MAY be digitally signed using JSON Web Signature (JWS, RFC 7515) with canonicalization via JSON Canonicalization Scheme (JCS, RFC 8785). However — and this is critical — the JWS signature proves only that a key holder signed this card. It does not prove who the key holder is. The spec does not specify how a verifier should resolve, validate, or trust the key. A2A’s own GitHub issue #1672 acknowledges: “identity verification is currently left to external mechanisms.”

Task Lifecycle: A State Machine for Long-Running Work

The Task is A2A’s core unit of work. Its state machine has nine states:

Figure 1 — The A2A task state machine. Once a task reaches a terminal state, it cannot restart. Follow-up interactions create a new task within the same contextId for multi-turn conversational continuity.

Once a task reaches a terminal state, it cannot restart. Follow-up interactions must create a new task within the same contextId — a server-generated identifier that logically groups tasks into conversational sessions. This is a significant departure from MCP, which went stateless at the protocol layer in its 2026-07-28 release candidate. A2A remains deliberately task-stateful, reflecting its focus on long-running collaborative work between autonomous agents.

Streaming and Authentication

When an agent declares streaming capability, clients use SendStreamingMessage. The server responds with Server-Sent Events (SSE), and each event contains a StreamResponse — a protobuf oneof wrapper with task, message, statusUpdate, or artifactUpdate variants. The stream MUST close when the task reaches a terminal state.

Authentication is at the HTTP transport layer — identity is NOT transmitted within JSON-RPC payloads. The Agent Card declares security schemes (API key, HTTP auth, OAuth2 with PKCE/Device Code, OpenID Connect, mTLS). For in-task authorization, an agent transitions the task to AUTH_REQUIRED, forming a chain of authorization delegation across multiple agents.

The protocol deliberately does not define how authorization must be performed. Token lifetime is not enforced. There is no user-consent-required task state. These gaps are examined in detail in the Security section.

The Layering Model: A2A, MCP, and Frameworks

The interoperability landscape in 2026 has a three-tier layering model:

Figure 2 — A2A, MCP, and frameworks occupy different layers of the agent stack. A2A handles cross-system agent-to-agent communication, MCP handles agent-to-tool integration, and frameworks handle within-system orchestration.

Within-system orchestration is handled by frameworks like LangGraph (stateful directed graphs with checkpointing), CrewAI (role-based crews with sequential/hierarchical processes), and OpenAI Agents SDK Handoffs (same-process control transfer). These manage internal control flow and shared state within one codebase.

Cross-system communication is A2A’s domain. Agents built by different vendors discover each other via Agent Cards and delegate tasks via JSON-RPC. The key architectural property is opacity — remote agents operate as black-box systems whose internal workings, memory, and tools are not exposed. This is what makes A2A usable across organizational boundaries.

Agent-to-tool integration is MCP’s domain. Each agent uses MCP internally to connect to its own tools and data sources.

How Frameworks Bridge to A2A

As of mid-2026, both major Python multi-agent frameworks have integrated A2A directly:

• Google ADK: to_a2a(agent, port) — a single function call that auto-generates the Agent Card and returns a Starlette ASGI app
• LangGraph: auto-exposes every assistant at /a2a/ with an auto-generated Agent Card — zero configuration needed
• CrewAI: A2AServerConfig and A2AClientConfig for exposing and consuming A2A agents
• OpenAI Agents SDK: wraps external A2A calls as custom tools

The Contested Boundary

The official positioning is that A2A and MCP are fully complementary and non-overlapping. However, this clean separation is contested. Solomon Hykes (Docker founder) publicly questioned it: “In theory they can coexist, in practice I foresee a tug of war. Developers can only invest their energy into so many ecosystems.” The A2A documentation itself acknowledges that “an A2A server could expose some of its skills as MCP-compatible resources.” The boundary is a design philosophy choice, not a hard architectural constraint.

The Developer Experience: Building with A2A + MCP

Google ADK: The Best DX

Google’s Agent Development Kit provides the most streamlined A2A developer experience. Exposing an ADK agent as an A2A server is a single function call:

1
from google.adk.a2a.utils.agent_to_a2a import to_a2a
2

3
agent = Agent(
4
    name='travel_agent',
5
    tools=[McpToolset(
6
        connection_params=StreamableHTTPConnectionParams(
7
            url='https://mapstools.googleapis.com/mcp',
8
        ),
9
    )],
10
)
11
a2a_app = to_a2a(agent, port=8001)  # One line: A2A server with MCP tools

On the consumer side, RemoteA2aAgent wraps a remote A2A agent as a local ADK sub-agent — the developer treats the remote agent exactly like a local one. The class transparently handles card resolution, message serialization, task state tracking, and response parsing.

Framework DX Comparison

Verdict: Google ADK provides the best overall DX for A2A + MCP combined systems. LangGraph is the best choice for teams already invested in the LangChain ecosystem. CrewAI is suitable for simpler, single-purpose agents.

Enterprise Deployment: Who’s Actually Using It

Platform-Level Integrations

The Linux Foundation’s April 2026 press release identifies concrete platform integrations rather than end-customer deployments:

• Microsoft embedded A2A into Azure AI Foundry and Copilot Studio
• AWS added support via Bedrock AgentCore Runtime, with a published serverless A2A gateway reference architecture
• Google Cloud provides managed Agent Runtime with A2A on Cloud Run

Vendor Implementations

• Salesforce Agentforce 3: Built-in A2A + MCP. MuleSoft Agent Fabric scanners went GA January 2026
• ServiceNow Now Assist (Dec 2025): Bidirectional A2A — both server and client modes, configuration-driven
• SAP: A2A + MCP adopted for BTP/Joule, but Agent Gateway not yet GA (outbound only as of mid-2026)

Production Failure Patterns

A detailed deployment series documented five concrete production failures:

1. SSE buffering on Nginx — missing proxy-buffering: off caused tasks to hang (4 hours to diagnose)
2. Task zombies — error handler exceptions left tasks stuck in working state with open streams
3. JWKS cache staleness — stale keys after rotation caused all requests to return 401 for ~20 minutes
4. In-memory task store across workers — tasks invisible across uvicorn workers (silent data loss)
5. Cold-start latency — 6-second cold starts on scale-to-zero

The Adoption Reality

Figure 3 — A2A’s first year: from Google launch to 150+ organizations. But the gap between “supporting” and “in production” remains wide.

The “150+ organizations” figure requires careful interpretation. The Linux Foundation press release says “more than 150 organizations supporting the standard” — not “in production.” A public partner list exists on GitHub with ~155 named organizations. Joining requires filling out a Google Form — it is a statement of support, not evidence of deployment.

A Harvard Business Review survey of 603 technology leaders found that only 6% of companies trust AI agents to autonomously manage core business processes. The gap between 150 organizations “supporting” A2A and 6% trusting agents for real work is 66 percentage points. As one analyst put it: “Support for a standard is free. Budget commitment is not.”

An empirical probe by the OpenClaw research project tested 50 agents from public directories that explicitly advertised A2A support. Results: 100% claimed A2A support, but only 0–4% returned a valid Agent Card, and 0% responded to a correctly formatted A2A request. This finding is narrowly scoped (public-registry agents, not enterprise deployments) and was AI-generated without independent replication. However, it catalyzed the creation of the official A2A Technology Compatibility Kit and a 111-test conformance specification.

The Ecosystem Strategy: Google’s Kubernetes Replay

The clearest strategic reading of A2A is the “commoditization playbook” Google has run before. Google open-sourced Kubernetes in 2014 to prevent any single cloud vendor from capturing infrastructure margins. A2A follows identical logic: publish the protocol, donate to the Linux Foundation within 10 weeks, and establish a layer no single vendor can own.

Google’s Open Source Programs Office has explicitly framed open source as “a deliberate competitive lever rather than an act of corporate generosity.” When Anthropic subsequently moved MCP to a foundation, Google’s OSPO reportedly described that outcome as “absolutely the point.”

The 150+ organization ecosystem has three functional tiers:

1. Cloud/infrastructure validators (AWS, Microsoft, Google, Cisco): ensure protocol neutrality so their clouds remain viable deployment targets
2. Enterprise SaaS participants (Salesforce, SAP, ServiceNow, Workday): expose AI capabilities as A2A-compatible agents so customers can orchestrate across SaaS estates
3. Professional services channel (Accenture, Deloitte, KPMG, McKinsey, PwC, TCS, Wipro): implementation revenue from digital transformation playbooks

The strategic endgame is not for Google to “own” A2A — it explicitly gave up ownership. The play is to dominate the ecosystem around A2A: influence the TSC, seed the SDKs, define the extension model, and be the preferred cloud deployment target.

Security: The Trust Problem at Cross-Vendor Boundaries

Agent Session Smuggling

Palo Alto Networks Unit 42 demonstrated “Agent Session Smuggling” — a working attack where a malicious remote agent injects covert instructions into a victim client agent during legitimate A2A sessions. Using Google’s ADK with Gemini, a malicious “research assistant” progressively tricked a “financial assistant” into exfiltrating its system prompt, tool schemas, and conversation history, then executing unauthorized stock trades — all without the user’s awareness.

The attack is more dangerous than MCP-based attacks because A2A servers are stateful, AI-powered, and can adaptively refine instructions over multiple turns.

Prompt Injection Propagation

The OWASP 2026 LLM Top 10 identifies three properties that amplify injection in multi-agent systems: context-window pooling (no enforced trust boundary), memory persistence (injections survive across sessions), and agent autonomy (injected instructions are acted upon). The Cloud Security Alliance’s “Promptware” research, co-authored with Bruce Schneier, documents full kill chains through crafted text inputs.

Key Security Gaps

• Agent Cards are unsigned by default — signing is MAY, not MUST, enabling typosquatting and impersonation
• No protocol-level prompt injection defenses — confirmed by five independent security teams
• No enforced token lifetime — leaked OAuth tokens can remain valid for hours or days
• No consent mechanism — no requirement for user approval before sharing sensitive data between agents
• Cross-vendor trust boundary exploitation — if one organization has weaker security, attackers can compromise agents in other organizations

Comparative Risk

A 2026 systematic threat modeling paper evaluated MCP, A2A, Agora, and ANP using NIST SP 800-30. A2A scored medium risk — better than MCP (high risk) because OAuth2/JWT reduces exploitability, but worse than ANP (which uses W3C DIDs for identity assurance). No protocol achieved low risk across all lifecycle stages.

Historical Parallels: Lessons from CORBA to SOAP to OAuth

The A2A pattern is not novel — it is the fourth major wave of cross-vendor interop protocols:

CORBA’s Five Lessons

Michi Henning’s landmark 2006 ACM analysis “The Rise and Fall of CORBA” documented why a technology produced by “the world’s largest software consortium” fell to “obscure niche technology” in under a decade:

1. Spec complexity kills — CORBA’s Component Model was “essentially unimplementable”
2. Versioning matters — changing a data structure broke every client; enterprises froze on ancient versions
3. Match the deployment environment — CORBA failed when firewalls locked down; A2A’s HTTP-native design avoids this
4. Cost barriers block adoption — CORBA cost thousands per seat; A2A’s open SDKs are the anti-CORBA strategy
5. Fragmentation is fatal — DCOM vs. CORBA split the market; ACP’s merger into A2A avoids this

The Semantic Gap: SOA’s Deepest Lesson

The deepest historical lesson comes from Service-Oriented Architecture. SOA gave strong interface definitions via WSDL — “On paper, it looked like interoperability. In practice, it often wasn’t.” The contract could describe the shape of a message but not its meaning.

Agent Cards describe capabilities but not semantic guarantees. An agent advertising “financial analysis” may mean very different things in different contexts. When the consumer is an autonomous agent composing operations at runtime, “a contract that was merely inconvenient for human developers can become dangerous.”

This is the unsolved problem — standardizing how agents talk is necessary but not sufficient. Standardizing what they mean is the frontier.

The Pattern: Simplicity Wins

Across all four waves, the technically inferior but operationally simpler protocol wins. CORBA’s CDR was compact and fast; SOAP was slower; REST was less efficient — each successor won because it was easier to deploy. A2A has adopted HTTP+JSON and JSON-RPC, the same “simple enough” primitives that won for REST. The risk is feature creep — each new interaction mode and security scheme adds WS-*-style complexity.

Where the Sources Disagree

Is A2A production-ready or vaporware?

Official narrative: A2A v1.0 is stable, 150+ organizations support it, major platforms integrated it. Skeptic: 0% of 50 public agents responded to an A2A request. Only 6% of companies trust agents. No end-customers named.

Reconciled read: Platform integrations are real. Vendor implementations exist. But actual cross-vendor production usage is undisclosed and likely small. A2A is early in the adoption curve — infrastructure in place, production usage nascent.

Are A2A and MCP complementary or competing?

Official: Different axes — MCP is vertical (agent→tools), A2A is horizontal (agent↔agent). Practitioners: “I foresee a tug of war.” The boundary is blurry.

Reconciled read: Architecturally clean, but the boundary is a design philosophy, not a hard constraint. Most production systems will use both. The “tug of war” is about developer attention, not technical incompatibility.

Are signed Agent Cards sufficient for identity?

Google: Signed cards provide “cryptographic verification of agent identity.” Security researchers: JWS proves a key signed the card, not who the key belongs to. Identity verification is “left to external mechanisms.”

Reconciled read: Signed cards are a necessary foundation but insufficient. The cryptographic primitive is correct; the trust infrastructure (key resolution, CA equivalent, revocation) is not yet built — the TLS-without-a-CA-ecosystem problem.

Devil’s Advocate: The Case That This Report Is Overstated

What if A2A doesn’t matter? Most production AI deployments in 2026 are single-agent systems with tools — not multi-agent swarms. If 94% of enterprises aren’t ready to trust one autonomous agent, cross-vendor agent swarms are not the bottleneck.

What if the semantic gap kills it? Practitioners report silent schema mismatches, context collapse across hops, and retry storms (one failed task: 47 LLM calls, $180 cost, 94 seconds, zero alerts). If the semantic layer cannot be solved at the protocol level — and 35 years of history suggests it cannot — A2A provides connectivity without interoperability.

What if MCP absorbs the use case? MCP has 214 million monthly PyPI downloads vs. A2A’s enterprise-focused trajectory. If MCP adds agent-to-agent patterns, the separate protocol may become redundant.

What if governance fragmentation undermines extensions? Five+ competing trust/identity proposals are active in GitHub with no TSC consensus. If trust extensions proliferate without consolidation, the interoperability promise breaks.

Open Questions and Roadmap

The official roadmap is deliberately lightweight post-v1.0, focusing on validation tooling, the extension ecosystem, and SDK alignment. The single largest area of open debate is agent trust and identity — five+ overlapping but incompatible proposals are active in GitHub issues, with no TSC consensus on whether trust should be one unified primitive or layered and composable.

Unresolved enterprise features include auth delegation in multi-agent chains, agent marketplaces and registries, standardized skill taxonomies, rate limiting, and publish/subscribe for async communication (requested since September 2025, still under TSC review after 7+ months).

A major structural debate is testing where A2A’s scope ends: should it absorb negotiation, payment signaling, and governance primitives? An arXiv paper found that none of MCP, A2A, or ACP can express governed agent communities — only task-oriented coordination.

Conclusion

A2A in July 2026 is a protocol at an inflection point. Its architectural design is sound — the three-layer specification, agent card discovery, task lifecycle state machine, and multi-transport support draw on 35 years of distributed systems lessons. The ecosystem strategy is textbook: Linux Foundation governance, three-tier partner structure, competitor consolidation, and extension platform. The developer experience, particularly via Google ADK, is genuinely good — to_a2a() and RemoteA2aAgent make cross-vendor agent delegation approachable for the first time.

But the protocol’s production reality lags its narrative. The 150+ organizations support the standard; they don’t all run it in production. The security gaps — unsigned Agent Cards, no prompt injection defenses, no consent mechanisms — are real and demonstrated by working attacks. The semantic gap that killed SOA remains unsolved: A2A standardizes how agents talk but not what they mean.

For practitioners building production multi-agent systems today, the A2A + MCP combination is the right architectural pattern — but it should be deployed with eyes open. Use A2A for cross-vendor delegation, MCP for tool access, and a framework for within-system orchestration. But add your own authorization layer (the protocol won’t provide one), use out-of-band human-in-the-loop for sensitive operations (the protocol won’t require it), and don’t trust Agent Card claims without verification (the protocol doesn’t enforce it).

A2A gives you the wire format. The trust, semantics, and governance are still yours to build.