Dora NodaIn April 2025, Google proposed a protocol for something the industry had been duct-taping for a year: letting two AI agents built by different vendors hand work to each other without a custom integration for every pairing. Twelve months later, that protocol — Agent-to-Agent, or A2A — counts more than 150 supporting organizations, ships a stable v1.0 specification, and runs inside Azure AI Foundry, Copilot Studio, and Amazon Bedrock. The single most misunderstood thing about that milestone is what it means next to MCP. Here is the verdict up front, with the evidence below:
MCP connects an agent downward to tools and data. A2A connects agents sideways to each other as peers. They are complementary halves of one stack, not competitors — and for a platform deciding where to invest, the rule is simple: one agent doing the whole job needs MCP; two agents from different vendors coordinating one job need A2A on top. The comparison table in the third section and the three-agent deploy walkthrough in the fifth show exactly where each wire runs.
The news in 60 seconds: A2A's first year
The timeline is compact enough to hold in one hand. Google announced A2A in April 2025 and donated it to the Linux Foundation in June 2025, seeded with AWS, Cisco, Microsoft, Salesforce, SAP, and ServiceNow. On April 9, 2026, the Linux Foundation marked the one-year point: supporting organizations had tripled from just over 50 to more than 150, the core repository had passed 22,000 GitHub stars, and the SDK ecosystem had grown from a single Python implementation to five production-ready languages — Python, JavaScript, Java, Go, and .NET.
The technical anchor of the announcement was v1.0, the protocol's first stable specification. It introduced multi-protocol support (one agent can advertise JSON-RPC, REST, and gRPC endpoints in priority order), enterprise-grade multi-tenancy, modernized security flows, signed Agent Cards for cryptographic identity verification, and a defined migration path for early adopters. The stated design goal was a web-aligned architecture: familiar security and load-balancing patterns so the protocol survives contact with high-scale production traffic.
The cloud embeddings followed the spec, not the hype. Microsoft integrated A2A into Azure AI Foundry and Copilot Studio; AWS added support through Amazon Bedrock AgentCore Runtime, then extended its DevOps Agent in June 2026 with custom SRE agents reachable headlessly over both MCP and A2A.
Reported production use spans supply chain, financial services, insurance, and IT operations — unglamorous verticals where cross-vendor coordination, not demos, is the requirement. As Google Cloud's Rao Surapaneni put it in the anniversary release, the momentum moved the project into production-ready use, letting "disparate AI systems work together across environments" instead of scaling through siloed, custom-built connections.
Two adjacent facts complete the picture. First, A2A's scope has started growing an economic layer: the Agent Payments Protocol (AP2), with 60-plus organizations behind it, extends agent coordination into secure, agent-driven transactions. Second, A2A and MCP now sit under the same Linux Foundation stewardship, and a joint MCP/A2A interoperability specification is on the roadmap — the standards bodies themselves are treating "both, composed" as the end state.
A2A vs MCP: the table
Before the mechanism, the boundary. Almost every confused architecture discussion in 2026 comes from assigning one protocol the other's job, so here is the split dimension by dimension:
| Dimension | MCP | A2A |
|---|---|---|
| Purpose | Agent calls a tool or data source | Agent delegates a task to another agent |
| Direction | Vertical: model downward to capability | Horizontal: peer to peer across agents |
| Who is opaque? | The tool is dumb; the agent holds all the reasoning | Both sides are full agents (LLM plus tools); neither sees the other's internals |
| Discovery | Tool manifest: what functions exist, what schemas they take | Agent Card: a signed JSON document advertising who the agent is, what skills it offers, and which endpoints to reach it on |
| Lifecycle primitives | Invoke, read, subscribe: call-and-response with tools | Task-based: send a task, poll its status, stream updates, cancel it, collect result artifacts |
| Auth model | Client authenticates to a server it chose to install | Each card declares its own scheme — OAuth2, API key, mTLS — because the caller didn't choose the peer |
| Failure shape | A tool errors; the agent retries or routes around it | A peer goes silent mid-task; the protocol needs status, timeouts, and cancellation as first-class concepts |
| Canonical example | "Query the Postgres replica for last week's deploys" | "Ask the compliance agent on another platform to approve this deploy, then tell me" |
Read any single row and the design logic lands. MCP assumes one side is infrastructure you installed and trust — you picked the server, so a shared session is fine. A2A assumes the opposite: the peer was built by another team, on another framework, behind another trust boundary. That is why discovery is a signed, fetchable card rather than a config file, why tasks have lifecycles instead of calls having responses, and why auth is declared per peer instead of negotiated once.
Forcing MCP to do delegation means re-inventing task state inside tool calls; forcing A2A to do tool access means wrapping every function call in a task lifecycle it doesn't need. The industry spent 2026 standardizing both precisely so nobody has to make that mistake twice.
How A2A actually works: three moving parts
Strip away the press releases and A2A is three mechanisms, each solving one consequence of "the peer is opaque and untrusted":
1. Signed Agent Cards for discovery. Before any call, the calling agent fetches the peer's card — a JSON document at a well-known URL listing the agent's name, skills, and supported transports, now cryptographically signed in v1.0 so identity is verifiable rather than asserted. This is the standard replacement for hard-coding against a peer's API or guessing from its docs: the card is how a calling agent learns what you do before any call is made.
2. A task lifecycle, not request-response. The core verbs are task-shaped: send a task, get its status, list tasks, cancel a task, with streaming updates while it runs. Delegation is long-lived and interruptible — the exact semantics a deploy approval or a multi-step rollout needs, and the exact semantics plain tool calls lack. Results arrive as artifacts attached to the task, so the delegating agent never inspects the peer's memory, prompts, or tools.
3. Transport negotiation with per-card auth. A single card can advertise JSON-RPC 2.0, REST/HTTP+JSON, and gRPC endpoints in priority order, with custom bindings (WebSocket is the spec's worked example) available in v1.0. Each peer declares its own authentication, because in a cross-vendor world there is no shared session to inherit. The web-aligned bet is deliberate: standard TLS, standard load balancers, standard OAuth flows — nothing exotic for the platform team to operate.
Note what the three parts share: every one of them exists because the two sides don't share code, memory, or an operator. Same-framework subagents on one orchestrator need none of this — shared state already answers discovery, lifecycle, and auth. A2A earns its complexity exactly at the organizational boundary.
Worked example: three agents ship one deploy
Concretely, here is the future the TODO item sketches — one agent drafts the change, another approves, a third executes — with each wire labeled:
- Draft (agent-internal). A planner agent in the developer's chat turns "roll back the canary, it regressed p99" into a change plan: target service, image tag, rollout strategy. No protocol involved yet — this is one agent reasoning with its own tools.
- Delegate for approval (A2A). The planner fetches the policy agent's signed Agent Card — a service run by a different team, on a different framework — and sends it a task: the plan plus the evidence (metrics snapshot, diff). The policy agent works opaquely, streams status, and returns an approval artifact: signed, timestamped, referencing the exact plan hash it reviewed. If the plan changes, the approval doesn't transfer — the task model makes that natural.
- Execute (MCP). The planner hands the approved plan to an executor agent — or acts itself — which calls tools over MCP: push the tag, trigger the rollout, watch health checks, query logs. Every one of these is agent-to-tool: the git host, the deploy API, and the metrics store are infrastructure the platform installed, not peers to negotiate with.
- Report back (A2A). The executor's result becomes an artifact on the original task: deployed, verified, p99 recovered — or failed with logs attached for the planner to re-plan against.
Count the wires: two A2A handoffs (delegate, report) and a fan of MCP calls (every action). That ratio is the whole architecture.
A2A carries intent, approval, and accountability across trust boundaries; MCP carries commands downward into machinery. Delete A2A from this picture and the approval becomes a Slack message a human pastes back in — which is, tellingly, exactly how most teams do it today. Delete MCP and every tool call becomes a task delegation to a single-function "agent," which is pure overhead.
The roadmap verdict: does deploy-from-chat need A2A yet?
Apply the decision rule honestly and it cuts both ways — which is what makes it a rule instead of a slogan:
While one agent owns the whole deploy, MCP alone suffices. A single-agent deploy-from-chat flow — user describes intent, the agent plans, calls the platform's deploy/status/log tools, and reports back — never crosses a vendor or trust boundary. Every peer is a tool the platform chose. Adding A2A here buys task envelopes around calls that don't need them: scope creep with a standards badge on it. The right first build is the MCP surface itself — machine-readable infrastructure state (apps, deploys, health, logs) exposed as tools any agent can drive.
A2A earns its place at three precise triggers. First, when the drafting agent and the executing agent come from different vendors — the user plans in their IDE assistant but execution lives in the platform's agent, and neither side will surrender its stack. Second, when approval must cross a trust boundary with independent auditability — a compliance agent that must verify the exact plan hash, not take the deployer's word for it. Third, when delegation is long-lived enough to need the lifecycle — multi-step rollouts where the delegator must poll, stream, or cancel across hours, not seconds.
Until at least one trigger fires, A2A-shaped work is premature.
There is, however, one cheap hedge worth taking now: keep the agent-facing surfaces A2A-shaped even before adopting the protocol. Discoverable capability descriptions instead of tribal knowledge, task-shaped handoffs (intent plus evidence in, artifacts out) instead of chat-shaped ones, approvals bound to plan hashes. If those shapes hold, adding A2A later is a transport swap, not a redesign. If they don't, no protocol will save the integration.
The industry trajectory supports sequencing over skipping. AWS's DevOps Agent already demonstrates the composed end state — custom SRE agents coordinated over A2A, acting through MCP tools — and the joint interop spec on the standards roadmap says the two protocols are converging on composition, not consolidation. Build the tool layer first, hold the handoff shapes steady, and adopt the peer layer when a second vendor enters the deploy path. That is what "betting on both" actually means: not two integrations on day one, but an architecture where the second one fits when its trigger fires.
Outlook
A2A's year-one numbers — 150-plus organizations, a stable spec, native cloud embeddings — mark the moment agent-to-agent coordination stopped being a framework feature and became infrastructure. The interesting work now moves up a layer: the registry problem (how agents find trustworthy cards at scale), the interop spec that makes MCP tools and A2A peers compose cleanly, and the payments layer that lets delegation carry money as well as intent.
Platforms that expose their machinery as tools today, with handoffs shaped like tasks, will plug into that infrastructure when it matures. The ones that hard-code every pairing will be re-wiring by hand — at exactly the moment everyone else stops thinking about wiring at all.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
