The multi-agent systems I’m building in the ACO framework don’t exist in isolation. Every agent needs to talk to tools, data sources, and — increasingly — other agents. Until recently, that meant writing custom integration code for every connection. The protocol landscape has shifted dramatically in the past year, and the combination of two protocols in particular is emerging as the standard stack for production agentic systems: MCP (Model Context Protocol) for tool and resource access, and A2A (Agent-to-Agent) for inter-agent communication.
What Each Protocol Actually Does
MCP solves the tool access problem. When an LLM-powered agent needs to query a database, read files, call an API, or interact with any external system, MCP provides a standardized way to expose that capability. The protocol defines how servers advertise their tools, how clients invoke them, and how responses flow back. Think of it as USB for AI agents — a common interface that decouples the agent from the specific implementation of any given tool.
The ecosystem numbers are striking. As of June 2026, the Model Context Protocol has surpassed 17,000 publicly listed servers and 97 million monthly SDK downloads according to the Zuplo State of MCP report. That’s not a niche technology — it’s infrastructure. The long tail of those servers is telling: specialized implementations for medical records, legal documents, real-time financial data, proprietary internal tools. Individual developers and organizations built exactly what they needed, and MCP made it reusable.
A2A, Google’s Agent-to-Agent protocol, addresses a different problem that emerges once you have multiple specialized agents working together. If MCP is USB, A2A is the protocol that lets two computers negotiate a file transfer without either knowing the other’s internal architecture. A2A defines how agents discover each other’s capabilities, how they negotiate task handoffs, how they share partial results across a multi-step workflow, and how they recover when a peer agent fails.
The A2A protocol reached v1.0 in April 2026 and has now surpassed 150 organizational adopters according to the Linux Foundation press release. Enterprise adoption is accelerating — SAP, Salesforce, and Intuit all announced production A2A integrations. More interestingly, major cloud platforms have native A2A support, which means the protocol is becoming a first-class primitive in cloud infrastructure rather than a custom add-on.
Why the Combination Matters for Multi-Agent Architecture
The most powerful multi-agent designs separate concerns along the MCP/A2A boundary. MCP handles vertical integration — agent-to-tool, agent-to-data-source. A2A handles horizontal integration — agent-to-agent coordination, capability discovery, task distribution.
In the ACO system I’ve been working on, this separation maps cleanly to the architecture. The orchestrator agent uses A2A to coordinate with specialized execution agents — telling them what to do, receiving results, handling failures. The execution agents use MCP to interact with the actual tools and data they need to complete those tasks. The orchestrator never needs to know how the execution agent accesses a database or calls an external API. It only needs to know whether the task got done.
This has a practical implication for reliability. When an MCP server changes its internal implementation or a tool’s API updates, only the MCP server definition needs to change. The A2A layer above it is unaffected. Similarly, when an agent’s role or capability changes, only the Agent Card (A2A’s capability advertisement mechanism) needs updating — peer agents discover and adapt automatically.
The Interface Contract Problem
The hardest part of building multi-agent systems isn’t designing individual agents — it’s defining the contracts between them. What information does Agent A need to provide to Agent B when handing off a task? How is partial completion represented? When does an agent escalate versus retry locally?
A2A’s task negotiation mechanism is an attempt to standardize these contracts. An Agent Card published by an A2A-compatible agent advertises its capabilities, supported input/output formats, and error handling semantics. When Agent A wants to delegate to Agent B, it queries B’s Agent Card to determine whether the fit is right before attempting the handoff.
This is a genuine advance over ad-hoc multi-agent integrations, but the contracts are still being worked out in practice. The IETF draft for A2A applicability to network management agents (expired August 2026, so under active development) suggests the protocol is expanding beyond enterprise chat and task handoffs into infrastructure management. That’s a sign of maturing semantics — the contract vocabulary is growing to cover more failure modes and edge cases.
What’s Still Missing
Production multi-agent systems built on MCP plus A2A still have real gaps. Authentication across the two layers doesn’t have a unified solution — MCP servers often rely on local credential stores, while A2A authentication is identity-based. A compromised MCP server can potentially access more than its nominal scope allows (the Confused Deputy problem identified in the April 2026 security study). And the discovery mechanism for A2A — how does Agent A find Agent B in a large fleet — is still largely organizational convention rather than a technical standard.
The MCP roadmap calls for SSO-integrated flows to address enterprise auth, but that’s bureaucratic language for a real gap. Until auth is solved at the protocol level, production deployments need careful thought about credential management and permission boundaries.
Despite these gaps, the MCP+A2A stack is the most coherent architecture for multi-agent systems I’ve worked with. The alternative — custom integration code for every agent-to-tool and agent-to-agent connection — doesn’t scale and doesn’t compose. The protocols aren’t perfect, but they’re real, they’re adopted, and they’re improving. That’s further along than most infrastructure standards get at this stage.