The agent protocol tax: MCP, A2A, and Llama Stack are not converging. Your tool inventory is the locked asset

Anthropic’s Model Context Protocol (MCP) reached open-spec public release in November 2024 and crossed broad client and server adoption through 2025. Cursor, Windsurf, Claude Code, an expanding catalogue of other agent platforms, and an active third-party server ecosystem all speak MCP. Google’s Agent2Agent (A2A) protocol was announced at Cloud Next in April 2025 and contributed to the Linux Foundation later in 2025. Meta’s Llama Stack consolidated through 2024-2025 as an open-source runtime specification covering agent execution, memory, evaluation, and tool-use, with its own protocol surface independent of MCP and A2A.

Three open protocols. Two complementary by stated scope (MCP for agent-to-tool, A2A for agent-to-agent). One full-stack runtime. None converging on a single standard. The four major proprietary agentic platforms, Microsoft Copilot Agent (inside M365 Copilot Studio and the Copilot Agent SDK), Salesforce Agentforce, SAP Joule, and ServiceNow Now Assist, maintain their own extensibility surfaces and do not adopt any of the three as a first-class default.

An enterprise picking an agentic AI platform in 2026 is, in almost every case, also picking a protocol team. The model decision sits on top of the protocol decision. The cost of being wrong on the model is low. The cost of being wrong on the protocol is high, because the locked asset is not the agent code. It is the tool inventory the agents call.

What the three open protocols actually do

MCP is the wrapper-and-call layer for agent-to-tool. An MCP server is a process that exposes a defined set of tools (file system, database, SaaS API, internal service) over a wire protocol. An MCP client is an agent runtime that discovers, authenticates to, and invokes the server’s tools. The spec is open and the server-side investment is portable across any MCP client. The relevant prior coverage is the enterprise tooling read in MCP and the coming standard for enterprise agent tooling.

A2A is the discovery-and-delegation layer for agent-to-agent. An A2A endpoint advertises a card describing the agent’s capabilities, authentication requirements, and pricing or rate-limiting terms. Another agent acting as an A2A client can find the endpoint, authenticate, delegate a task, receive a result, and (if appropriate) chain further work. The spec is designed to be complementary to MCP rather than competing with it, Google’s framing positions MCP as the in-agent tool layer and A2A as the inter-agent coordination layer. The relevant prior coverage is at A2A protocol: enterprise agent-to-agent interoperability.

Llama Stack is a different shape. Where MCP and A2A are protocols (wire formats with libraries), Llama Stack is a runtime specification covering agent execution, memory, evaluation, safety, and tool-use as integrated subsystems. Llama Stack has its own tool-use protocol, its own evaluation hooks, its own memory primitives, and its own safety filters. An enterprise running Llama Stack as the agent runtime has chosen the full vertical rather than composing MCP for tools and A2A for delegation.

The structural position is that MCP + A2A are designed to compose into a stack; Llama Stack is a vertically integrated alternative to that stack; and the four proprietary platforms ship their own equivalents at every layer. The fragmentation is not a temporary state of the market. Each of the four vendor positions (Anthropic-aligned MCP-first, Google-aligned A2A-first, Meta-aligned Llama-Stack-first, proprietary-platform-first) has incentives to maintain its own ecosystem.

Why the protocol decision is harder to reverse than the model decision

Three structural differences.

The locked asset is different. Swapping models, Anthropic Claude for OpenAI GPT, GPT for Google Gemini, Gemini for an open-weight Llama variant, is a configuration change at the model-client layer. The agent’s behaviour shifts and the prompts may need re-tuning, but the surrounding code base, the tool wrappers, and the authentication shims do not change. Swapping protocols means re-implementing every tool wrapper the agent depends on. An MCP server is not an A2A endpoint; an A2A card is not a Llama Stack tool plugin; a Llama Stack tool plugin is not a Copilot Agent extension. Each is a separately engineered artefact in its own ecosystem.

The volume is different. An agentic deployment at moderate scale has one to five model dependencies. The same deployment has tens to hundreds of tool dependencies, the file systems, ticketing systems, databases, observability platforms, business-process APIs, and internal services that the agents need to act on. The tool inventory is the long tail of the engineering work, and most of the long tail is custom or customer-extended.

The build is bespoke. Model APIs are the vendor’s responsibility to keep stable across the customer base. Tool wrappers are the customer’s responsibility, written against the chosen protocol’s specifics, its authentication conventions, its serialisation, its capability-discovery format, its error-handling contract. Customer-built MCP servers, A2A endpoints, and Llama Stack tool plugins are not portable across the protocols. The protocol decision sits underneath every tool decision the enterprise will make for the next five years.

A 2026 enterprise that has invested in 40 MCP servers for its internal-tooling agents is not lightly going to re-platform to A2A even if the strategic case for A2A is compelling. The re-platform cost is the 40 server rewrites plus the authentication-shim work plus the observability re-integration plus the operational tuning to get the new estate to the maturity of the old one. The cost is rarely modelled at procurement time because the procurement question is framed as “which agent platform should we buy” rather than “which protocol estate are we committing the next five years of tool engineering to”.

What the proprietary-surface picture adds

Microsoft’s Copilot Agent platform, the runtime inside M365 Copilot Studio and the Copilot Agent SDK, maintains its own agent-extensibility surface. Tool extensions are written as Copilot connectors or as Copilot Studio actions, with authentication, identity, and data residency handled inside the M365 admin and security surface. Salesforce Agentforce uses its own action and topic primitives. SAP Joule and ServiceNow Now Assist do the same inside their respective platforms. None of the four adopts MCP, A2A, or Llama Stack as the default extensibility protocol; each ships proprietary equivalents tailored to its platform’s identity model, data model, and admin surface.

