Google's A2A Protocol for Product Managers: What It Is and Why It Changes Multi-Agent Architecture
TL;DR
Google's Agent-to-Agent (A2A) protocol is an open standard that lets AI agents built by different vendors discover each other, delegate tasks, and coordinate work across organizational boundaries. By May 2026 it has 150+ organizational backers including AWS, Azure, Salesforce, SAP, and Workday — making it the de facto standard for multi-agent interoperability. For AI PMs, A2A is not a nice-to-have: it's the architectural decision that determines whether your agentic product works with the enterprise ecosystem or gets routed around. This article explains how it works, how it differs from MCP, and what it means for your product roadmap.
What A2A Is and Why It Exists
Google announced the Agent-to-Agent (A2A) protocol in April 2025 to solve a specific problem: AI agents built on different platforms couldn't talk to each other. If a Salesforce Einstein agent needed to delegate a task to a ServiceNow agent, there was no standard way to do it — each integration was custom, brittle, and expensive to maintain.
A2A fills the gap that MCP (Model Context Protocol) deliberately left open. MCP — the Anthropic-originated standard — handles one direction: connecting an agent to tools, APIs, and data sources. MCP says 'here is how an agent reaches out to call a tool.' A2A handles the other direction: connecting agents to other agents. A2A says 'here is how Agent A tells Agent B to do something and gets a structured result back.'
In one year the protocol went from a Google proposal to a Linux Foundation project with 150+ organizational members. Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud have all integrated A2A natively into their platforms. This is not a Google-specific standard anymore — it's the OSI model of the multi-agent era.
Why this moved so fast
Enterprise buyers drove adoption harder than the vendors expected. Once a large bank, insurer, or manufacturer realized their AI strategy required agents from Salesforce, ServiceNow, and SAP to collaborate without custom plumbing, A2A became a procurement requirement. Vendors without A2A support started losing enterprise deals. That accelerates a standard faster than any technical argument.
How A2A Works: The Technical Mechanics
You don't need to implement A2A — your engineering team does. But understanding the mechanics shapes your product decisions.
Agent Card
Every A2A-compatible agent publishes a JSON document called an Agent Card at a well-known URL (/.well-known/agent.json). The card advertises the agent's capabilities, skills, input/output schemas, and authentication requirements. Think of it as an API spec written for agent consumption, not human consumption.
Tasks
Work is exchanged as structured Task objects with a defined lifecycle: submitted, working, input-required, completed, failed, canceled. A calling agent can poll the task status, stream progress via Server-Sent Events, or receive a webhook callback when done. This lifecycle model is why agentic systems can handle long-running tasks that take minutes or hours — unlike a typical API call.
Transport
A2A runs over standard HTTP with JSON-RPC 2.0 as the message format. Streaming uses Server-Sent Events (SSE). There is nothing proprietary in the wire protocol — any system that can make HTTP requests can participate. This was a deliberate choice to maximize enterprise compatibility with existing network infrastructure.
Authentication
A2A defers authentication to existing enterprise standards: OAuth 2.0, API keys, mTLS. The Agent Card specifies which schemes are supported. This means your enterprise identity provider (Okta, Azure AD, Ping) already speaks A2A — there is no new identity layer to deploy.
Parts and Artifacts
Task payloads can contain Parts — typed data chunks that are text, file references, or structured data. Task outputs are Artifacts — the structured results an agent returns. This content model allows agents to exchange rich multi-modal data, not just strings.
MCP vs A2A: The Two Protocols Every AI PM Must Understand
The confusion between MCP and A2A is real — most engineering teams conflate them. Here is the one-sentence distinction: MCP is for agents talking to tools; A2A is for agents talking to agents. Both are needed. They are complementary, not competing.
| Dimension | MCP | A2A |
|---|---|---|
| What it connects | Agent to tool, API, or data source | Agent to agent |
| Who owns the standard | Anthropic (originally) | Linux Foundation (donated by Google) |
| Interaction model | Request/response to a tool | Task delegation with lifecycle tracking |
| Authentication | Tool-specific schemes | Enterprise OAuth/mTLS/API keys |
| Long-running tasks | Not native (synchronous bias) | Native via SSE streaming and task lifecycle |
| Enterprise adoption | Very high — every major LLM provider | High and accelerating — 150+ orgs |
| PM implication | Your agent's tool integrations | Your agent's ecosystem partnerships |
A full enterprise agent stack uses both. MCP connects your agent to your company's internal tools (CRM, databases, document stores). A2A connects your agent to partner agents (a logistics provider's agent, a bank's payment agent, a vendor's fulfillment agent). Think of MCP as the internal API layer and A2A as the B2B integration layer.
Build AI Products on the Right Architecture
The AI PM Masterclass covers multi-agent architecture, protocol selection, and how to make build-vs-integrate decisions — taught live by a Salesforce Sr. Director PM who's shipped agent products at enterprise scale.
What A2A Means for Your Product Architecture
A2A changes several product decisions you would previously have treated as engineering-only concerns.
Agent discovery vs hardcoded integrations
Without A2A, integrating with a partner agent meant a bespoke engineering project. With A2A, a partner agent publishes an Agent Card and your agent can discover its capabilities programmatically. Product implication: your roadmap for new agent partnerships shrinks from quarters to weeks. But you now need to define a policy for which third-party agents your product will trust and invoke.
Authentication and authorization scope
When your agent delegates to a third-party agent via A2A, that agent acts on behalf of your user. What permissions does it get? What data can it see? A2A delegates authentication decisions to you — but you have to make them deliberately. PMs who leave this to engineering end up with agents that overshare user data. Define a minimal-permission policy for every A2A integration you authorize.
Task ownership and auditability
A2A tasks have full lifecycle tracking. Every task your agent creates — or accepts from another agent — generates a structured audit trail. For enterprise buyers in regulated industries (finance, healthcare, legal), this is a selling point. For consumer products, it's an operational hygiene requirement. Build the log retention and export capability your compliance team will ask for before they ask for it.
Failure modes are now distributed
When your agent delegates to an external agent via A2A, that external agent can return failed, input-required, or simply time out. Your product needs graceful degradation paths for all three. The user experience of a distributed agent failure is much harder to design than a simple API timeout. Map the failure tree before engineering builds the happy path.
The 2026 A2A Adoption Landscape
The speed of A2A adoption tells you something about its strategic importance. In April 2025 it was a Google proposal. By May 2026 it is a Linux Foundation project with production deployments at major enterprises. Here is where the adoption is concentrated:
Cloud platform integration
Azure AI Foundry, Amazon Bedrock AgentCore, and Google Cloud have all integrated A2A natively. If your product runs on any of the three major clouds, you already have A2A infrastructure available. You don't need to build the protocol — you need to decide how to use it.
Enterprise software ecosystems
Salesforce, SAP, ServiceNow, Workday, and IBM are all A2A backers with production implementations. If your product sells into enterprises that run these platforms, A2A compatibility is a near-term procurement checkbox. Evaluate your top 10 enterprise accounts — are any running A2A-compatible orchestrators already?
Vertical concentrations
Supply chain, financial services, insurance, and IT operations have the deepest A2A production deployments as of 2026. These verticals share a common characteristic: multi-system workflows where no single vendor owns the full process. A2A lets them automate across vendor boundaries without giving any one vendor full workflow control.
What is not yet mainstream
Consumer-facing products and developer tools have lower A2A adoption in 2026. The protocol is optimized for enterprise service-to-service communication, not end-user-facing experiences. If your product is consumer-focused, A2A is on your 2027 horizon, not your 2026 sprint backlog.
What AI PMs Should Do With This Now
Most AI PMs in 2026 have read about A2A but haven't translated it into product decisions. Here is a concrete action list:
Audit your agent integration map
List every system your agent integrates with. For each integration, ask: is this vendor A2A-compatible? If yes, is your integration already using A2A or custom HTTP? Custom integrations are technical debt — flag them for migration in the next major release cycle.
Add A2A compatibility to your vendor scorecard
When evaluating new AI infrastructure vendors, add A2A compatibility as a requirement. Not a nice-to-have — a gate. An AI platform that doesn't support A2A in 2026 is betting against the industry standard. Weight it accordingly.
Define your agent trust policy
Which external agents is your system allowed to invoke? Which external agents are allowed to invoke yours? Write this as a one-page policy document before engineering makes the decisions by default. The answer should be deliberate, not accidental.
Identify one A2A integration for your 2026 roadmap
Pick one high-value integration that A2A enables — a partner's agent, a platform's native agent, a cloud provider's orchestration agent. Size the user value, scope the engineering work (smaller than you think now that the protocol exists), and put it in the roadmap. The first A2A integration teaches your team more than any amount of reading.
Read the A2A spec once
The A2A specification at a2a-protocol.org is 20 pages. Read it. Not to implement it — to understand what engineering is building. PMs who have read the spec ask better questions in architecture reviews and catch product edge cases that pure engineers miss.
Ship Multi-Agent Products That Work in the Real Enterprise
The AI PM Masterclass covers agentic architecture, protocol selection, and how to build products that integrate with the enterprise AI ecosystem — not just demos that run in isolation.