A2A Protocol vs MCP: What Google's Agent2Agent Standard Actually Solves (and What It Doesn't)

Your agents can't talk to each other. Not really.

A CrewAI agent speaks CrewAI. A LangGraph agent speaks LangGraph. The moment you need one to hand a task to the other, you're writing a bespoke integration: a throwaway HTTP client, a hand-rolled message format, a retry loop you'll debug at 2am. I've shipped production systems on CrewAI, LangGraph, and AutoGen, and the model was never the hard part. The glue between agents that were never designed to interoperate was.

The Agent2Agent (A2A) protocol is the first open standard that tries to kill that glue. It's published by Google, uses JSON-RPC 2.0 over HTTP(S), and as of 2026 ships official SDKs in three languages: Python, Go, and JavaScript, plus a DeepLearning.AI course built with Google Cloud and IBM Research. If you build multi-agent systems, this is worth understanding before it lands in your stack whether you planned for it or not.

Here's what it actually does. And where it still leaves you on your own.

What the A2A protocol actually is

A2A is an open protocol for communication between "opaque agentic applications" — agents built on different frameworks, by different teams, running on different servers, that need to collaborate as agents rather than as tools.

Three things define it:

Agent Cards for discovery. Every A2A agent publishes an Agent Card: a structured description of what it can do and how to reach it. Before any work happens, one agent reads another's card and learns its capabilities. No shared codebase, no shared memory required.

Three interaction modes. A2A supports synchronous request/response, streaming over Server-Sent Events (SSE), and asynchronous push notifications for work that takes longer than a round trip. A long-running research task can stream progress and then push a final result when it's done.

Opacity by design. This is the part people miss. An A2A agent does not expose its internal state, memory, or tools to the agents it talks to. It's a black box that takes a task and returns a result. That protects proprietary logic and reduces the blast radius of a compromised agent, but it also means debugging crosses a boundary you can't see into.

That last point is the whole philosophy. MCP (more on that below) is about giving an agent tools. A2A is about letting agents be peers.

A2A vs MCP: the difference that matters

This is the search query everyone types, so let me be precise instead of hand-wavy.

MCP, the Model Context Protocol, connects an agent to its tools and data sources. It's agent-to-resource. A database, an API, a filesystem: MCP wraps it so the agent can call it. My post on building your own MCP server walks through that layer.

A2A connects an agent to another agent. It's agent-to-agent. The other side isn't a tool you drive; it's a peer you delegate to, and it decides how to get the result.

	MCP	A2A
Connects	Agent to tools/data	Agent to agent
Discovers via	Server definitions you wire in	Agent Cards (self-described)
Knows internals?	Yes, it's your tool	No, opaque by design
Best for	Giving one agent capabilities	Coordinating many agents

They aren't competitors. The official framing is that A2A complements MCP: MCP feeds an agent its tools, A2A lets that agent hand work to other agents. If you've read why your agent can't use tools safely, think of A2A as the next layer up, the one that assumes the tool-using problem is already mostly solved.

Where I'd actually use it

I self-host my agents. After moving off hosted APIs, I run everything on a single Hetzner box, and the integration tax between frameworks was the thing eating my evenings. A2A is appealing there precisely because it assumes nothing about the other side's internals.

Concretely, the cases where it earns its place:

• Multi-framework stacks. One agent is great at retrieval, another at codegen, a third at long-horizon planning. They were built on different frameworks by different people. A2A lets them cooperate without anyone rewriting the others.
• Cross-team or cross-company boundaries. You don't want to share your agent's internals with a vendor's agent. Opacity is a feature here, not a limitation.
• Long-running delegation. A task that runs for minutes or hours, streams progress, and pushes a result when finished fits A2A's async model far better than a blocking API call.

If you're running one agent and calling a few tools, A2A is overhead you don't need. Use MCP. Use a function call. The moment you have two agents that need to negotiate who does what, the protocol starts paying for itself.

The catch: what A2A doesn't solve

This is the part the launch announcements skip.

It's a protocol, not a runtime. A2A tells agents how to speak. It does not give you orchestration, error recovery, idempotency, or a dead-letter queue. You still build the system around it. The multi-agent reliability work, how to test agents before production, guardrails against runaway loops, tool-call verification, is still on you.

Opacity cuts both ways. When an A2A agent returns a wrong answer, you can't see why. The boundary that protects you from a compromised peer also hides the bug that cost you an hour. You need observability at the protocol edge, because you won't get it from inside.

It's early. The spec is real and the SDKs exist, but adoption is not universal. Today you'll still write adapters for the frameworks and services that haven't published an Agent Card. The standard reduces the glue; it hasn't eliminated it yet.

Security is yours to configure. "Enterprise-ready" in the spec means authentication and authorization are designed in, not that they're on by default. An A2A agent with an open Agent Card is an open door. Treat agent-to-agent trust the same way you'd treat any network boundary, because that's exactly what it is.

Getting started

If you want to touch it this week, the path is short:

pip install a2a-sdk

That gives you the Python SDK. Google's docs site (a2a-protocol.org) carries the full specification, and the DeepLearning.AI course teaches exposing agents built with Google ADK, LangGraph, or BeeAI as A2A servers and wiring them into workflows. Start by standing up one agent that publishes an Agent Card and one that consumes it. The discovery mechanism is the part that feels different from a normal API, and it's the part worth internalizing first.

Read it alongside the MCP material. The two together describe a stack: MCP for what your agent can do, A2A for what your agents do together. Most teams I talk to are missing the second half and calling the resulting tangle "orchestration."

The honest part

A2A is not going to make your multi-agent system reliable by itself. What it does is remove a specific, real tax: the per-integration glue between agents that should be able to talk and couldn't. That's worth something. I've paid that tax in weekends.

But a protocol that lets agents negotiate doesn't tell them to negotiate well. The failure modes I wrote about in testing agents before production don't disappear because the handshake is standardized. They move up a layer. Plan for that, and A2A is a genuine upgrade. Treat it as a reliability cure and you'll ship a cleaner version of the same mess.