MCP vs A2A.

The short answer

MCP, the Model Context Protocol, is a vertical standard. It describes how a single agent discovers and calls the things around it — tools, files, databases, internal services — without a bespoke integration per system. It answers the question what can this agent reach, and how does it ask.

A2A, agent-to-agent messaging, is a horizontal standard. It describes how one agent delegates to another across an organisational or vendor boundary: how it advertises what it can do, how a task is handed over, and how results and status come back. It answers the question who else can do part of this work, and how do we talk.

You can adopt either without the other. Most production systems will end up using both, for the same reason a company runs both a database driver and an email protocol.

Side by side

• Direction. MCP: agent to capability, vertical. A2A: agent to agent, horizontal.
• Primary unit. MCP: a tool or resource with a described interface. A2A: a task with a lifecycle and a status.
• Trust boundary. MCP: usually inside your perimeter, calling systems you own. A2A: frequently across a boundary, calling something you do not control.
• What breaks without it. MCP: every tool integration is bespoke and rewritten per platform. A2A: every collaboration between agents is a private contract that cannot be swapped.
• Failure mode. MCP: ambiguous tool descriptions, so the agent picks the wrong tool confidently. A2A: seam loss, where the constraint or caveat does not survive the handoff.
• Governance question. MCP: what is this agent permitted to do. A2A: whose policy applies once the task leaves your system.

Where MCP earns its keep

The honest case for MCP is not elegance, it is the integration bill. Before it, connecting an agent to a warehouse, a ticketing system, and an internal pricing service meant three adapters written against three platforms, and rewritten when you changed platform. A described interface turns that into configuration.

The subtler benefit is control. When tools are described declaratively, permissions, rate limits, and audit can wrap the description rather than being scattered through application code. That is exactly the shift from access control to action control that Chapter 14 argues for, and the guardrail surface that Chapter 15 builds on.

The failure mode is worth planning for. A tool description is a prompt. Vague names and overlapping responsibilities produce an agent that calls the wrong thing and reports success — a class of bug that no amount of model upgrading fixes.

Where A2A earns its keep

A2A matters the moment work crosses an owner. A support agent that needs a refund executed by a finance agent, a procurement agent negotiating with a supplier's agent, a research agent fanning out to specialists: each of those is a handoff, and handoffs are where multi-agent systems actually fail.

A shared protocol helps because it forces the handoff to be explicit — capability advertised, task stated, status tracked, result returned. What it does not do is carry your meaning. The protocol will faithfully transmit an instruction that has lost the constraint attached to it. That is the seam problem in Chapter 34, and the reason a context contract has to travel with the task, not alongside it.

Which one to adopt first

Adopt MCP first if your bottleneck is integration breadth: one agent, many systems, too many adapters. Adopt A2A first if your bottleneck is delegation: several agents or several teams already trying to collaborate through private, brittle contracts.

If neither is your bottleneck yet, adopt neither and write down your interfaces anyway. A documented internal contract can be moved onto a standard later. An undocumented one cannot be moved anywhere.

The portability question underneath both

Open protocols reduce integration lock-in. They do not reduce context lock-in, and context lock-in is the expensive kind. Your definitions, evaluation sets, memory, traces, and policy are the assets that took years to accumulate. A protocol boundary keeps the plumbing swappable while those assets quietly accumulate inside one vendor's proprietary store.

So the test is not do we speak an open protocol. It is can we leave. Export the context, stand the workflow up somewhere else on a sample, and count the days. Chapter 12 specifies what portable context has to contain, and Chapter 25 covers being platform aware without being platform dependent.

A short checklist before you commit

• Can you enumerate every tool an agent may call, from a description rather than from source code?
• Does each cross-agent handoff carry its constraints, provenance, and confidence with it?
• When two agents disagree, is there a stated authority, or does the last writer win?
• Can you export definitions, memory, and evaluations today, without a vendor ticket?
• Would a protocol change be a configuration change, or a project?