Six protocols. The wrong question is which one wins.

In 18 months, the number of protocols competing to become the standard for AI agent commerce went from zero to six. These are not minor variations on the same idea. ACP and UCP have fundamentally different architectures. MCP was designed to solve a completely different problem than A2A. Visa TAP is a transaction authentication protocol, not a communication standard. AP2 is an Anthropic initiative to create an open standard for agent-to-agent payment negotiation.

The instinctive response to this fragmentation is anxiety. Which one do you bet on? What if you build for ACP and UCP wins? What if you spend six months integrating A2A and the market decides agents do not need to talk to each other?

We think this is the wrong frame. The question is not which protocol wins. The question is which layer you are operating in, and whether that layer's value is dependent on protocol selection. We have a strong opinion on this, and we are going to defend it with data.

What each protocol actually solves

Before we can analyze which protocols will win, we need to be precise about what each one does. Most analysis we have seen conflates these six protocols as if they are all competing for the same thing. They are not. They solve different problems at different layers. Understanding this is the key to making a rational bet.

They are not all competing for the same thing

Once you map what each protocol solves, the apparent fragmentation resolves into something coherent. These are not six versions of the same idea. They are six protocols solving different problems at different layers of the stack.

The real competition is within layers, not across them:

Tool Access layer: MCP has already won. There is no credible competitor. The 97M downloads/month and Linux Foundation governance make this a settled question. If you are building tools for agents, you are building MCP servers. Full stop.

Commerce layer: ACP vs. UCP is a real competition. They solve the same problem (agent-initiated commerce) from different angles (agent-first vs. merchant-first). This will be decided by merchant adoption and payment rail coverage. Our opinion: they will coexist, with ACP dominant for payment-led flows and UCP dominant for catalog-led flows.

Coordination layer: A2A vs. AP2 is not yet a real competition because neither has meaningful traction. A2A has the enterprise partnerships, AP2 has the better protocol design. This layer will not matter until 2027-2028 when multi-agent deployments become common.

Trust layer: TAP has no competitor. Visa is the only player solving agent transaction authorization at the protocol level. The question is not whether TAP wins the trust layer, but whether the trust layer matters in the next 2 years. Our opinion: it does not, yet. Most agent transactions today are human-supervised (the human reviews and approves each purchase). Autonomous spending at scale is a 2028+ problem.

The convergence thesis

Here is our prediction: these six protocols will collapse into 2-3 surviving standards by 2028. Not because the losers are bad, but because the market cannot sustain six concurrent standards. Developer attention is finite. Integration budgets are finite. The convergence will follow a predictable pattern.

Phase 1: Tool layer consolidation (already happened)

MCP won. This is done. Every alternative tool-calling interface (LangChain's native tools, CrewAI's tool definitions, custom function calling schemas) is either adopting MCP or becoming irrelevant. The speed of this consolidation surprised everyone, including Anthropic. It took 18 months from launch to de facto standard.

Phase 2: Commerce layer consolidation (2026-2027)

ACP and UCP will either merge or one will absorb the other. Our bet: they merge into a unified standard, likely under Linux Foundation governance, by late 2027. The economic incentive is overwhelming. Merchants do not want to implement two commerce protocols. Agents do not want to maintain two checkout flows. The merge will look like: UCP's merchant catalog format + ACP's payment intent schema + a new governance body.

If they do not merge, ACP wins. The reason is simple: ACP has OpenAI and Stripe. OpenAI has the largest consumer agent deployment (ChatGPT). Stripe has the largest payment processing network. Distribution wins protocol wars, and ACP has more distribution than UCP.

Phase 3: Coordination layer consolidation (2027-2028)

A2A and AP2 address different coordination problems (task delegation vs. payment negotiation), so they may coexist as complementary standards rather than competing. If forced to choose, we think AP2's rail-agnostic design gives it a better long-term position. A2A's enterprise partnership model risks becoming a lowest-common-denominator standard that satisfies everyone but delights no one.

