MCP and A2A Standardize Different Boundaries

Before writing a single line of code, it pays to separate the two protocols by meaning - because the rest of the book is about where each one's boundary runs. MCP connects an AI application to capabilities and data: a model inside a host discovers a server's tools, resources, and prompts, and calls a specific capability. A2A connects independent agent applications as peer services: one agent reads another's Agent Card, negotiates data formats, sends a Message, and watches the Task lifecycle through to a finished Artifact. Different questions, different units of contract - so this is not an either-or choice but two levels of one architecture.

The easiest way to see them together is the book's running example. A Release Coordinator asks a Release Review Agent to check the release web-portal@2.4.0. Between the two agents, A2A is in force: the coordinator doesn't know how the reviewer is built, it only states the goal and waits for the result. And inside the reviewer runs an MCP host that reads a runbook, fetches a CI snapshot, and calls a deterministic check through MCP servers. One request passes through both boundaries in turn.

The arrows read left to right and show how the two boundaries meet in a single scenario. On the outside, the coordinator talks to the agent in the language of A2A - a Message opens a Task, the status moves from submitted to working, and an Artifact appears at the end. Inside, while the Task is working, the same agent speaks MCP - it discovers the available capabilities and makes addressed calls to servers. Neither level substitutes for the other: A2A carries the delegation, MCP carries access to capabilities.

Fold this into one sentence and the difference is easy to remember.

The short formula. MCP gives an agent hands and sources. A2A gives an organization a way to hand work between self-standing agents.

That is exactly why the choice can't be made by a marketing word. The label "agent" on a button or "AI" in a service description decides nothing - the character of the boundary decides.

Don't decide by the word "AI". If a remote service is an ordinary deterministic function, it doesn't need A2A. If a local capability is called "agent", that alone doesn't make it an A2A service.

The whole book begins with this distinction, and we'll return to it at every layer: first we'll choose the minimal contract for a task (next chapter), then build each side separately, and only at the end compose them into a single system.