Part III, Chapter 15 of the Agentic-Oriented Development series
MCP is vertical. A2A is horizontal.
Model Context Protocol (MCP) is the contract your agent uses to reach a capability outside its own process. Agent-to-Agent (A2A) is the contract your agent uses to coordinate with a peer agent that has its own context, its own state, and its own opinions about how to do its job.
Your protocol stack is the set of contracts that govern how every layer of your system moves work to the next layer. In a real project it lives in concrete artifacts. A configuration file declaring which MCP servers your agent can reach. An agent declaration describing what your agent does for peers calling in. The server code behind both that implements the typed schemas the protocols require.
Two protocols carry your stack today. Each one solves a different shape of communication problem.
MCP governs the way your agent reaches DOWN into the capabilities it depends on. Tools the agent invokes, data sources it queries, vector stores it searches, external systems it acts against. A2A governs the way your agent reaches ACROSS to a peer agent that has its own context, its own state, its own opinions about how to do its job.
Method calls and message passing. Same dichotomy. Different layer of the stack.
I tell you this distinction matters because every agent system I review now is collapsing these two layers into one protocol, and the architectures break in exactly the same places OOP architectures broke when we tried to message through getters. I learned this the hard way during a customer identity consolidation that I will come back to later in the chapter, where the constraint that broke the obvious architecture was the same constraint that breaks single-protocol agent systems today.
Object-oriented programmers spent thirty years drawing this same line. An object invokes behavior on its dependencies through method calls. The receiver is known, the contract is typed, the call returns a value. Two objects that need to coordinate, on the other hand, exchange messages through interfaces. The sender names intent. The receiver decides how to fulfill it. The two patterns coexist because they solve different problems.
The agent layer recovered that distinction the moment systems grew past a single agent talking to a single tool. MCP solves the dependency-invocation problem. A2A solves the peer-coordination problem. Trying to use one for the other is exactly the kind of category mistake that, at the OOP layer, produced the architectures that made us regret the day we tried to do messaging through getters.
Chapter 14 named the wires. This chapter strips them.
The Two Directions Problem
A single protocol cannot solve both problems because the questions sit at different layers of the topology and demand different answers.
MCP answers the vertical question. How does this agent invoke a capability that lives outside its process boundary? The capability might be a database query, a file fetch from object storage, or a payment-gateway call. It does not matter which. The agent wants a result. It does not need to negotiate. It does not need to know whether the tool is busy. It needs an inputSchema (a typed description of the arguments the tool accepts), a typed return, and a clear failure mode.
A2A answers the horizontal question. How does this agent coordinate with a peer that has its own context, its own working memory, and its own way of fulfilling work? The peer is another agent. Maybe it lives in another organization. Maybe it lives in another runtime. The calling agent does not control how the peer thinks, only what it asks the peer to deliver. Coordination is a task lifecycle, the structured request-status-deliverable arc A2A wraps around work that takes longer than a single call.
The collapsing-them-together failure mode shows up in two shapes. Teams that try to push inter-agent coordination through MCP end up shoehorning peer collaboration into a tool-call interface that was never designed to carry task lifecycles, multi-turn negotiation, or asynchronous progress. The agent on the other side is forced to pretend it is a stateless tool, which means it has to discard exactly the context that made it worth calling. Teams that try to push tool access through A2A end up routing every database query through a heavyweight task lifecycle that imposes coordination overhead on what should be a single reach-and-return.
One protocol cannot replace the other. They solve different problems at different layers.
The OOP grounding is the cleanest way to internalize this. Method calls are synchronous, strongly typed, and the calling object knows the receiver. Message passing is intent-based, sometimes asynchronous, and the receiver decides how to satisfy the request. AOD inherits both because both work-shapes exist in agent systems. The protocol stack just gives each shape its own wire.
Mapping Protocols to the Topology
The four-layer topology from Chapter 14 has a protocol verdict for every edge. The reader who memorized the topology should be able to look at any boundary in the diagram and name what governs it.
User to Orchestrator. Application protocol or UI surface. This sits outside the AOD protocol stack proper and is governed by whatever the host application chooses (HTTP for a web client, a chat surface for a conversational interface, a CLI shell for a developer tool). Naming it here just so the stack reads complete.
Orchestrator to Agent. A2A. The orchestrator delegates a task to a specialist agent. The agent has its own context window, its own memory, its own way of working through the task. The orchestrator does not see how the work happens. It sees the task result. That asymmetry is exactly what A2A's task lifecycle was designed to carry.
Agent to peer Agent. A2A. This is the Stage 3 mesh from Chapter 14. Two specialist agents handing work to each other directly without routing through the orchestrator. Discovery, negotiation, status, completion. All governed by the same protocol the orchestrator-to-agent edge uses.
Agent to Tool. MCP. The agent reaches down to an MCP server, invokes a tool with a typed input, gets a typed output, moves on. No coordination, no lifecycle, no peer state.
Agent to Subagent. Spawning and result-collection mechanics from Chapter 8. Not a protocol in the same sense, because the subagent is ephemeral, not a discoverable peer. It comes into existence to do one task, returns its result, and disappears. There is no published interface for an outsider to bind to. The mechanics are runtime concerns of the harness, not the protocol stack.
Skills. Cross-cutting at the agent layer. Skills are the Chapter 12 mechanism for injecting reusable knowledge, instructions, or judgment into an agent's context. They do not cross a process boundary. There is no message in flight to govern, so there is no skill protocol. A skill loads, the agent reasons against it, the work proceeds. If you find yourself looking for the wire that carries skills between layers, stop looking. There isn't one. The skill lives inside the agent, the way a method body lives inside an object.
The topology tells you what your system is. The protocol stack tells you how the layers actually move work between each other.
This is the reason the topology and the protocol stack are inseparable. The topology gives you the map. The protocol stack gives you the rules of motion on the map. Without the protocol stack, the topology is a diagram. With it, the diagram becomes a running system.
The Org Chart Parallel
For senior leaders, the cleanest way into this dichotomy is the org chart you already run.
MCP is the individual contributor. An agent putting its head down and querying a database, reading a file, calling a vector store. Pure task execution. No coordination overhead. The agent does its job, returns the result, moves on.
A2A is cross-departmental collaboration. An agent negotiating a handoff with an autonomous peer in another silo. Formal request, status updates, deliverable handed back. The deliverable is the Artifact (the structured output of a completed task). The negotiation is the Task lifecycle. The discovery channel is the Agent Card (the JSON document each A2A agent publishes to declare what it does).
The split is the same logic every org chart already encodes. Individual contributors do their work. Cross-functional collaboration goes through formal request channels. Nobody walks into another department's database to extract a record. Nobody coordinates with another team by writing a database query. The protocols inherit that exact logic, just at the agent layer.
The OOP Parallel: Agent Cards Are Public Interfaces
The org chart parallel is the universal frame. For your engineering counterparts, the same dichotomy lands one altitude deeper, in the language they already use to talk about object boundaries.
A2A's discovery mechanism is the Agent Card, a JSON metadata document published at /.well-known/agent-card.json. The card declares the agent's name, its skills, its endpoint, and its authentication requirements. It does NOT declare the agent's internal logic, its model, its system prompt, or its memory.
This is encapsulation. Object-oriented programming taught us that a public interface declares what an object can do, not how it does it. Agent Cards are the same construct, reconstituted at the agent layer. The protocol even has a name for this design. Opaque agents (agents that publish capabilities through a card and keep their internals private). The protocol enforces the boundary the way an interface enforces a contract.
When I review agent systems shipping today, the ones that scale cleanly are the ones that drew the encapsulation boundary at the right altitude. Opaque agents are interchangeable. If two agents publish matching skills, an orchestrator can swap one for the other without rewriting itself. That is the Liskov substitution principle, the design rule that says interchangeable parts must be safely swappable, applied at the agent layer. Barbara Liskov named it in 1987 as the design property that makes inheritance worth using. A2A makes it the foundation of inter-agent discovery.
MCP encapsulates too, just at a different altitude. An MCP server hides the implementation of a tool behind an inputSchema and an outputSchema (the typed argument and return-value contracts MCP requires of every tool). The agent calling the tool does not know whether the tool is talking to PostgreSQL, S3, or a homegrown microservice running behind a queue. The schema is the public interface for the tool. The Agent Card is the public interface for the agent.
A2A defines four core object types, and they line up with the OOP parallel cleanly. Agent Card is the public interface signature. Message is the method invocation. Task is the invocation lifecycle, the structured envelope around work that takes longer than a single call. Artifact is the typed return value, the formalized output a calling agent inspects before chaining to the next step.
Artifacts make A2A handoffs auditable in shape. The protocol guarantees the structured envelope on every completed task. Immutability and retention come from whatever store the enterprise wires behind it, not from the protocol itself. The Agent Card describes what an agent CAN do. The Artifact records what it actually DELIVERED. Together they bracket the agent's accountability surface.
The agent publishes what it can do, not how it does it. That is encapsulation, just at a higher altitude.
The Agent Card is the contract. The Artifact is the receipt.
When You Need Which
The matrix below is the lookup, organized by the question the agent is actually trying to answer.
| Scenario | Protocol | Why |
|---|---|---|
| Agent calls a database query tool | MCP | Tool invocation, no peer coordination |
| Agent asks another agent to analyze data | A2A | Delegation across agent boundaries |
| Agent reads a file from cloud storage | MCP | External capability, no peer state |
| Agent delegates a subtask to a specialist | A2A | Peer with its own context |
| Agent accesses a vector store for RAG | MCP | Read-only data access |
| Agent discovers available specialist agents | A2A | Discovery is a coordination problem, not a tool problem |
The pattern shows up the moment you stop treating "agent" as a monolithic abstraction and start treating it as a system with two distinct external dependencies. Capabilities it consumes (downward) and peers it coordinates with (sideways).
I have seen this same architectural split in a different domain, and it sharpens the lesson. Earlier in my career, I led a customer identity consolidation across a global enterprise. We had over forty separate identity tools deployed across business units. Each application reached directly to its own identity store through its own ad-hoc interfaces. That is the pre-MCP, pre-A2A world at scale. Every consumer wiring itself to its dependencies in whatever shape the moment demanded.
We picked one platform to consolidate against. Then we hit the constraint that broke the obvious architecture. About a third of the business operated in countries with data residency laws requiring customer identity records to physically reside within the country's borders. A single centralized store was not legally an option for that third of the business.
So we adapted. Local identity stores in each region for residency compliance. A single, standardized federated API on top, so every consuming application saw one contract regardless of where the underlying records lived. Local stores were the vertical reach (each region's data lived where the law required, behind a uniform interface). The federated API was the horizontal coordination (one contract, many implementations behind it).
The architectural lesson is the same one MCP and A2A teach. Vertical reach is one problem. Horizontal coordination is a different problem. You cannot solve one with the protocol designed for the other. Hybrid architectures answer for both.
The Ecosystem Today
Both protocols crossed the production threshold inside the last twelve months. The numbers below show the shape of the crossing.
MCP. Per April 2026 industry analysis, the public MCP registry holds 9,400+ servers, up from roughly a thousand a year earlier. The mcp-server topic tag covers 7,800 GitHub repositories. SDK downloads run at approximately 110 million per month across the major framework ecosystems (OpenAI, Google, LangChain, and others). As of Q1 2026, native MCP support is shipping in Claude, ChatGPT, the Gemini API and Vertex AI Agent Builder, plus Cursor, Windsurf, Zed, the JetBrains AI Assistant, the Vercel AI SDK, and the OpenAI Agents SDK. The same industry survey reports a majority of enterprise AI teams running at least one MCP-backed agent in production.
A2A. Per the Linux Foundation's April 2026 milestone announcement, the A2A protocol surpassed 150 organizations in production deployment, marked at the protocol's first anniversary. Native A2A support is now built into Amazon Bedrock AgentCore (shipped November 2025), Azure AI Foundry, Salesforce Agentforce, ServiceNow, and SAP. Official SDKs ship in five major languages: Python, JavaScript, Java, Go, and .NET. The technical steering committee carries representation from AWS, Cisco, Google, IBM Research, Microsoft, Salesforce, SAP, and ServiceNow. Vertical adoption concentrates in supply chain, financial services, insurance, and IT operations.
Single-governance picture. Both protocols sit under the Linux Foundation umbrella. MCP is an anchor project of the Agentic AI Foundation (AAIF), which launched in December 2025 with Anthropic, Block, and OpenAI as co-founders and Platinum members including AWS, Bloomberg, Cloudflare, Google, and Microsoft alongside the three co-founders. A2A was donated to the Linux Foundation in June 2025 and reached the one-year milestone in April 2026. The two protocols share the same neutral foundation, even if they live in different LF sub-organizations. The two-protocol stack is the deliberate architectural intent of the foundation governing both, no longer a forecast.
The governance picture matters most to the readers who approve budget. Linux Foundation governance of MCP and A2A means the protocol stack is an open standard, not a vendor-specific play. Enterprise leaders fear vendor lock-in more than they fear technical risk. Foundation governance is the explicit answer to that fear. You are not betting on Anthropic. You are not betting on OpenAI. You are not betting on Google or AWS or Microsoft. You are betting on the shared language they have all signed onto, governed by the same foundation that governs Linux, Kubernetes, and Node.js. Senior leaders can draw their own conclusion about what that does to the lock-in risk profile.
Practitioners building today are building into a stack where MCP is the production-grade vertical protocol and A2A is the production-grade horizontal protocol, both governed under the same neutral foundation. That is the deployment shape Stage 4a (production-grade two-protocol stack) from the Chapter 14 maturity progression assumed.
What This Means for Your Roadmap
MCP first, today. If your team has not stood up an MCP server yet, that is the immediate move. Chapter 12 is the practitioner's playbook (skills versus MCP versus memory, tool design, the Practitioner Knowledge use case). The decision framework there still applies. MCP solves your real problem now.
Build with A2A in your line of sight. Even running a single-orchestrator system today, design your agent boundaries the way A2A would expect. Make every specialist agent's skill set explicit, the way an Agent Card would declare it. Use opaque boundaries internally, not just at cross-org seams. The discipline transfers cleanly when you eventually plug A2A in.
The two-protocol stack is the destination. AOD's job in 2026 is to teach you how to draw the topology, design the layers, and reach for the protocol that matches the layer. MCP for vertical. A2A for horizontal. Anything else and you are forcing a peer-coordination problem through a tool-invocation pipe, or vice versa.
The protocol stack is what turns the topology from a diagram into a running system.
What this chapter does NOT cover. The protocol stack tells you which wire to use. It does not tell you how to defend it. Three security concerns belong to Securing Agentic Systems, the second book in this series. Two of them are MCP-first concerns, because MCP is the protocol you are deploying right now.
- The AI-native gateway. A policy-enforcing proxy that terminates model-to-tool traffic with mutual TLS and Role-Based Access Control. Without it, every MCP server you register becomes its own enforcement boundary, which is how a single misconfigured tool punctures your whole agent fleet.
- The On-Behalf-Of token exchange. The OAuth 2.0 flow that propagates the authorizing user's enterprise SSO identity through every agent action, so an action taken by an agent attributes back to a human. Without it, every agent action your auditors investigate is anonymous.
- The tool-poisoning attack surface. The supply-chain risk that emerges when MCP servers feed instructions and data into your agents' reasoning loops. A malicious tool description becomes a malicious agent action.
A2A inherits the inter-organization version of these concerns plus the data-residency obligations my customer-identity story names. Cross-jurisdiction agent peering pulls in the same legal constraints that broke the single-store architecture in that consolidation. Book 2 covers which of A2A's supported authentication schemes (OAuth 2.0, mutual TLS, API key) you should enforce for which class of peering, and the gateway and OBO chapters carry the full architecture. Book 2, Part III is where this lives.
This chapter named the architecture completely. Book 2 picks up the security architecture with the same rigor.
What's Next
Vertical for capabilities, horizontal for peers, Linux Foundation governance for both. That is the protocol stack you can authorize today and defend in front of your board. The architecture is named, and you know which protocol governs which edge.
Chapter 16 covers how agents come into being inside that architecture. Persistent agents that live across phases. Ephemeral subagents that exist for a single task. The Agent Factory that creates them, configures them, and tears them down. Same pattern that gave us new in OOP, applied to a system where instantiation is a runtime decision instead of a compile-time one.
You have the class from Part I. You have the lifecycle from Part II. You have the architecture from Chapter 14, and now the protocols. All four.