Where value captures

This is the question that matters for anyone building a business in this space. If you understand where value captures in the protocol stack, you can make a rational decision about where to build. Get this wrong and you build a business that gets commoditized when the protocols consolidate.

Protocol layer: low value capture, high influence

Nobody makes money from protocols directly. HTTP does not generate revenue. TCP/IP does not generate revenue. JSON-RPC does not generate revenue. The companies that created these protocols (or contributed to them) gained influence and ecosystem position, but not direct protocol revenue.

The same will be true for MCP, ACP, UCP, A2A, AP2, and TAP. Anthropic does not monetize MCP. Stripe does not monetize ACP (they monetize the Stripe payment rails that ACP uses). Google does not monetize A2A. The protocol is the means to an end, not the end itself.

Implication: Do not build a business whose primary value is protocol compliance. Protocol compliance becomes table stakes. If your pitch is “we support ACP,” that is not a moat. Every Stripe merchant supports ACP.

Application layer: high value capture, high competition

ChatGPT, Gemini, Claude, Perplexity. These are application-layer products that use protocols to deliver value. They capture value through user engagement, subscription revenue, and data network effects. This is where most of the venture capital is flowing, and it is also where competition is fiercest.

Implication: If you are building an agent application (a consumer or enterprise product powered by AI agents), the protocol layer is a dependency, not a differentiator. Your value comes from the application experience, not from which protocols you support.

Infrastructure layer: high value capture, moderate competition

This is where we are. Infrastructure sits between protocols and applications. It provides the concrete capabilities that protocols describe abstractly. MCP defines how an agent calls a “payment tool.” Infrastructure provides the actual payment tool: connected to Pix, Zoop, or Stark Bank, handling NF-e issuance, managing SEFAZ communication, routing between carriers.

Infrastructure value capture is high because infrastructure is hard to replicate. You cannot clone domain expertise. You cannot replicate 400+ API integrations with a protocol specification. You cannot substitute years of understanding SEFAZ rejection codes, Correios API quirks, and Zoop split payment edge cases with a clever abstraction layer.

Implication: If you are building infrastructure, you should be protocol-agnostic. Support whatever protocol wins. Your value is not in the protocol layer; it is in the capabilities you expose through whatever protocol the market selects. This is our strategy, and we think it is the only defensible strategy for an infrastructure company in this space.

Why we bet on MCP

The download trajectory is definitive

100,000 to 97,000,000 monthly downloads in 18 months. That is not hype. That is infrastructure adoption at a pace that has no precedent in the JavaScript ecosystem. For comparison: Express.js, the most popular Node.js web framework, took 8 years to reach 30 million monthly downloads. React took 6 years to reach 50 million. MCP reached 97 million in 18 months.

This trajectory tells us something important: the developer community has decided that MCP is the way to expose tools to agents. That decision is already made. It is not reversible. The switching costs are too high (5,800+ servers would need to be rewritten) and the network effects are too strong (every new server makes the ecosystem more valuable for every agent framework).

The governance structure is right

Anthropic invented MCP. The Linux Foundation now governs it. This is the same path that Docker, Kubernetes, and CNCF projects took. Proprietary origin, open governance. The protocol is community property. This matters because it eliminates the “vendor lock-in” objection that kills many open standards. No one is afraid that Anthropic will rug-pull MCP because Anthropic no longer controls it.

Framework support is universal

Claude, Vercel AI SDK, LangChain, LlamaIndex, CrewAI, AutoGen, Microsoft Copilot Studio, Gemini (partial). This is not a single-vendor protocol. It is the de facto interface between AI frameworks and external tools. When your protocol is supported by every major framework, you stop being a protocol choice and start being assumed infrastructure, like HTTP or JSON.

MCP is protocol-agnostic on commerce

