The Agent Protocol Land Grab: Why Interop Standards Are the New Platform War

Every vendor selling an agent platform right now is telling enterprise buyers the same reassuring story: the protocol layer is settled, it is open, it is boring plumbing, and the interesting decisions are all further up the stack. That story is a strategy. The protocol layer between agents and enterprise systems is the least boring layer in the entire agent stack, because it is the only one that determines who gets to reach the customer's data and who has to ask permission. Whoever owns that layer owns the distribution chokepoint of the agent era, and the companies publishing "open" agent standards understand this considerably better than the companies adopting them.

The thesis is straightforward and uncomfortable. Model Context Protocol, Agent2Agent, and the vendor-proprietary function-calling schemes that predate both are not interchangeable transport formats that will eventually converge into a boring commodity. They are competing bids to become the TCP/IP of agents, submitted by parties with sharply different economic interests in what the winning protocol does and does not make easy. Openness in this context is not generosity. It is the standard opening move of a firm that wants to commoditize the layer above or below the one it actually monetizes, and it works precisely because the buyer experiences it as a gift.

The Land Being Grabbed Is Not the Wire Format

Executives evaluating agent protocols tend to read the specifications, conclude the differences are syntactic, and delegate the decision to an architect. That is the wrong altitude. The wire format genuinely is close to a commodity: JSON over a streaming transport, a schema for describing callable capabilities, a session model. Any competent team could implement three of these in a quarter, and the ones that exist are not meaningfully differentiated on expressiveness.

The contested territory is everything the wire format drags behind it. A protocol standardizes four things beyond message syntax, and each one is a position in a different market.

The first is capability description: how a tool, a database, or an internal service advertises what it can do in a form an agent can reason about. Whoever defines that vocabulary shapes what agents find easy to use, and what agents find easy to use is what enterprises end up building.

The second is discovery and registry: how an agent finds out what exists. A registry is a directory, and a directory is a distribution channel. The history of app stores and package managers says the same thing about who captures value in a directory, and it is not the listings.

The third is identity and authorization: how an agent proves it is allowed to act, on whose behalf, within what scope. This is the layer where switching costs actually calcify, because auth infrastructure is the part of an integration that security, legal, and audit have all signed off on, and re-signing off is expensive in a way that rewriting a client library is not.

The fourth is trust and provenance: how a receiving system decides whether an inbound agent request is legitimate, and what audit trail survives it. This barely exists in any current specification, which is itself the most useful signal about how early the market is.

None of these four is a transport concern. All four are governance concerns, which is why treating protocol selection as an architecture decision rather than a strategy decision is the characteristic executive error of this cycle. The technical framing of what MCP is and where it fits is covered separately in the enterprise breakdown of Model Context Protocol; the argument here is about who benefits from which version of the standard winning.