Why Agent Protocols Exist: The MxN Problem · Interoperability: MCP, A2A & the Agent Protocol Stack

There is a directory that exists, under one name or another, in every company that adopted agents early. At one mid-size fintech it was called integrations/, and by late 2024 it held forty-one files with names like jira_for_support_bot.py, jira_for_dev_agent.py, and jira_for_oncall_assistant.py — three separate, subtly different wrappers around the same Jira API, because three agents had been built by three teams at three different times. When Jira changed a pagination default, all three broke, on three different days, and were fixed by three different engineers who did not know the other two existed. The week the platform team counted the files was the week they started looking for a protocol.

You have felt a small version of this pain already. In Tool Use, Code Execution & Sandboxing you hand-rolled a tool layer: JSON Schemas, dispatch, result formatting, error envelopes. It worked, and it taught you what a tool call really is — but everything you built was private to your agent. Nobody else's agent can call your tools, and your agent cannot call anybody else's, without another round of bespoke glue. This lesson is about the arithmetic that makes that approach collapse at scale, and about the small stack of open protocols that emerged in 2024–2026 to replace it.

By the end you will be able to name the four layers of the 2026 agent protocol stack — MCP, A2A, AG-UI/A2UI, AP2/x402 — say precisely what each one standardizes, explain why a protocol is not a framework, and read a date-versioned spec changelog the way a working engineer reads release notes: looking for the lines that change your code.

1. The Integration Matrix

Put numbers on the fintech story. Say your company runs M agent surfaces — a support bot, a coding agent, an on-call assistant, an analytics copilot — and they collectively need access to N internal systems: Jira, GitHub, the data warehouse, Slack, the CRM, the wiki, and so on. Every agent needs most of the systems, and every pairing is a bespoke integration: its own auth handling, its own schema for arguments, its own retry and error conventions, its own owner.

The cost is M × N. Four agents and twelve systems is forty-eight integrations. Grow to eight agents and twenty-five systems — a perfectly ordinary 2026 enterprise — and you are maintaining two hundred integrations. Each one is small, which is exactly the problem: no single wrapper justifies real engineering investment, so all of them stay half-tested, half-documented, and forked. The matrix also punishes change quadratically. Add one agent and you owe N new integrations before it is useful; add one system and you owe M. Deprecate an API version and the blast radius is a column of the matrix, scattered across teams.

This is not a new disease. Machine translation hit it (every language pair needs a translator), compilers hit it (every language × every CPU), and hardware peripherals hit it (every device × every port). The cure is always the same shape: put a standard interface in the middle. Compilers adopted intermediate representations; peripherals got USB. With a shared wire format, each agent implements the protocol once (M adapters), each system is wrapped once (N adapters), and any agent can reach any system. M × N collapses to M + N: for the eight-agent, twenty-five-system company, two hundred integrations become thirty-three — and each of the thirty-three is used by everyone, so it actually gets maintained.

2. What a Protocol Actually Pins Down

Saying 'put a standard in the middle' is easy; the work is deciding what the standard must specify. For agent-to-tool communication, the bespoke wrappers all reinvented the same five things, so those are exactly what a protocol has to pin down:

Discovery — how does an agent learn what tools and data a system offers, with what schemas, without a human reading docs?
Invocation — one wire format for 'call this operation with these arguments' and one envelope for results and errors.
Context — a way to expose data (files, records, documents) that an agent should read, distinct from operations it should perform.
Lifecycle — connect, negotiate versions and capabilities, keep the session alive or make each call self-contained, disconnect.
Direction reversal — a channel for the system to ask something back: a clarifying question to the user, a completion from the model.

The Model Context Protocol — MCP, announced by Anthropic in November 2024 and adopted across the industry (OpenAI, Google DeepMind, and Microsoft all shipped client support during 2025) — answers all five for the agent-to-tool layer. It is an open, vendor-neutral spec: JSON-RPC 2.0 messages over a couple of standard transports, with a fixed vocabulary of primitives (tools, resources, prompts, and the reverse-direction flows sampling and elicitation) that the next lesson dissects one by one. What matters here is the economic role: MCP is the USB port of the agent world. The plug is boring on purpose, and the boredom is the feature.

3. A Protocol Is Not a Framework

A confusion worth killing early, because hiring managers and vendors both trade on it: protocols and frameworks are orthogonal. A framework — LangGraph, CrewAI, the Microsoft Agent Framework — is code that runs inside your process and shapes how you structure the loop: state, planning, retries, handoffs. A protocol is an agreement about bytes between processes. One is an implementation choice; the other is an interface commitment.