This is the subtle point that most analysis misses. MCP does not compete with ACP, UCP, or any commerce protocol. MCP is the tool interface. An MCP tool can expose an ACP checkout. An MCP tool can expose a UCP catalog. An MCP tool can execute a Pix transfer, a SPEI transfer, or a USDC transfer. The commerce protocol is an implementation detail inside the MCP tool.

This means betting on MCP is not a bet against ACP or UCP. It is a bet that whatever commerce protocol wins will still need to be exposed to agents via a tool interface, and that tool interface is MCP.

Strong opinions: which will win and which will die

We are going to put our predictions in writing. These are informed by our position as infrastructure builders, our conversations with agent developers, and our analysis of adoption data. We could be wrong. But having no opinion is worse than having a wrong opinion, because having no opinion means you are building without a thesis.

CodeSpar's position: infrastructure, not protocol

We support MCP as the native interface. We expose our entire server catalog - 50+ MCP servers covering payments, invoicing, shipping, messaging, and ERP - via MCP tool definitions. Every one of our 400+ tools is callable by any MCP-compatible agent framework: Claude, Vercel AI SDK, LangChain, CrewAI, or custom agents.

We also surface the payment router as an MCP tool, meaning an agent can let the router select between Pix, ACP, USDC, or SEPA based on the recipient, amount, and jurisdiction. If ACP becomes the standard for US merchant checkout, our payment router sends ACP intents to US merchants. If UCP becomes the standard for catalog discovery, our commerce tools consume UCP catalogs. We route to whichever wins.

// The agent doesn't care which protocol the tool uses internally
const session = await codespar.create("commerce-agent", {
  preset: "full-commerce",
});

// This MCP tool call routes to the correct protocol automatically:
// - Brazilian merchant → Pix (BCB rails)
// - US Stripe merchant → ACP intent
// - Shopify merchant → UCP checkout
// - USDC settlement → direct on-chain
await session.send(`
  Pay R$500 to merchant-br-12345    → routes via Pix
  Pay $200 to merchant-us-67890     → routes via ACP/Stripe
  Pay €150 to merchant-eu-54321     → routes via SEPA
`);

// The protocol is an implementation detail.
// The MCP tool interface is the constant.

This means our position on the protocol war is: “we route to whichever wins.” If ACP dominates, our payment router sends more traffic over ACP rails. If UCP dominates, merchants using UCP become reachable via our commerce tools. We are not betting on a protocol. We are betting that whatever protocol wins will still need the tool layer that connects agents to LatAm commercial APIs.

That tool layer does not exist anywhere else. Not because nobody wants to build it, but because building it requires deep domain expertise in LatAm fiscal compliance, payment rails, logistics infrastructure, and messaging platforms. That expertise is not available as an API you can subscribe to. It is accumulated through years of building in the region.

What this means for builders

If you are building in the agent commerce space, here is what we think you should do based on this analysis:

1. Build on MCP. This is not a bet. This is a fact. MCP is the tool interface standard. Build your tools as MCP servers. There is no credible alternative and there will not be one.

2. Watch ACP and UCP, but do not commit to one yet. The commerce protocol layer is unsettled. If you are building a merchant integration, support both. If you are building an agent, consume both. The convergence will happen in 2027. You do not want to be locked in to the loser.

3. Ignore A2A and AP2 for now unless you are building a multi-agent platform. These protocols solve future problems. Unless you are specifically building agent-to-agent coordination, they are not relevant to your 2026 roadmap.

4. Build infrastructure, not protocol wrappers. The value is in the capabilities you expose, not in the protocol you expose them through. If your entire value proposition is “we make it easy to use ACP,” you are building a library, not a business. Libraries get commoditized. Infrastructure does not.

5. If you are building for LatAm, we have already done the protocol analysis for you. Use CodeSpar. Our MCP servers handle the protocol routing. Your agent calls our tools. We handle the rest. That is the entire point of infrastructure.