In 2023, AI agents were demos. In 2026, they're infrastructure.
But none of it works without protocols. Just as TCP/IP made the internet possible by letting disparate networks communicate, a new stack of protocols is making the agent ecosystem possible by letting autonomous systems built by different vendors, on different frameworks, in different clouds—actually talk to each other.
The two protocols at the center of this transformation are MCP (Model Context Protocol) and A2A (Agent2Agent). Together, they've gone from experimental specifications to production standards in under two years. And if you're building agents in 2026, you need to understand both.
The Problem: Agents Couldn't Talk to Each Other
Ask an engineering team how their AI agents communicate, and the answer used to be the same everywhere: glue code someone wrote last quarter. One team's research agent called another team's pricing agent over a bespoke endpoint. A vendor's support agent couldn't see your internal scheduling agent at all. Every integration was a custom project.
This is the agent interoperability problem, and it has a familiar shape. Many producers, many consumers, no shared contract. Without a standard, nothing coordinates across a vendor or an org chart. The promise of multi-agent AI systems stalls at the boundary of whoever wrote the integration.
The math makes it worse. If you have N agents and each pairing needs custom integration code, you need N² integrations. Ten agents means forty-five custom connections. Twenty agents means one hundred ninety. This doesn't scale.
The Protocol Stack: MCP, A2A, and Friends
The 2026 interoperability conversation is dominated by four protocols, but they layer rather than compete. Think of it as a stack:
- MCP operates at the tool layer—how an agent reaches a tool, data source, or file system
- A2A operates at the inter-agent layer—how one agent discovers, delegates to, and coordinates with another
- ACP (Agent Communication Protocol) handles REST-based multimodal messaging, now merged into A2A
- ANP (Agent Network Protocol) addresses orchestration and discovery across broader networks
The arXiv interoperability survey frames this as a phased adoption roadmap: MCP first for tools, A2A next for agent messaging, then ACP and ANP for broader networks. Not a winner-take-all race—a layered architecture where each protocol solves a distinct problem.
MCP: The Tool Layer
MCP, originated by Anthropic in late 2024, standardizes how an agent reaches a tool, a data source, or a file system. A client connects to an MCP server, discovers the tools it offers, and calls them over JSON-RPC—across stdio for local servers or HTTP for remote ones.
The adoption has been extraordinary. By mid-2026, MCP surpassed 97 million monthly SDK downloads. Every major AI platform supports it: Anthropic, OpenAI, Google, Microsoft, Salesforce, Snowflake, and most API gateway vendors. It is now the closest thing the industry has to a default wire format for tool access.
But MCP is about capabilities, not coordination. It never tells two agents how to talk to each other. It solves the problem of "how does my agent call this API"—not "how does my agent delegate work to another agent."
Critically, MCP is no longer controlled solely by Anthropic. It moved under the Linux Foundation's Agentic AI Foundation, co-founded with Block and OpenAI. In 2026 it gained a standardized enterprise auth layer covering OAuth, role-based access control, and audit logging—the kind of plumbing large IT departments actually require before they connect an agent to production systems.
A2A: The Inter-Agent Layer
If MCP is how an agent reaches its instruments, A2A is how it reaches its colleagues.
A2A, announced by Google in April 2025 with more than fifty launch partners, lets independent agents discover and delegate to each other. Each agent publishes an agent card at /.well-known/agent-card—a structured manifest describing its skills, endpoints, and auth requirements. A client agent reads the card, then sends a task that moves through a defined lifecycle.
The technical implementation is deliberately conservative. A2A operates over HTTP using JSON-RPC 2.0 with Server-Sent Events for streaming. It integrates with existing web infrastructure rather than requiring new protocol layers. This design choice—building on technologies enterprise teams already understand—explains the speed of adoption.
By the project's one-year mark in April 2026, the Linux Foundation reported more than 150 supporting organizations, over 22,000 stars on the core repository, and official SDKs in five languages: Python, JavaScript, Java, Go, and .NET. Version 1.0 shipped in March 2026, introducing signed agent cards, enterprise-grade multi-tenancy, and modernized security flows.
The governance detail matters enormously. A protocol controlled by one cloud vendor is a strategy. A protocol held by a neutral foundation is infrastructure. Enterprises will not bet a coordination layer on one company's roadmap, which is why the transfer to the Linux Foundation preceded the sharpest phase of adoption.
Why Linux Foundation Governance Changes Everything
Both MCP and A2A now sit under the Linux Foundation. This isn't a technical detail—it's a strategic one.
When Anthropic donated MCP to the Linux Foundation's Agentic AI Foundation (co-founded with Block and OpenAI), and Google donated A2A in June 2025, they did something unusual in the tech industry: they gave up control. The founding members of the Agentic AI Foundation read like a who's-who of enterprise software: AWS, Cisco, Google, Microsoft, Salesforce, SAP, and ServiceNow.
Neutral stewardship means no single vendor can change either protocol unilaterally. This reduces lock-in risk and gives enterprises confidence to build on these standards. When you're building production systems that will run for years, that kind of backing matters a great deal.
The comparison to TCP/IP is deliberate. The internet protocols succeeded not because they were technically perfect, but because they were open, neutral, and governed by institutions that no single company controlled. MCP and A2A are following the same playbook.
What This Looks Like in Production
By Google Cloud Next 2026 in April, A2A version 1.2 had shipped and the protocol was running in 150 organizations in production—not pilot projects. Microsoft, AWS, Salesforce, SAP, and ServiceNow all have production deployments.
The use cases are concrete:
- Cross-vendor coordination: A Salesforce agent delegates to a ServiceNow agent without custom integration code
- Multi-cloud workflows: An AWS-based analytics agent hands off to an Azure-based reporting agent
- Supply chain automation: A procurement agent discovers and negotiates with vendor agents autonomously
- Enterprise orchestration: A root orchestrator dispatches tasks to domain-specific agents (HR, finance, IT) via A2A, with each agent using MCP to access its tools
The pattern that emerges is consistent: MCP for internal tool access, A2A for external agent collaboration. Single agent plus tools? MCP only. Multi-agent orchestration? MCP + A2A.
The Security Model
Protocols without security are attack vectors. Both MCP and A2A have evolved significantly in this area through 2026.
For MCP, the 2026 specification releases introduced three critical improvements:
DPoP (Demonstrating Proof of Possession) binds tokens to a cryptographic key, so a stolen token can't be replayed by an attacker. This neutralizes the most common attack vector.
Workload Identity Federation eliminates long-lived static keys on servers. Instead of storing API keys in environment variables, agents authenticate using short-lived tokens issued by a trusted identity provider.
Agent Identity and Delegation defines how MCP servers should handle requests from agents acting under their own identity versus agents acting on behalf of a user. This is the foundation for fine-grained authorization policies.
For A2A, version 1.0 introduced signed agent cards—a cryptographic signature that lets a receiving agent verify the card was actually issued by the domain owner. Without this, an attacker could stand up a fake agent card and redirect other agents into a card forgery attack. The signed-card capability is the single most important security addition because it closes the trust gap that prevented defensible cross-organization integration in earlier versions.
The 90-Day Adoption Roadmap
If you're an enterprise architect looking at this landscape, the path forward is straightforward but requires intentionality. Here's the phased approach that's working:
Days 1-20: Inventory and Assessment
Map your architecture. Inventory the tools your agents need to touch—CRM, helpdesk, commerce, finance, internal APIs. Confirm which already have MCP servers available and which need building. Identify which agents need to communicate with each other and across what boundaries.
Days 21-45: Standardize on MCP
For your first agentic project, standardize on MCP for all tool connections. Build any missing integrations as reusable MCP servers, not one-off connectors tied to a single model. This ensures your tool layer is portable across agents and vendors.
Days 46-65: Design A2A Handoffs
If your use case needs more than one agent, design the handoffs explicitly over A2A. Document which agent owns which step and what each one passes to the next. Implement a root orchestrator that can discover and delegate to domain agents via their agent cards.
Days 66-80: Procurement and Policy
Write MCP and A2A support into your standard procurement and vendor-evaluation templates. Every future agentic AI engagement should inherit the requirement automatically. This prevents lock-in at the contract level, not just the architecture level.
Days 81-90: Governance and Board Briefing
Brief the board on interoperability as a vendor-risk control. Frame MCP + A2A as the portability insurance that lets the business adopt agentic AI without betting the estate on a single vendor. This isn't a technical detail—it's a strategic risk decision.
Common Pitfalls to Avoid
The biggest risk at this stage is not moving slowly. It is moving without a coherent strategy. Many enterprise teams have a dozen MCP experiments running in parallel with no shared infrastructure, no governance, and no one connecting the dots. That is not progress. That is technical debt.
Other pitfalls to watch for:
- Treating protocols as an afterthought: Bolting on MCP or A2A after agents are built creates integration debt that's expensive to fix
- Ignoring governance: Standardized protocols enable interoperability, but who governs which agents talk to which tools? You need a policy layer, not just a transport layer
- Assuming vendor neutrality: Just because a protocol is open doesn't mean your implementation is portable. Avoid proprietary extensions that create hidden lock-in
- Skipping the security model: DPoP, signed agent cards, and workload identity federation aren't optional for production deployments
The Bottom Line
AI agent interoperability is no longer a research problem. It's an engineering discipline with mature protocols, production deployments, and neutral governance. The question isn't whether to adopt MCP and A2A—it's how quickly you can migrate your existing integrations to these standards.
The organizations that build with open protocols from the start are positioning themselves to avoid lock-in. The ones that defer the protocol decision are accumulating switching costs that compound with every additional agent they deploy.
Industry analysts project that by the end of 2026, 40% of enterprise applications will include task-specific AI agents. The enterprises that thrive will be the ones whose agents can talk to each other—across vendors, across clouds, across organizational boundaries.
MCP and A2A are the protocols making that possible. They're not perfect. They're not final. But they're open, they're governed neutrally, and they're running in production at scale.
That's more than you can say for most of the agent stack.