The numbers behind the convergence
For most of 2024 and the early half of 2025, anyone trying to ship an agent into a real enterprise had the same conversation about protocols: which one wins, and how long do we wait? That conversation is now over, and the answer is both of them, and the wait is up.
By February 2026, the Model Context Protocol (MCP) — Anthropic's open standard for connecting models to tools and data sources — had crossed 97 million monthly SDK downloads across Python and TypeScript combined, with adoption from every major model vendor: Anthropic, OpenAI, Google, Microsoft, and Amazon. The Agent-to-Agent protocol (A2A) — Google's standard for horizontal coordination between agents — had grown to 150+ participating organizations and was formally donated to the Linux Foundation in June 2025. ACP, the third major contender, is also now under Linux Foundation oversight. Over 100 enterprises have formally adopted both MCP and A2A as part of their reference architecture.
The structural shift is governance, not adoption. With all three protocols sitting under Linux Foundation oversight, the political risk that kept enterprise architects on the sideline — what if my vendor pulls the spec? — is gone. The two-layer stack (MCP for vertical tool integration, A2A for horizontal agent coordination) has stopped being a debate and started being a procurement requirement.
What the two protocols actually do, in one paragraph each
MCP gives an agent hands. It's a standard wire format for how a model talks to tools, data sources, and execution environments. Before MCP, every "connect Claude to your database" or "give the agent access to your ticket system" was a custom adapter — written once, maintained forever, broken on every model version bump. With MCP, the tool exposes a server, the model speaks the protocol, and the same integration works across vendors. Roughly 97 million downloads a month is what it looks like when an entire industry agrees on a port number.
A2A gives an agent colleagues. It's a standard for how one agent discovers, authenticates with, and delegates work to another agent — across team, vendor, and trust boundaries. Before A2A, multi-agent systems were one team writing both ends of the wire, which meant they didn't compose. With A2A, a customer-support agent at your vendor can hand a refund request to a billing agent at your company, with discovery, scope negotiation, and an audit trail that crosses both sides. 150+ organizations participating is what it looks like when interop stops being a slide and starts being a contract.
The two are complementary, not competitive. MCP makes one agent more capable. A2A makes many agents coordinate. The teams trying to pick one are solving the wrong problem.
What the convergence eliminates from your roadmap
If you were planning to build any of the following in 2026, the protocol stack just deleted that line item from your roadmap — and turned anything you've already shipped there into maintenance overhead competing with a free standard.
- A custom adapter between your agent and a third-party SaaS. That SaaS is going to ship an MCP server. If it hasn't, its competitor will. Building your own adapter is now a six-month head start that ends in six months.
- A bespoke "agent gateway" that handles auth, scope, and audit between agents. A2A handles discovery, capability negotiation, and identity claims as part of the protocol. Your gateway is reinventing what's already shipped.
- A model-specific tool definition for every agent in your stack. MCP tool definitions are model-agnostic by design. The whole point of the protocol is that the same tool server works for Claude, GPT, and Gemini agents without rewrites.
- A homegrown logging and audit layer for agent activity. Protocol-native observability is the next thing every vendor is shipping on top of MCP and A2A. Your homegrown layer will fight it instead of consuming it.
None of this means "throw out everything." It means the bet has shifted. In 2024 the custom integration layer was a moat; in 2026 it's a maintenance liability that locks you out of every protocol-native tool, agent, and audit surface vendors are about to ship.
What the convergence does not solve
Protocols make connections cheap. They don't make the system on the other end of the connection good. Three problems get harder, not easier, once the wire stops being the bottleneck.
Trust boundaries between agents. A2A makes it easy for an agent at company X to delegate work to an agent at company Y. It does not make it easy to decide whether you should. The policies that govern which agents are allowed to talk to which, at what scope, with what data, are policies you have to write — and the procurement, security, and legal review around them is now the actual gating step for production multi-agent deployments.
Evaluating multi-agent output. When one agent calls another via A2A and the second calls a tool via MCP and returns an answer, who is responsible for evaluating whether that answer was correct? The protocol doesn't say. Eval design for cross-vendor agent systems is a discipline most teams haven't started building, and it's the difference between a multi-agent demo and a multi-agent deployment that's auditable.
Scoped permissions and credential hygiene. MCP lets a tool server expose what it can do. It doesn't decide whether a given agent, called by a given user, in a given context, should be allowed to do it. The permission layer above the protocol — least privilege, time-bound credentials, per-action audit — is the part where production incidents live, and it's the part the protocol explicitly leaves to you.
What teams should do this quarter
The practical move is unglamorous and important. Audit your existing agent stack for custom integrations that overlap with MCP or A2A. Mark each one as "keep," "replace," or "wrap." Things that genuinely need bespoke logic — your proprietary scoring pipeline, your domain-specific RAG layer — keep. Things that are reinventing tool calling, discovery, or capability negotiation — replace, and use the time you save to build the policy, eval, and permission layers above the protocol that the standards explicitly don't provide. Things that can be wrapped behind an MCP server without changing internally — wrap, and make every model in your stack instantly able to call them.
The goal isn't to use the protocols for their own sake. It's to make sure every line of integration code you maintain is doing work the protocol doesn't already do, so your team's leverage stays in the layer where you actually differentiate.
Where Sonnet Code fits
A standards stack everyone agrees on is the easy half of agent engineering. The hard half is the layer above it — the policies, evaluations, and permission design that turn protocol-native plumbing into a production system you can defend in a security review. AI development at Sonnet Code is that engineering: auditing your current integration layer against MCP and A2A, replacing the parts that overlap with the standards, and building the trust-boundary, scoped-permission, and observability layer above the protocols where the real risk lives. AI training is the human-judgment half: senior engineers and domain experts who design the cross-agent evaluation harnesses that make multi-agent output measurable, and the review discipline that lets your team trust agent-to-agent delegation without rubber-stamping it.
The protocol stack converged. The differentiation moved up. The teams that win the next year are the ones that stop maintaining the layer the Linux Foundation now owns and start investing in the layer it doesn't.
