A2A vs MCP: How Agent-to-Agent and Agent-to-Tool Protocols Differ

June 23, 2026 · Agents at Scale: The 2026 Frontier (part 3)

▶ Watch on YouTube & subscribe to The Stack Underflow

By 2026, the production default for multi-agent systems is the supervisor-worker pattern: one orchestrator agent delegates tasks to specialist agents. That raises a question most explanations quietly skip: how does one agent actually delegate to another — especially when those agents are built by different vendors, running in different clouds, on different frameworks?

Until April 2025, the honest answer was “custom glue code every time.” Then Google shipped A2A, and the picture snapped into focus. If you already know MCP, you are exactly halfway there.

The one-sentence version: MCP is the vertical protocol that connects a single agent downward to its tools; A2A is the horizontal protocol that connects agents sideways to each other — and you need both for a production multi-agent stack.

The layer confusion that trips everyone up

Before A2A existed, developers knew MCP (Model Context Protocol, shipped by Anthropic) and assumed it handled all agent communication. It does not. MCP solves one specific problem: letting a model talk to its environment — databases, file systems, APIs, browser tools. One agent, many tools. Vertical.

A2A solves a different problem: letting a supervisor agent on Anthropic’s infrastructure delegate a subtask to a research agent built on LangChain that lives in AWS, and then to a code-review agent on Azure that has never heard of the supervisor’s framework. Peer coordination across framework and vendor boundaries. Horizontal.

They are not competitors. They are different layers of the same architecture. Conflating them is like conflating HTTP and SQL because “both move data.”

┌─────────────────────────────────────────────────────┐
│              Supervisor Agent (Anthropic)            │
│                                                     │
│         A2A ──────────────── A2A                    │
│          │                    │                     │
│  ┌───────▼────────┐  ┌────────▼───────┐             │
│  │ Research Agent │  │ Code Review    │             │
│  │ (LangChain/AWS)│  │ Agent (Azure)  │             │
│  └───────┬────────┘  └────────┬───────┘             │
│    MCP ──┘                    └── MCP               │
│     │                              │                │
│  [Web Search]               [GitHub, Postgres]      │
└─────────────────────────────────────────────────────┘

A2A = horizontal (agent ↔ agent)
MCP = vertical  (agent ↓ tools)

One diagnostic question cuts through any confusion: is the connection between two agents, or between an agent and a tool? That question answers which protocol applies.

How A2A actually works

A2A is deliberately boring by design — it reuses the same web primitives that have run enterprise software for two decades. Five steps:

No exotic transport. No proprietary binary format. HTTP, JSON, OAuth — the same stack your existing API gateways already speak. That is a deliberate design choice: it means the first implementation typically takes one to two hours, and five official SDKs are available to get you there faster.

The signed agent cards added in v1.0 are worth noting: they provide cryptographic proof of who issued the card, which matters when you are delegating tasks to agents you did not build and do not fully control.

Adoption: from announcement to infrastructure in one year

Google announced A2A on April 9, 2025. The timeline after that is unusually fast for a protocol:

• June 2025 — donated to the Linux Foundation (open governance, not Google-controlled)
• August 2025 — IBM’s competing protocol ACP voluntarily merged into A2A
• April 2026 — 100+ organizations in formal support, including Google, Microsoft, AWS, Salesforce, SAP, ServiceNow, Workday, and IBM

Every major cloud now has native A2A support. ACP merging in is the tell: when your biggest rival joins you rather than fights you, the protocol has won.

The complementary picture: Anthropic shipped MCP and solved agent-to-tool. Google shipped A2A and solved agent-to-agent. Two companies, two protocols, one coherent stack.

The two-protocol stack in practice

Here is what the architecture looks like when both protocols are doing their jobs:

Supervisor (Anthropic)
  │
  ├─── A2A ──► Research Agent (different vendor)
  │               └─── MCP ──► Web Search
  │               └─── MCP ──► File System
  │
  └─── A2A ──► Code Review Agent (different framework)
                  └─── MCP ──► GitHub
                  └─── MCP ──► Postgres

The supervisor does not care what the sub-agents are built with. It speaks A2A. Each sub-agent manages its own tool connections via MCP. The protocols operate at different layers without interfering with each other.

Common misconceptions

• “A2A replaces MCP.” No. They operate at different layers. Removing either one breaks the stack — you need both. MCP handles the agent-to-tool layer; A2A handles the agent-to-agent layer.

• “A2A is a Google-controlled proprietary protocol.” It was donated to the Linux Foundation in June 2025. Governance is open. The fact that IBM merged ACP into it rather than maintaining a competing standard reinforces this.

• “You only need A2A if you’re building multi-cloud systems.” Even single-cloud architectures benefit from A2A when mixing agents from different frameworks or from third-party vendors. The protocol exists precisely because “same cloud” does not mean “same framework.”

• “A2A is cutting-edge and risky to adopt.” 150+ organizations including every major cloud provider support it as of 2026. It uses HTTP and JSON-RPC — the least exotic transport choices imaginable. The operational risk is low.

Frequently asked questions

What is an agent card and why does it matter? An agent card is a JSON document published at /.well-known/agent-card.json on an A2A-compatible agent’s host. It declares the agent’s skills, supported data types, and authentication requirements. It’s the discovery mechanism: before delegating a task, the supervisor reads the card to confirm the sub-agent can handle the request. Version 1.0 added signed agent cards so the caller can cryptographically verify who issued the card.

If A2A uses JSON-RPC 2.0 over HTTP, how is it different from just calling a REST API? A plain REST API call has no standardized schema for agent capabilities, task lifecycle, streaming status updates, or artifact returns. A2A defines all of these as a protocol — both sides know exactly what a “task” looks like, what states it moves through, and how results are returned. It’s the difference between an informal convention and a spec both sides implement.

Do I need to run my own A2A infrastructure? Not necessarily. Major clouds (Google, AWS, Microsoft) now provide native A2A support, so you can leverage their infrastructure rather than rolling your own agent routing layer. For local development, the official SDKs make it straightforward to stand up an A2A-compatible agent in an hour or two.

How does authentication work when agents are owned by different organizations? A2A supports OAuth 2.0, API keys, and mutual TLS. For cross-organization scenarios, signed agent cards (v1.0+) provide cryptographic proof of identity, so the delegating agent can verify it is talking to a legitimate agent rather than an impersonator. This is the same trust model used in federated identity systems — nothing fundamentally new.

Where this fits in the series

This episode is part of Agents at Scale: The 2026 Frontier, the “How Claude Actually Works” course on The Stack Underflow. The previous episode established the supervisor-worker pattern as the production default; this episode fills in the protocol layer that makes cross-vendor, cross-framework supervisor-worker systems possible. The next episode covers sub-agent isolation — how to prevent one agent’s failure or compromise from cascading through the rest of the system.

Browse all tutorials to follow the full series in order.