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

June 23, 2026 · updated June 25, 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 delegates subtasks to specialist agents. The architecture sounds simple enough on a diagram. The part most explanations quietly skip is the plumbing: how does an agent built on Anthropic’s infrastructure actually hand a task to a research agent running on LangChain in AWS — and then wait for a result, handle streaming updates, and verify it is talking to a legitimate agent and not an impersonator?

Until April 2025, the honest answer was “custom glue code every time.” That month Google shipped the Agent-to-Agent (A2A) protocol and the picture snapped into focus. If you already understand Model Context Protocol (MCP), you are exactly halfway there — because A2A and MCP solve adjacent but non-overlapping problems, and every production multi-agent system needs both.

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 layers for a complete production stack.

The layer confusion that trips everyone up

Before A2A existed, developers reached for MCP 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 delegate a subtask to a research agent built on a different framework in a different cloud, operated by a different team, without any of them writing a single line of bespoke integration code. Peer coordination across framework and vendor boundaries. Horizontal.

These are not competing standards. 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 this connection between two agents, or between an agent and a tool? That question alone answers which protocol applies.

How MCP works (the vertical layer)

MCP (Model Context Protocol, shipped by Anthropic in November 2024, current spec 2025-11-25) is built on JSON-RPC 2.0 over three transport options: stdio for local processes, Server-Sent Events for HTTP streaming, and Streamable HTTP for stateless deployments. In December 2025, Anthropic donated MCP governance to the Agentic AI Infrastructure Foundation (AAIF), a directed fund under the Linux Foundation, marking the protocol as vendor-neutral. A 2026-07-28 release candidate is in progress — the largest revision since launch — adding a stateless core and a Tasks extension.

MCP exposes four primitive types to a connected agent:

The MCP server announces which primitives it supports during capability negotiation at connection setup. The agent then calls tools (or reads resources) via standard JSON-RPC messages. Everything is single-agent: one model, one server, one session. Horizontal agent coordination is out of scope.

How A2A works (the horizontal layer)

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

An agent card is a JSON metadata document published at /.well-known/agent-card.json on any A2A-compatible host. It declares the agent’s identity, skills, supported data types, service endpoint, and authentication requirements. Before delegating a task, the supervisor reads the card to confirm the sub-agent can handle the work.

Signed agent cards, added in A2A v1.0 (April 2026), attach a cryptographic signature to the card using ProtoJSON canonicalization. The receiving agent can verify that the card was actually issued by the domain owner — not injected by a man-in-the-middle. This matters operationally when you are delegating to agents you did not build and do not fully control.

Task lifecycle

Every unit of work in A2A is a task — a first-class object with a defined lifecycle. Tasks move through eight states:

submitted  ──►  working  ──►  completed   (terminal)
                  │
                  ├──►  input-required    (interrupted, awaits user)
                  ├──►  auth-required     (interrupted, awaits credentials)
                  ├──►  failed            (terminal)
                  ├──►  canceled          (terminal)
                  └──►  rejected          (terminal, agent declined)

The calling agent monitors state transitions through SSE streaming: the server emits TaskStatusUpdateEvent and TaskArtifactUpdateEvent messages over an open HTTP connection, concluding when a final: true flag arrives. For long-running tasks, A2A also supports push notifications so the caller does not need to hold an open connection at all.

Core JSON-RPC methods in the spec: SendMessage, SendStreamingMessage, GetTask, ListTasks, CancelTask, SubscribeToTask, plus push-notification lifecycle methods (Create, Get, List, Delete).

Two-protocol stack in practice

Here is what the architecture looks like when both protocols are doing their jobs across a real support workflow:

Supervisor (Anthropic / Claude Sonnet 4.6)
  │
  ├─── A2A ──► Billing Agent  (LangChain / AWS Bedrock)
  │               └─── MCP ──► CRM database
  │               └─── MCP ──► Payments API
  │
  └─── A2A ──► Policy Agent  (AutoGen / Azure AI Foundry)
                  └─── MCP ──► Policy repository
                  └─── MCP ──► Shipping API

