The Agent Protocol Stack Is a Mess and Here Is Where the Lock In Hides

A team we know spent three weeks wiring their agent stack to MCP. The week they finished, their investor forwarded them an A2A announcement and asked a question nobody in the room could answer cleanly: which of these do we actually need and which of these are we going to rip out in six months?

They are not alone. Every team with an AI product in production right now is staring at the same stack of acronyms and trying to figure out which piece is infrastructure and which piece is a fad. The honest answer is most of them are neither. They are competing bets on which layer of the agent stack is going to become the default, and right now the only thing everyone agrees on is that nobody agrees.

That noise is a stack forming. And the question that matters is not which protocol wins. It is which layer you choose badly, because that is where the real lock in lives.

The stack in plain language

Forget the spec documents and the blog wars. The agent protocol stack right now is three layers that do three jobs.

The bottom layer is transport. How do two machines talk to each other. This is old ground. HTTP. WebSockets. gRPC. None of this is new and none of this is where the lock in risk sits. You can swap transport later if you need to. The ecosystem is mature and nobody is going to own your transport choices.

The middle layer is tool protocol. How does a model call a tool. This is where MCP lives and MCP is winning this layer the way HTTP won the transport layer, not because it is perfect but because it is early enough and good enough and the network effect has already started. When Anthropic shipped it as open, the rest of the industry had two choices: adopt it or explain why your thing is different enough to justify the fragmentation. Most teams chose adoption. If you are building an agent that needs to call tools, you are almost certainly building on MCP or you are about to be.

The top layer is agent to agent. How do two agents negotiate a task when neither one controls the other. This is where it gets messy and where the real lock in risk lives. A2A is Google's play. ACP is another. There are others, each with their own governance model, their own assumption about what an agent is, and their own answer to the question nobody has standardized yet: when two agents talk, who owns the task that results.

The confusion is about the top layer

The reason everyone is confused right now is that the bottom two layers are already settling and the top layer is wide open. People mix them up. They argue about MCP when they mean agent to agent. They treat transport choices as strategic when they are not. The debate is really only about one thing and it is the thing nobody has a clean answer to yet.

Here is the honest landscape of where things stand. MCP is the tool protocol. Most teams are building on it. A2A and the others are competing for the agent to agent slot. HTTP and gRPC handle the transport underneath. The confusion happens because people try to evaluate the stack as one decision when it is three, and the risk profile of each one is completely different.

The bottom layer has no lock in risk. The middle layer has moderate lock in risk and MCP is the leading candidate. The top layer has real lock in risk and no winner yet.

That is the map. The rest is noise.

Where the lock in actually sits

Here is the part nobody wants to hear. The biggest lock in risk in the agent protocol stack is not in any protocol. It is in the thing that makes the stack coherent in the first place. Your orchestration.

When you build an agent, you are not just picking protocols. You are writing the logic that decides when the agent calls a tool, how it hands work to another agent, what happens when one of those calls fails, and how it recovers. That logic is your real investment. The protocols are just the wires.

The lock in happens when your orchestration logic is written as if the protocols will never change. When every tool call assumes MCP will always be there. When every agent to agent interaction assumes a specific handshake that one vendor defined. The protocol is replaceable. The orchestration is not, unless you wrote it to be swappable, and most teams did not because that was a future problem and future problems are easy to defer.

This is the root cause of almost every infrastructure lock in story. It is never the protocol itself. It is the depth of assumption you wrote into the code that uses the protocol. The deeper the assumption, the harder the swap. The protocol is the surface. The assumption is the lock.

What a small team should actually do

The practical version of this, the version that works for a team building agents right now with a real product and a real deadline, is simpler than the discourse suggests.

One. Adopt MCP for tool calls and stop debating it. The network effect has started. The cost of being wrong about MCP adoption is low because the ecosystem is building around it. The cost of not adopting it is high because every tool provider is shipping MCP servers. If you are not on MCP already, you will be within the quarter.

Two. Write your orchestration so it does not care which protocol the next layer uses. This is the one that saves you later. Your agent to agent logic should be behind an interface that does not assume a specific protocol underneath. That way when A2A or ACP or whatever comes next becomes the standard, you swap the implementation, not the architecture. The discipline is simple: never import the protocol into your business logic. Wrap it instead.

Three. Do not bet on agent to agent yet. Use whatever works for your specific case, keep it isolated, and watch. The layer is still forming and committing early means committing to someone else's assumptions about what agent coordination looks like. The teams that win this one are the ones that ship now and stay loose, not the ones that commit to a protocol before the use cases have stabilized.

Four. Document every protocol dependency. Not in a wiki nobody reads. In the code, one line per dependency, what it does, what would break if it disappeared. When the replacement comes, and it will come, you will know exactly what to swap. This is not documentation theater. It is the difference between a two hour migration and a two week fire drill.

The real moat is not the protocol

There is a strange comfort in believing the protocol is the strategy. It gives you something concrete to argue about. But the teams that are going to win the agent era are not the ones that picked the right protocol. They are the ones that built agents that understand the problem deeply enough to survive protocol changes.

When intelligence is a commodity and protocols are a commodity, the moat moves to understanding. Understanding what the agent is for, understanding what the user actually needs, understanding where the failure modes are before they happen. That is the same place the moat has always been. The protocol stack just made it more obvious by giving every team the same building blocks and daring them to do something different with them.

The agent protocol land grab is real. The stakes are real. But the thing that will make your agent survive is not which protocol you chose last month. It is whether you understand the problem well enough to keep the agent working when the next protocol shows up and makes the last one look outdated.

That has always been the test. The stack just changed. The test did not.

Try it on your own tree

Open the code that runs your agent. Search for every place a protocol name appears in your orchestration logic. Not the transport layer, not the tool layer, the layer that decides what your agent does next. If you find direct imports, hard coded handshakes, or assumptions about what another agent will return, that is your lock in. Not today. But in three months, when the standard at the top layer settles and you need to move.

The fix is not to rewrite. It is to wrap. Put an interface between your logic and the protocol. One afternoon of work now saves a week later. That is the kind of trade that keeps a small team moving without inheriting someone else's assumptions about how agents should talk.

If you would rather hand us the tree and let us find the assumptions you missed, that works too. Mapping the real dependencies is our daily work.

Related reading: Vibe Coding Debt Is the New Technical Debt covers why untraced code becomes unowned code. Your AI Feature Is a Symptom looks at why AI belongs downstream of understanding.