The short version, up front: if you run a single agent, you don't need A2A yet. It's agent-to-agent plumbing, and it only pays off once your product hands a task to an agent you don't control. What changed in 2026 is that the plumbing became standard — Google, Microsoft, and AWS all speak the Agent2Agent protocol natively — so when you do need cross-vendor delegation, you wire it once instead of building three bespoke bridges. Below is the line for a team of one.
What A2A is (in one paragraph)#
A2A (Agent2Agent) is an open protocol for one autonomous agent to discover, message, and delegate work to another autonomous agent — including agents built by a different team, on a different framework, run by a different company. Each agent publishes an Agent Card describing what it can do; a peer reads the card and hands it a task, which carries its own lifecycle (submitted, working, completed) rather than being a single blocking call. It is governed by the Linux Foundation under the Agent2Agent project.
What actually changed#
At its one-year mark on April 9, 2026, the Linux Foundation reported that A2A had crossed 150 supporting organizations and — the material part — that it's now embedded natively in all three major clouds:
- Google Vertex AI — Google originated A2A and bakes it into its agent platform.
- Microsoft Azure AI Foundry and Copilot Studio — first-class A2A support for building and connecting agents.
- AWS Bedrock AgentCore Runtime — A2A as a supported protocol for agent-to-agent communication.
On top of that, LangGraph and CrewAI ship native A2A support, and a companion Agent Payments Protocol (AP2) — for secure, agent-driven transactions — has 60+ organizations behind it. Adoption now spans supply chain, financial services, insurance, and IT operations.
Native cloud support is what turns a protocol from a spec you could implement into a default you'd have to work to avoid.
The decision: when a founder actually needs it#
Use this line. It's binary, and it saves you from adopting a standard before it earns its keep.
You do NOT need A2A when:
- You run one agent. A single agent that calls tools wants MCP, not A2A. (See A2A vs MCP for the boundary.)
- Your "multiple agents" are really subagents inside one system you own end to end — your framework's own orchestration handles that; you don't need an inter-vendor protocol to talk to yourself.
- You're pre–product-market-fit and every hour of glue code is an hour not spent on the core loop.
You DO need A2A when:
- Your product delegates a task to an agent you don't own — a partner's agent, a customer's in-house agent, or a marketplace of third-party agents.
- You're selling an agent that other companies' agents should be able to call — publishing an Agent Card is how you get discovered and invoked.
- You operate across two of the three clouds and want agents on each to coordinate without you writing the bridge.
If none of those is true today, note the date you expect one to become true, and move on. Adopting A2A early costs you a surface to maintain for a capability nobody's calling yet.
Why this isn't an MCP-vs-A2A fight#
The common confusion is treating these as rivals. They're perpendicular:
- MCP is the vertical connection — one agent reaching down to its tools, data, and resources.
- A2A is the horizontal connection — one agent reaching across to another agent as a peer.
A mature system runs both: MCP inside each agent so it can act, A2A between agents so they can delegate. Getting MCP right is the near-term work for almost every founder — especially with the stateless 2026-07-28 spec locking this week. A2A is the layer you reach for when your ambitions cross a boundary you don't own.
How to adopt it minimally, when the time comes#
Don't rebuild anything. When you hit a real cross-vendor delegation:
- Expose, don't rewrite. If you're already on Vertex AI, Azure AI Foundry, or Bedrock AgentCore, turn on its native A2A surface and publish an Agent Card describing what your agent does. The runtime handles the protocol.
- Consume one peer, read-only first. Wire a single inbound or outbound delegation and keep it one-directional until you trust it.
- Add AP2 only if money moves. If your agents transact on a user's behalf, layer in the Agent Payments Protocol; otherwise it's not your problem yet.
- Keep MCP as your tool layer. A2A carries the task between agents; MCP still carries the tool calls inside each one.
The takeaway for a team of one: A2A being in all three clouds is a future-proofing win, not a to-do item. It means the day you need cross-vendor agent delegation, the hard part is already done — you're turning on a standard, not inventing a bridge. Until that day, spend the hour on MCP.