Supervisor discovers billing agent via /.well-known/agent-card.json
Verifies signed card (v1.0+) before delegating
Billing agent manages its own MCP tool connections internally
Supervisor never sees or controls billing agent's tools

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

Adoption timeline: from announcement to infrastructure in one year

The A2A timeline is unusually fast for a protocol:

IBM’s Kate Blair, who ran the competing ACP project, joined the A2A Technical Steering Committee and said: “By bringing the assets and expertise behind ACP into A2A, we can build a single, more powerful standard for how AI agents communicate and collaborate.” When your biggest rival joins rather than fights, the protocol has won.

As of v1.0.1, six official SDKs are production-ready:

pip install a2a-sdk                    # Python
npm install @a2a-js/sdk               # JavaScript / TypeScript
go get github.com/a2aproject/a2a-go   # Go
                                       # Java: via Maven
dotnet add package A2A                 # .NET (NuGet)
cargo add a2a-lf                       # Rust

Microsoft integrated A2A into Azure AI Foundry and Copilot Studio (GA April 2026). AWS added native support through Amazon Bedrock AgentCore Runtime. Google ADK ships A2A support natively. An Agent Payments Protocol (AP2) — fully compatible with A2A via a mandates extension — launched alongside with 60+ financial-services organizations.

By comparison, MCP crossed 97 million monthly SDK downloads (Python + TypeScript combined) by February 2026 and now has native support from every major AI provider. Both protocols are now infrastructure, not experiments.

How to apply this right now

Concrete decision rules for a working system:

1. Always ask “is this a tool or an agent?” If you are wiring an agent to a database, file system, or API — use MCP. If you are wiring an agent to another agent — use A2A. Do not reach for one when the job belongs to the other.

2. Start with the agent card. Before writing any A2A task logic, define what your agent can do in its card: which skills it supports, what data types it accepts, and what auth it requires. The card is the contract.

3. Use signed agent cards in production (v1.0+). In any system where a supervisor delegates to agents it did not build, signature verification is the difference between trusting a claimed identity and verifying it. The signed-card verification adds one HTTP round-trip; it is worth it.

4. Design for task state, not just success/failure. A2A tasks can reach input-required or auth-required mid-flight. Build your orchestrator to handle interrupted states gracefully — this is where most production integrations first break.

5. Treat each sub-agent’s MCP connections as internal. The supervisor should not know or care which MCP tools a sub-agent uses. If you find yourself routing MCP calls through the supervisor, you have the architecture inverted. MCP is per-agent, not per-system.

6. Use SSE streaming for long-running tasks. Do not poll GetTask in a loop. Subscribe to the task stream and let TaskStatusUpdateEvent deliver state transitions. For tasks measured in minutes rather than seconds, configure push notifications so you can release the HTTP connection entirely.

Common misconceptions

“A2A replaces MCP.” They operate at different layers. MCP handles agent-to-tool; A2A handles agent-to-agent. Removing either breaks the stack. The correct mental model is a two-layer protocol stack, not a choice between two options.

“A2A is a Google-controlled proprietary protocol.” Google donated it to the Linux Foundation in June 2025. Governance is open: a Technical Steering Committee includes representatives from Google, Microsoft, AWS, IBM, Cisco, Salesforce, SAP, and ServiceNow. The fact that IBM merged its competing ACP standard into A2A — rather than maintaining a rival — is the clearest signal that governance is real.

“You only need A2A for multi-cloud systems.” Even single-cloud architectures benefit from A2A when mixing agents from different frameworks or third-party vendors. The protocol exists because “same cloud” does not mean “same framework.” An Anthropic agent and a LangChain agent running in the same AWS region still need a standard coordination layer.