Consequences of orthogonality, all of which you will use:

You can speak MCP from any framework — every major one ships an MCP client adapter — or from no framework at all. The bare agent loop you built in Agent Architectures: Loops, Planning & Memory can become an MCP host with about thirty lines of client code, and in Lesson 3 it will.
An MCP server neither knows nor cares what is on the other end: Claude Desktop, Cursor, a LangGraph graph, your bare loop, or a test harness. Build the server once; every host benefits.
Frameworks churn; protocols compound. Frameworks have merged (AutoGen and Semantic Kernel became the Microsoft Agent Framework), pivoted, and died within eighteen months, and the OpenAI Assistants API — a proprietary interface many teams treated as an interface commitment — was sunset. Servers written against MCP's first revision still connect today. Skills invested in the protocol layer outlive the framework of the season.

4. The 2026 Stack Map

MCP solved agent-to-tool, and its success made the remaining gaps visible. Through 2025 and 2026 the industry converged on a small stack, one protocol (or contending pair) per layer:

Layer	Protocol	Stewardship (2026)	What it standardizes
Agent ↔ tools & context	MCP	Open spec, date-versioned; originated at Anthropic	Discovering and invoking tools, reading resources, prompt templates, sampling, elicitation
Agent ↔ agent	A2A v1.0	Linux Foundation (donated by Google; IBM's ACP folded in)	Agent Cards for discovery, tasks with lifecycle states, messages and artifacts, long-running delegated work
Agent ↔ interface	AG-UI, A2UI	CopilotKit community; Google	Streaming agent state, tool activity, and generated UI into front ends as typed events
Agent ↔ money	AP2, x402	Google and ~60 payments partners; Coinbase	Cryptographically signed mandates proving authority to pay; HTTP 402 machine-to-machine micropayments

The layers compose rather than compete. A concrete 2026 deployment: a procurement agent talks A2A to a supplier's quoting agent, which uses MCP internally to query its inventory system; your agent streams its progress to the buyer's dashboard over AG-UI, and settles the invoice under an AP2 mandate signed by the buyer. Four protocols, one workflow, no bespoke glue. This course walks the stack bottom-up: MCP as a builder (this section and the next), then A2A, then the interface and payments layers.

A useful test when someone pitches 'protocol number five': ask which layer it owns. If the answer overlaps a layer above — as many 2025 hopefuls overlapped A2A — expect consolidation, which is precisely what happened when IBM's Agent Communication Protocol merged into A2A rather than fight it.

5. Date-Versioned Specs and the Changelog Habit

MCP versions are dates, not semvers: 2025-03-26, 2025-06-18, 2025-11-25, and the 2026 revision current as you read this. That choice signals something about pace — this is a spec that revises in months, not years — and every revision so far has changed behavior you would ship:

2025-03-26 replaced the original two-endpoint HTTP+SSE transport with streamable HTTP and added OAuth 2.1 authorization and tool annotations. Servers written against the old transport needed real migration, not a recompile.
2025-06-18 added elicitation (servers asking users questions mid-call) and structured tool output, and removed JSON-RPC batching — a breaking deletion.
2025-11-25 added asynchronous tasks for long-running tool calls and sharpened the stateless-server story that horizontal scaling depends on.

Lesson 5 covers the mechanics of how client and server negotiate a revision at connect time. The professional habit to build now is simpler: when a protocol you depend on revises, read the changelog the same week, and ask three questions of every line — does this break my servers, does it unlock a capability I am currently faking, and when do the hosts my users run pick it up? Engineers who skipped the 2025-03 changelog shipped servers on a transport their newest hosts were already deprecating.

Check: your team builds agents in LangGraph. A vendor says their system 'only integrates with CrewAI'. If the vendor exposed an MCP server instead, what would change?

6. What You Can Now Do

You can put a number on integration debt: count agents, count systems, multiply, and compare against M + N to make the case for protocol adoption in one slide. You can sort any product claim into the four-layer map and spot the ones that own no layer. You can explain to a skeptical colleague why adopting MCP does not mean adopting anyone's framework. And you know that a date-versioned spec is a living dependency: pin the revision you target, read every changelog, and budget for skew.

What you cannot yet do is build anything — you know why MCP exists but not how it is put together. The next lesson opens the hood: hosts, clients, servers, the JSON-RPC messages on the wire, and the primitives you will spend the rest of this section implementing.