On this page
MCP and A2A Together: Building Multi-Agent Systems in 2026
MCP and A2A have emerged as the de facto standard stack for building production multi-agent systems in 2026. However, most enterprises hit a hidden scaling wall not from protocol limitations, but from immature operational infrastructure for identity, observability, and cost governance. Teams can connect agents to tools, but struggle to govern, observe, and manage agent fleets at production scale.
The AI agent protocol wars are over, and the wrong side won. MCP has become the de facto standard for tool access with 97 million monthly SDK downloads and 10,000 public servers, while A2A reached v1.0.0 with 24,000+ GitHub stars for agent coordination. Both live under the Linux Foundation’s Agentic AI Foundation. Protocol consolidation looks like victory. But here’s the uncomfortable truth: the protocol layer is the easy part. The operational layer — identity, observability, cost governance — is where production multi-agent systems quietly fall apart.
I’ve been tracking what I call the Operations Lag pattern: enterprise agentic AI in 2026 faces an adoption velocity mismatch where protocol layers have reached commodity status (4,750% growth in 16 months), while the operational infrastructure layer remains dangerously immature. The result is a hidden scaling wall. Teams can connect agents to tools but cannot govern, observe, or economically manage agent fleets at production scale.
The Layered Stack Is Real, Not Theoretical
The cleanest mental model for 2026 is this: MCP is agent-to-tool, A2A is agent-to-agent. MCP uses JSON-RPC 2.0 over stdio or HTTP/SSE transport to standardize how a single agent reaches databases, APIs, and file systems. A2A handles discovery, task delegation, and coordination between autonomous agents — even across vendor boundaries. IBM’s Agent Communication Protocol (ACP) has been consolidated into A2A under the Linux Foundation, leaving two protocols where there were once four or more.
This isn’t a competition. It’s a stack. Google’s own framing captures it: A2A is the horizontal bus, MCP is the vertical bus. You need both when specialized agents own different tools and need to coordinate on a single request.
The orchestrator-worker pattern dominates production architectures. An orchestrator agent delegates tasks to specialized worker agents via A2A, and each worker uses MCP to access its required tools. A researcher agent queries web and databases through MCP. A coder agent hits GitHub and execution environments. A reviewer agent runs tests and triggers deployments. The orchestrator never touches tools directly — it coordinates.
Where Production Actually Breaks
Here’s what the protocol diagrams don’t show you. 63% of enterprises are piloting AI agents, but fewer than 25% have scaled them to production. The gap between pilot and production isn’t model capability. It’s operational infrastructure.
Context degradation hits first. Research from Google shows that single agents using more than 10-15 tools experience measurable degradation — the model starts missing instructions, calling wrong tools, or hallucinating parameters. Each additional tool dilutes attention across a wider surface area. The multi-agent architecture solves this by giving each agent a narrow scope, but that’s where A2A becomes mandatory, not optional.
Blast radius is the second killer. One unhandled exception in a monolithic agent crashes the entire workflow. A rate limit on a translation API shouldn’t bring down your contract analysis pipeline. Splitting agents apart contains failures, but it also introduces coordination complexity that MCP alone cannot address.
The governance gap is the silent killer. Before June 18, 2026, the standard MCP authorization model required every employee to manually authenticate to every MCP server individually during onboarding. Security teams had no mechanism for consistent access policy or centralized audit trails. That changed when enterprise-managed authorization (EMA) for MCP became stable, replacing the per-user OAuth loop with an identity-provider-mediated delegation model. One login, governed access across every compatible MCP server. This is the kind of infrastructure that makes MCP production-viable inside large organizations.
The Cost Nobody Budgets For
MCP server pricing varies 100x across vendors, from €150/month flat-rate platforms to $130k/year enterprise iPaaS. That sticker price is a measurement problem, not a total cost. The real cost driver is token spend: mid-market teams running Sonnet across 12 connectors regularly burn €20k-€80k/year in Anthropic tokens alone. A single Claude conversation averages 8-15 tool calls, so per-call pricing scales roughly 4x faster than headcount.
For a 50-developer multi-agent deployment using mid-market MCP server pricing (Workato at $50k-$130k/year) plus Anthropic token costs for 12 connectors (€20k-€80k/year), the total year-one infrastructure cost range lands at $50k-$130k + €20k-€80k before engineering labor. And that’s the optimistic scenario where tool calls are well-architected and loops are bounded.
The pricing opacity is structural. Five different vendors price five different ways — per tool, per call, per seat, per workspace, or flat-rate with warehouse included. Headline stickers rarely match what teams actually pay after token costs, data residency surcharges, and overage charges land in the renewal invoice. CFOs are being asked to approve budgets for a cost structure they cannot forecast.
What the July 28 Spec Change Actually Means
The MCP 2026-07-28 release candidate removes the session handshake, making the protocol stateless at the protocol layer. The initialize/initialized handshake disappears. The Mcp-Session-Id header goes away. A tool call becomes a single self-contained HTTP request that any server instance can handle.
This matters for production scaling. Gateways can now route on Mcp-Method and Mcp-Name headers without parsing JSON bodies. Load balancers don’t need session affinity. Horizontal scaling of MCP server instances becomes trivial compared to the sessionful model that preceded it. If you’ve been running MCP servers behind sticky sessions, the July spec removes that constraint entirely.
The Build-vs-Buy Calculus Has Shifted
Multi-agent orchestration isn’t a single capability — it’s at least five distinct layers, each with different economics. Foundation models: buy via API. Tool integrations: hybrid (buy standard connectors, build custom ones). Observability: buy via platform. Domain logic: build, because competitors can’t replicate your business rules by purchasing the same vendor.
The hybrid model — open-source framework plus managed platform — now dominates enterprise agent orchestration. First-party engineering reports show custom orchestration becomes a multi-quarter effort for most teams, while managed platforms ship materially faster. Gartner forecasts that over 40% of agentic AI projects will be canceled by the end of 2027, and the junction between orchestration assumptions and domain logic requirements is where most fail.
Domain logic is the only layer where building consistently outperforms purchasing. Everything else has commodity alternatives that ship faster and cost less to maintain.
Where to Invest Now
The protocol layer is won. MCP and A2A are infrastructure commodities with Linux Foundation governance, multi-vendor support, and rapidly maturing SDKs. Redirect engineering investment from custom orchestration to governance and observability. Specifically:
- Implement EMA for MCP now that it’s stable. The zero-touch SSO model eliminates the per-tool authorization prompt that was blocking enterprise adoption.
- Invest in trace-based evaluation platforms. You cannot govern what you cannot observe. LangSmith already serves 300 enterprise customers with 15 billion agent traces. That’s the infrastructure layer multi-agent systems need.
- Bound your tool-call loops. Token costs scale 4x faster than headcount. Architect agents to use 10-15 tools maximum, and delegate to specialist agents beyond that threshold.
The next wave of enterprise agent failures won’t stem from model capability. They’ll stem from operational infrastructure — identity management for non-human agents, cost visibility across exploding tool-call volumes, and governance frameworks that can’t keep pace with deployment velocity. The teams that recognize the Operations Lag pattern now will be the ones that actually scale past pilot.
What’s your production experience been — are you seeing the governance gap hit before or after the cost wall?