The implication for an enterprise running a mixed portfolio is straightforward. Anthropic-aligned coding agents speak MCP. Google-aligned workflow agents speak A2A. Open-source-derived agents on Llama Stack speak Llama Stack’s tool protocol. Microsoft 365 Copilot agents speak the Copilot Agent surface. Salesforce CRM agents speak the Agentforce surface. SAP enterprise-resource agents speak Joule’s surface. ServiceNow ITSM agents speak Now Assist’s surface. Seven distinct protocol estates with no single tool wrapper portable across all of them.

The 2026 enterprise is not in a position to consolidate on one estate, because the four proprietary platforms each own a tool category (CRM, ERP, ITSM, M365) the customer has already committed to at the underlying SaaS layer. The protocol decision is therefore a per-platform decision, and the cumulative cost of tool wrappers is the sum across the platforms.

The five-line accounting an enterprise should run

The accounting is per protocol estate and per quarter, kept by the AI platform engineering function jointly with procurement.

Tool wrappers written. Count the MCP servers, A2A endpoints, Llama Stack tool plugins, or proprietary extensions the customer has built or contracted for in each estate. The count is the size of the locked asset on the customer’s books. A reasonable 2026 mid-market enterprise will discover it has built somewhere between 10 and 50 wrappers per active estate; large enterprises run materially higher.

Identity integrations. How each protocol estate authenticates to customer systems. This is where the protocol decision intersects with the NHI procurement clause gap at AM-167. Each estate carries its own assumptions about credential issuance, rotation, and revocation; the cumulative NHI inventory across estates is what the audit will surface.

Observability surface. Which agent observability platforms support which protocols natively versus through adapter layers. Langfuse, Arize, Helicone, and LangSmith (the procurement read at AM-122) each have varying coverage; the gap between native and adapter support is the operational tax on a multi-protocol estate.

Vendor lock-in by tool category. Which protocol estate owns which tool categories in the customer environment. CRM agents bound to Agentforce; ERP agents bound to Joule; ITSM agents bound to Now Assist; M365 agents bound to Copilot Agent; coding agents bound to MCP; cross-vendor coordination via A2A. The grid makes explicit what the protocol decision per category actually was.

Re-platform cost. The engineering hours required to port the tool wrappers from estate A to estate B if a strategic decision changed the primary protocol. The figure is rarely calculated up front; it should be, because the re-platform cost is the exit barrier when the strategic case to consolidate or to switch appears.

The five-line accounting is the procurement-side reality check on the “we’ll just use the best agent for each job” position. The cost of having no consolidation is the seven-estate maintenance burden. The cost of forced consolidation is the re-platform bill. The procurement decision is to make the choice deliberately rather than to discover it retroactively at audit or budget review.

The three procurement clauses missing from most 2026 agentic AI MSAs

Protocol portability disclosure. The vendor names the protocols its agent runtime supports as a client (which protocols its agents can speak to) and as a server (which protocols it can host). The vendor commits to keeping the supported-protocols list current and to documenting any deprecation with a defined notice period. Without the clause, the customer cannot defensibly model the re-platform cost above because the vendor’s protocol roadmap is opaque.

Tool inventory exit terms. On contract termination, the customer retains the tool wrappers it built or commissioned, in source form, with documentation of the authentication primitives they use. The clause is the customer’s protection against the protocol-estate becoming a vendor asset on termination. Without the clause, an enterprise that ends a relationship with the platform vendor may find the tool wrappers technically usable elsewhere but legally encumbered.

Protocol-roadmap commitment. The vendor commits to supporting the named protocol(s) for a defined minimum period (24 months is a reasonable floor for an established protocol like MCP), with a notification window (12 months) if the roadmap changes. The clause prices the vendor’s optionality on protocol changes back to the customer.

The three clauses sit alongside the NHI procurement clause set (AM-167) as the procurement-side instruments for the agentic-AI relationship. Neither set is in most 2026 standard MSAs; both are in the customer-redlined versions used by procurement-mature enterprises.

What this means for the IT leadership agenda

The first move is the protocol-estate inventory. Per platform under contract or in evaluation, name the protocol(s) the platform’s agents speak, the tool wrappers built or commissioned, the identity integrations, the observability surface, and the re-platform cost estimate to move to a different estate. The artefact is a one-page-per-estate document maintained quarterly.

The second move is the consolidation evaluation. With the inventory in hand, the strategic question becomes tractable: are we paying for seven estates or are there two or three where consolidation is feasible without giving up the proprietary advantages of the platforms that own a tool category? The answer is enterprise-specific; the inventory makes it possible to ask.

The third move is the contract template. The three protocol clauses above are the minimum viable additions to the standard agentic AI MSA. Procurement counsel attaches them to every new contract and to every renewal where the contract is open. The protection compounds: every renewal cycle closes the gap on one more platform.

The model decision will keep getting easier in 2026 as the model layer commoditises. The protocol decision will keep getting harder as each estate’s tool inventory grows. The procurement-mature enterprises in 2026 are the ones treating the protocol decision as the strategic decision the model decision used to be, and the model decision as the configuration decision the protocol decision was supposed to be. The publication will be tracking that inversion through the second half of 2026 and into 2027.