Judge the standards bet by what it costs to be wrong

"MCP has won." You have heard some version of this — the Model Context Protocol has become the way AI agents talk to tools, the vendors have lined up, the question is settled. Standardise now.

That is roughly right for the tool layer, and increasingly right elsewhere too. Which is exactly why you should be careful, because "the winner is obvious" is the most expensive moment to stop thinking about what happens if you're wrong.

What has consolidated — faster than the sceptics expected

There are two layers here. At the layer where an agent talks to tools and data, MCP has reached de facto standard status: multi-vendor foundation governance, and the major model providers shipping support for it.

At the layer where agents talk to each other — historically the more fragmented one — consolidation has moved fast. A2A, one of the leading agent-to-agent protocols, is now hosted by the Linux Foundation, at a production-ready 1.0, with 150-plus participating organisations and integration into the major cloud AI platforms. A year ago you could fairly call this layer a scrum of competing specs. In mid-2026 that is no longer defensible; it is consolidating, even if more than one protocol still coexists.

So the market is not fragmented-and-stuck. It is converging. And a converging standards market is precisely where the timing bet gets interesting — because the cost of joining late, and the cost of backing a loser, both change as it tips.

What sets the cost of being wrong

Here the useful literature isn't about AI at all. It is the economics of standards, and it is unusually clear on the mechanism.

Two forces determine what a wrong standards bet costs you: switching costs and network effects. They bind you to an installed base and can hand the winning vendor durable pricing power after the fact. The same literature makes an uncomfortable observation — firms probably choose incompatibility more often than is socially efficient, because fragmenting a market can be individually rational for the fragmenter (though the theory cuts both ways, and some models predict the opposite bias). Either way, don't read the existence of competing protocols as proof the question is wide open.

The size of that penalty, though, is not fixed.

Switching cost is partly a design choice

The most useful idea for a decision-maker is that switching cost is architecture-dependent, not a property of the market you must simply accept.

The economics argues that converters, adapters and mix-and-match compatibility can, in principle, reduce lock-in — and the contrast between ecosystems bears it out: operating-system ecosystems tended to produce high switching costs and durable lock-in, while internet platforms that were easy to multi-home could show weaker lock-in even with real network effects. This is a tendency, not a law — the same economists are careful that the evidence on the strength of these effects is thin.

And there is a catch the optimistic version omits: a determined sponsor can defeat your converter. The standards literature is explicit that if a vendor can block a one-way adapter — through intellectual property, or by quietly and frequently changing the interface — your carefully preserved optionality evaporates. Designing for reversibility helps; it does not make you immune.

Translated into your architecture: put the protocol behind an interface you own, keep the agent's business logic independent of the transport, and don't let a spec's assumptions leak into your data model. This is the same discipline that made database portability possible — worth doing, and not a guarantee.

But waiting isn't free either

The honest complication — and this tension is live inside the same literature, not something I can resolve for you — is that delay has its own compounding cost.

Markets with network effects tip. Once tipping begins, the influence you might have had over which standard wins, and whether it accommodates your requirements, fades. Waiting preserves option value and spends influence; early commitment does the reverse. There is no general answer, and anyone offering you one is selling something.

One caution on the folklore: the canonical lock-in horror stories are disputed within economics — how large the penalty of backing a "wrong" standard really is remains contested, so don't assume it is catastrophic by genre convention. Equally, don't assume it's trivial: serious economists conclude network effects can be powerful even when they're easy to sneer at.

The decision

So don't ask which protocol will win — the tool layer is largely settled on MCP, the agent-to-agent layer is consolidating but not closed.

Ask instead: if we are wrong about this in eighteen months, what does it cost us to change our minds? If the answer is "an adapter and a fortnight," commit now and take the influence that comes with being early. If the answer is "a rewrite," you have not been given a protocol decision. You have been given an architecture problem, and you should fix that first.

The bet you can afford to lose is the one worth making early.