Enterprise Architecture
MCP and A2A: agent interoperability standards, seen by an architect
MCP connects an agent to its tools, A2A connects agents to each other. Both now sit under the Linux Foundation. What this changes for your architecture choices — and what it does not solve.
Two acronyms recur in every presentation on agentic AI: MCP and A2A. For an architect, the useful question is not "which one wins" but "which layer does each address, and what do I still have to design myself".
Two protocols, two layers
MCP (Model Context Protocol) was introduced by Anthropic in November 2024. It standardizes how an agent connects to tools, databases and services: an MCP server exposes capabilities, a client (the application or agent) discovers and calls them. This is the agent ↔ tool axis.
A2A (Agent2Agent) was announced by Google Cloud in April 2025 and handed to the Linux Foundation in June 2025. It standardizes communication between agents, including from different organizations or vendors: discovering a remote agent's capabilities, delegating tasks, tracking progress. This is the agent ↔ agent axis. The two are presented as complementary: one connects inward (tools and data), the other outward (other agents).
Governance is now neutral
The notable development of the past twelve months is governance: A2A has been under the Linux Foundation since 2025, and MCP was donated to the Linux Foundation's Agentic AI Foundation in late 2025. The A2A project announced more than 150 organizations supporting the standard at its first anniversary, with integration across the major cloud providers' platforms. For a decision-maker, this answers a legitimate fear: investing in a proprietary protocol that would vanish. Lock-in risk drops; it doesn't disappear, since implementation, extensions and gateways remain vendor-specific.
What this changes in your architecture choices
- Expose your systems through MCP servers rather than coding one integration per agent and per model vendor. Integration cost goes from N × M to N + M.
- Plan an agent gateway: a single point to enforce authentication, quotas, logging and policy. The Linux Foundation itself hosts such a project, agentgateway, which handles MCP and A2A.
- Treat each MCP server as an attack surface: it gives an agent the ability to act. Inventory, minimal rights, review of third-party servers, and care about instruction injection through content the agent reads.
What standards do not solve
A protocol standardizes communication, not trust. It doesn't tell you whether a remote agent deserves a task, or who is accountable when a chain of several agents errs. It provides neither data quality, nor governance, nor end-to-end traceability: those are architecture decisions, to be made upfront. Finally, the number of available servers and libraries says nothing about their quality — most public servers weren't designed for an enterprise environment.
Practical recommendation
Adopt MCP as the access layer to your internal tools for use cases where you've already identified an agent and an owner. Delay cross-organization multi-agent scenarios (A2A) until your individual agents are observable and governed: orchestration complexity grows faster than value.
- MCP connects an agent to its tools; A2A connects agents to each other. They are complementary.
- Both standards now sit under the Linux Foundation, which reduces lock-in risk without eliminating it.
- Agent gateway, minimal rights and an inventory of MCP servers should be designed in from the start.
- A protocol standardizes communication, not trust, data quality or accountability.
Sources
Related reading
Does this challenge sound familiar?
A first conversation to assess it together, at no cost.