Part 2 of the series "The Agent Coordination Gap"
What the Emerging Protocols Actually Do, What They Do Not Do, and Why the Gaps Matter
Two Protocols, One Assumption
The first article in this series described the agent coordination gap: dozens of agents running across multiple vendor platforms with no coordination layer between them. The instinctive response is to look for standards. If agents cannot talk to each other, build a protocol. If vendor ecosystems are siloed, build a bridge.
Two protocols have emerged as the leading candidates for that bridge. The Model Context Protocol (MCP), originated by Anthropic, provides a standard way for AI agents to connect to tools, data sources, and external services. Google's Agent-to-Agent Protocol (A2A) provides a standard way for agents to discover, communicate with, and delegate tasks to other agents. IBM's Agent Communication Protocol (ACP), which launched in March 2025 for its BeeAI open-source platform, merged into A2A under the Linux Foundation later that year, consolidating the agent communication landscape around a single specification.
Both protocols have significant organizational momentum. Both are under Linux Foundation governance. And both share a common assumption: that the core challenge is connectivity. Get the agents talking to each other, and coordination will follow.
That assumption is wrong. Connectivity is a prerequisite for coordination, not a substitute for it. What MCP and A2A provide is plumbing. What enterprises need is plumbing plus governance, trust infrastructure, conflict resolution, and decision authority frameworks that neither protocol was designed to deliver. Understanding exactly what these protocols do, and where they stop, is essential for any enterprise building an agent coordination strategy.
What MCP Does
MCP is a standard interface between AI agents and the tools, data sources, and services they need to access. Think of it as a universal adapter. Before MCP, every integration between an agent and an external service required custom code: a bespoke connector to a CRM, a custom API wrapper for a database, a one-off integration with a file storage system. MCP standardizes the connector pattern so that a tool built once can be used by any MCP-compatible agent.
The protocol has moved quickly from concept to adoption. Anthropic donated MCP to the Agentic AI Foundation (AAIF) at the Linux Foundation in December 2025, alongside contributions from Block (the open-source Goose framework) and OpenAI (the AGENTS.md specification). By mid-2026, the ecosystem had grown to more than 10,000 active public MCP servers, with the Python and TypeScript SDKs reaching 97 million monthly downloads according to Anthropic's ecosystem reporting. A Stacklok survey conducted with the AAIF, polling 100 senior software engineers at US and UK enterprises, found that 41% of respondents report MCP in production environments.
That adoption number deserves scrutiny. The same Stacklok survey found that 86% of MCP usage across those organizations is still experimentation or local development. Only 5% report governed, enterprise-wide production deployments. The gap between "we use MCP" and "we use MCP in production, at scale, under governance" is wide.
MCP's current specification covers resource access, tool invocation, and prompt templates. Its security model has improved significantly with the addition of OAuth 2.1 for remote server authentication. The protocol's roadmap, published through the AAIF, includes audit trails, SSO integration, gateway behavior standards, and configuration portability.
What MCP does not do is equally important. The current specification has no structured logging mandate, meaning there is no standard way to audit what an MCP-connected agent did, when, and why. Fine-grained authorization is left to implementers: the protocol provides the authentication layer (verifying identity) but does not specify how to enforce what a given agent is allowed to do once authenticated. There is no way to attach policy constraints ("read-only access," "EU data residency required," "transactions under $5,000 only") to an MCP connection at the protocol level. Those constraints, if they exist at all, must be implemented in the server, in the agent, or in a layer that sits above both.
The MCP Security Surface
MCP's rapid adoption has opened a new attack surface that enterprise security teams are only beginning to assess.
The most direct threat is tool poisoning. MCP servers describe their capabilities to agents using natural language descriptions that the agent's language model processes as part of its context. Researchers have demonstrated that malicious instructions can be embedded in those descriptions, invisible to the user but parsed by the model. An MCP tool that describes itself as "a read-only file browser" could include hidden instructions directing the agent to exfiltrate data to an external endpoint. The attack works because agents trust tool descriptions as authoritative metadata, not as untrusted input.
A related vector is the rug pull: an MCP server that behaves normally during an approval or review process, then changes its tool descriptions after it has been granted access. Because MCP servers are typically connected dynamically, the descriptions an administrator reviewed at setup may not be the descriptions the agent sees during operation.
Prompt injection through tool results is a third concern. Even when the tool description is clean, the data returned by a tool can contain instructions that the agent's language model interprets as commands. A database query that returns records containing adversarial text could redirect the agent's behavior without the user or the server operator being aware.
These are not theoretical concerns. The OWASP Foundation published an MCP Top 10 risk list covering these and additional attack vectors. A peer-reviewed study tested MCP security across multiple agent platforms and found attack success rates ranging from 0% (Claude Desktop, which sandboxes tool interactions) to 100% (Cursor, which auto-executes tool calls without user confirmation). The variation across platforms highlights a deeper issue: MCP defines connectivity, but security posture depends entirely on how each platform implements it.
For enterprise security teams, the implication is that MCP server vetting needs the same rigor applied to third-party software supply chain management, and in some ways more, because the attack surface is novel and the tooling for defense is immature.
What A2A Does
If MCP connects agents to tools, A2A connects agents to each other. The protocol provides a standard way for agents to discover one another, exchange messages, negotiate capabilities, and delegate tasks across organizational and platform boundaries.
A2A reached its v1.0 stable specification in early 2026 with more than 150 supporting organizations. The protocol has attracted significant cross-vendor support: Google, Microsoft, Salesforce, SAP, ServiceNow, and others have committed to implementation. A2A has accumulated more than 22,000 GitHub stars, and SAP and ServiceNow have reported initial production deployments.
The protocol's architecture centers on the Agent Card, a machine-readable document that describes what an agent can do, what protocols it supports, and how to communicate with it. A2A v1.0 introduced signed Agent Cards using JWS (JSON Web Signature) with JCS (JSON Canonicalization Scheme) for domain verification, providing a cryptographic mechanism to confirm that an Agent Card was published by the domain that claims it. The specification supports three communication bindings: JSON-RPC 2.0, gRPC, and HTTP+JSON, giving implementers flexibility in how agents exchange messages.
A2A's task model is straightforward. One agent (the client) sends a task to another agent (the server). The server processes the task and returns results, potentially including artifacts such as files or structured data. Tasks can include streaming updates, allowing long-running operations to report progress.
What A2A does not do is where the enterprise coordination challenge begins. The protocol provides no standardized registry API for agent discovery at scale. Signed Agent Cards verify that an agent is who it claims to be, but they do not answer the question an enterprise needs answered before routing a task: Is this agent authorized to perform this action in this context, with this data, under this governance framework? A2A provides no presence or health signaling, so a client agent cannot determine whether a target agent is available, overloaded, or degraded before sending a task. And task state visibility is coarse: the protocol reports whether a task is submitted, working, completed, or failed, but provides limited insight into what is happening inside a multi-step task execution.
The ACP Merger and What It Signals
IBM launched the Agent Communication Protocol in March 2025 as the communication layer for its BeeAI open-source agent platform. ACP addressed a genuine need: a lightweight, HTTP-based protocol for agent-to-agent messaging that did not depend on any single vendor's infrastructure.
By August 2025, ACP had merged into A2A under the Linux Foundation. Kate Blair of IBM Research joined the A2A Technical Steering Committee. The migration path was documented: replace ACP endpoints with A2A task methods, convert service manifests to Agent Cards, and adopt JSON-RPC 2.0 as the primary binding.
The merger is significant for two reasons. First, it removed what could have become a fragmenting force in the standards landscape. Two competing agent-to-agent protocols, both under open governance, would have forced implementers to choose sides or support both, replicating the kind of fragmentation the protocols were designed to solve. Consolidation under A2A gives the enterprise a single specification to target.
Second, the merger signals that the protocol layer may be reaching a natural equilibrium. MCP for agent-to-tool connectivity. A2A for agent-to-agent communication. Distinct protocols for distinct problems, both under Linux Foundation governance, with enough cross-vendor support to suggest durability. The standards landscape is more coherent than it was a year ago.
But coherence at the protocol layer does not mean coherence at the coordination layer. The merger resolved a specification conflict. It did not resolve the governance, trust, and authority questions that make multi-agent coordination hard.
The Governance Foundation
The institutional infrastructure around these protocols has matured rapidly. The Linux Foundation launched the Agentic AI Foundation (AAIF) in December 2025, providing a neutral governance body for MCP and related agentic AI standards. Platinum founding members include Amazon, Google, Microsoft, Bloomberg, and Cloudflare. Membership has grown from 146 organizations in February 2026 to 247 by August 2026. David Nalley of AWS serves as governing board chair.
AAIF houses not just MCP but also Goose (Block's open-source agent framework) and AGENTS.md (OpenAI's specification for making repositories agent-accessible). The foundation provides the governance structure that enterprise adopters need to see before committing to a standard: vendor-neutral stewardship, transparent specification processes, and a membership base broad enough to discourage any single organization from capturing the standard.
The institutional maturity is real. But it addresses protocol governance, not deployment governance. AAIF ensures that the specifications evolve through an open, multi-stakeholder process. It does not, and is not designed to, tell an enterprise how to govern the agents that use those specifications. That is the enterprise's problem.
The Enterprise Readiness Gap
The gap between protocol availability and enterprise readiness is measurable. A recent arXiv preprint assessing both MCP and A2A against a set of 12 governance features required for enterprise-grade multi-agent systems scored each protocol at 1 out of 12. The paper's framework included capabilities such as expressing constraints, supporting deliberation between agents, implementing voting mechanisms, enabling human escalation, and attaching audit metadata. Neither protocol supports any of these at the specification level.
This is not a criticism of the protocols. MCP and A2A were designed to solve connectivity, and they solve it well. The governance gap exists because connectivity and governance are different problems, and the protocols intentionally left governance to the layer above.
But the layer above does not exist yet for most enterprises. The Agent Service Bus framework described in the Arion Research Orchestration series identifies five capabilities that a coordination layer needs: Capability Discovery, Intent Resolution, Contract Negotiation, Conflict Arbitration, and Routing and Orchestration. MCP contributes to Capability Discovery (agents can find tools) and A2A contributes to it as well (agents can find other agents through Agent Cards). But neither protocol addresses Intent Resolution (translating a business request into a coordinated multi-agent plan), Contract Negotiation (establishing terms and boundaries for agent collaboration), or Conflict Arbitration (resolving disagreements when agents recommend contradictory actions).
The three-tier decision authority model from the Operating Model Gap series (Tier 1: agent acts freely, Tier 2: AI recommends and human decides, Tier 3: human only) illustrates the missing layer. Neither MCP nor A2A provides a way to express decision authority tiers in a protocol message. An agent delegating a task through A2A cannot attach a constraint that says "this task requires Tier 2 authority: present the recommendation to a human before executing." That logic, if it exists, lives in the agent's own code or in an orchestration layer, not in the protocol.
The practical consequence is that enterprises adopting MCP and A2A must build the governance, trust, and authority layers themselves. The protocols give them a way to connect. They do not give them a way to coordinate.
The Token Tax
Beyond governance, there is a practical efficiency question that enterprises are encountering in production. At the Ask 2026 conference in March 2026, Perplexity CTO Denis Yarats described why his company moved away from MCP internally: connecting three MCP servers consumed approximately 72% of the available context window before the agent processed a single user query. The tool descriptions, capability metadata, and protocol overhead consumed so much of the model's attention budget that the agent's ability to reason about the user's request was significantly degraded.
Perplexity's experience reflects a real engineering tension. MCP's design philosophy is to give agents rich, natural-language descriptions of every available tool so the model can reason about which tools to use. At small scale, with a handful of tools, this works well. At enterprise scale, where an agent might have access to dozens or hundreds of MCP servers, the cumulative description payload becomes a performance constraint. The token cost is not just computational. It is cognitive: every token spent describing tools is a token unavailable for reasoning about the task.
This is a solvable engineering problem. Server-side filtering, lazy loading of tool descriptions, hierarchical capability registries, and other architectural patterns can manage the token budget. But the fact that a $9 billion AI company found MCP's overhead unworkable for its own internal use case is a signal that enterprise-scale MCP deployments require architectural decisions that the protocol itself does not prescribe.
What Comes Next
The standards landscape is clearer than it was a year ago. Two protocols have established themselves as the leading specifications for agent connectivity, both under credible open governance. The ACP merger eliminated a potential fork. Institutional infrastructure through the AAIF provides a foundation for long-term standards stewardship.
But connectivity is the first layer, not the last. The enterprise coordination challenge is a stack: connectivity at the bottom (MCP, A2A), governance and policy in the middle (decision authority, trust frameworks, audit requirements), and organizational design at the top (cross-functional coordination, human-in-the-lead oversight, accountability structures). The protocols address the bottom layer. The middle and top layers are where the hard work begins.
The next article in this series examines the Agent Service Bus in practice: how the five capabilities of the coordination framework (Capability Discovery, Intent Resolution, Contract Negotiation, Conflict Arbitration, and Routing and Orchestration) build on the protocol foundation to address the governance and coordination gaps that MCP and A2A intentionally leave open.
Strategy Playbook
1. Protocol Adoption with Governance Overlay. Adopt MCP and A2A as the connectivity foundation for your multi-agent architecture, but do not treat protocol adoption as a governance strategy. For every MCP server deployed, define the authorization policies, logging requirements, and data residency constraints that the protocol does not enforce. For every A2A integration, specify the decision authority tier, escalation path, and conflict resolution rules that the protocol does not carry. The governance overlay is your responsibility. The protocol will not build it for you.
2. MCP Security Assessment. Treat MCP server vetting with the same rigor you apply to third-party software supply chain management. Catalog every MCP server connected to your agent estate. Assess each for tool poisoning risk (review tool descriptions for hidden instructions), rug-pull exposure (monitor for description changes post-approval), and prompt injection vectors (evaluate what data the server returns and whether it could contain adversarial content). Establish a review cadence: MCP server descriptions are not static, and a server that was safe at setup may not remain safe.
3. Standards Consolidation Roadmap. If your organization adopted ACP, begin planning the migration to A2A. The technical migration (replacing ACP endpoints with A2A task methods, converting service manifests to Agent Cards) is documented and straightforward. The harder migration is organizational: retraining teams, updating documentation, and aligning internal tooling. Start the roadmap now while ACP and A2A are still close enough architecturally that migration is a translation exercise rather than a redesign.
4. Token Budget Architecture. Do not wait until production to discover that MCP tool descriptions consume most of your agents' context windows. Measure the token overhead of your current MCP configuration. If agents connect to more than five or six servers, evaluate server-side filtering, lazy description loading, or a capability registry pattern that gives agents summarized metadata with the ability to request detailed descriptions on demand. The 72% figure from Perplexity's experience is an extreme case, but the underlying engineering constraint, that description payload scales linearly with connected servers, applies to every deployment.
Arion Research advises enterprise leaders on AI strategy and the shift to a digital workforce.