“The task lifecycle is a nice-to-have wrapper around HTTP.” The lifecycle is load-bearing. input-required lets a sub-agent surface a blocking question to the user without timing out. auth-required lets a sub-agent request a credential mid-task without aborting the whole workflow. rejected lets a sub-agent decline work it cannot safely complete. Treat these states as design primitives, not error cases.

Frequently asked questions

What is an agent card and why does it matter? An agent card is the A2A discovery document — a JSON file published at /.well-known/agent-card.json on any A2A-compatible host. It declares the agent’s identity, skills, accepted data types, service endpoint, and authentication requirements. Before delegating a task, a supervisor reads the card to confirm the sub-agent can handle the request. Signed agent cards (v1.0+) add a cryptographic signature so the caller can verify the card was genuinely issued by the domain owner rather than injected by an attacker.

If A2A uses JSON-RPC 2.0 over HTTP, how is it different from calling a plain REST API? A REST API call has no standardized schema for agent capabilities, task lifecycle, streaming status, or artifact return. A2A defines all of these as protocol primitives — both sides know exactly what a “task” object looks like, what states it can occupy, how TaskStatusUpdateEvent messages are structured, and how artifacts are returned. It is the difference between an informal convention two teams agree on privately and a spec both sides implement independently without a call.

Do I need to run my own A2A infrastructure? Not necessarily for production. Microsoft Azure AI Foundry, Copilot Studio, Amazon Bedrock AgentCore Runtime, and Google’s ADK all provide native A2A support. For local development, the official SDKs (six languages as of v1.0.1) let you stand up an A2A-compatible agent in a few hours. The barrier to entry is intentionally low: the protocol runs on HTTP and JSON, not bespoke infrastructure.

How does authentication work across organizational boundaries? A2A supports OAuth 2.0 (Authorization Code, Client Credentials, and Device Code flows), API keys, HTTP Bearer tokens, OpenID Connect, and mutual TLS. For cross-organization scenarios, signed agent cards (v1.0+) provide cryptographic identity verification before the first task is even sent. This is the same trust model used in federated identity systems — nothing architecturally novel, deliberately so.

What happened to ACP (Agent Communication Protocol)? IBM Research launched ACP in March 2025 to power its BeeAI platform. On August 29, 2025, IBM merged ACP into A2A under the Linux Foundation umbrella rather than maintain a competing standard. BeeAI users retained full functionality through adapter layers: A2AServer makes a BeeAI agent A2A-compliant; A2AAgent lets a BeeAI orchestrator call external A2A agents. The merger consolidated what had briefly been a three-protocol landscape (MCP, ACP, A2A) into a coherent two-layer stack.

How does the MCP spec relate to A2A now that both are under Linux Foundation governance? MCP (governed by AAIF under Linux Foundation since December 2025) and A2A (governed by the A2A project under Linux Foundation since June 2025) are now both vendor-neutral standards with open governance. They are intentionally complementary: MCP’s 2025-11-25 spec defines tools, resources, prompts, and sampling for vertical agent-to-tool wiring. A2A v1.0 defines agent cards, tasks, streaming, and push notifications for horizontal agent-to-agent coordination. The two specs reference each other’s use cases and are designed to coexist in the same stack.

Where this fits in the series

This episode is part of Agents at Scale: The 2026 Frontier. The previous episode established the supervisor-worker pattern as the production default (Multi-Agent Patterns That Actually Work). This episode fills in the protocol layer that makes cross-vendor, cross-framework coordination possible.

For the tool side of the picture — what MCP actually looks like from the inside — see What is MCP: The Universal Adapter and What Happens When an Agent Uses a Tool.

The next episode in this series covers sub-agent isolation: how to prevent one agent’s failure or compromise from cascading through the system (Sub-Agent Isolation and Context Rot). After that, Agent Observability covers how to instrument A2A and MCP calls with OpenTelemetry GenAI semantic conventions so you can actually see what your agents are doing.

Browse all tutorials to follow the full series in order.