Enterprise Agent Platform Lock-In: The Four Things That Don't Port

Enterprise agent platform lock-in is usually discussed as a protocol problem, and this month that framing stopped being useful. Google's Agent2Agent protocol moved under the Agentic AI Foundation on 17 August, joining Anthropic's Model Context Protocol in a vendor-neutral home whose membership has gone from fewer than 40 to more than 250 since December 2025. In the same stretch, an architecture review of the three hyperscaler agent platforms found that AWS, Microsoft and Google have independently converged on the same seven-piece stack.

Read those two events together and the obvious conclusion is that portability is arriving. I think the opposite is closer to true. The industry standardized the two layers that were never the lock-in, and left the one that is.

What did AWS, Microsoft and Google actually converge on?

The convergence is real and it is specific. Each platform now ships the same building blocks under different names.

AWS Bedrock AgentCore, generally available since October 2025, is seven composable services: runtime, gateway, memory, browser, code interpreter, identity and observability, with isolated sessions that run up to eight hours. Microsoft Foundry, renamed from Azure AI Foundry in January 2026, mirrors it almost piece for piece with a session-isolated managed runtime, Entra Agent ID for agent identity, scoped managed memory and OpenTelemetry tracing. Google folded Vertex AI into the Gemini Enterprise Agent Platform and shipped Deployments, Memory Bank, Sessions, Agent Registry, Policies and Gateways.

Three vendors, three product vocabularies, one architecture: a session-isolated managed runtime, a gateway for tool access, scoped managed memory, an agent identity, and OpenTelemetry observability.

The comparison that gets made is Cloud Foundry, and it is apt in a way that should worry platform owners. Cloud Foundry's promise was "push your code and the platform handles the rest." The agent equivalent has arrived without the part that made that promise safe to accept, which was a portable lifecycle contract. There is no cf push for an agent that means the same thing on two clouds.

If the protocols went neutral, where is the enterprise agent platform lock-in?

This is the question the A2A news obscures rather than answers, and it is where enterprise agent platform lock-in actually lives now.

MCP standardizes how an agent reaches a tool. A2A standardizes how an agent reaches another agent. OpenTelemetry standardizes how the agent's behavior is reported. All three are genuine, all three are now governed neutrally, and all three describe the agent's outward reach.

None of them describes the agent. Nothing in that stack specifies how an agent is declared, versioned, promoted, given a principal, granted memory, allocated a session, or retired. Those are lifecycle concerns, they are where every hyperscaler has made a different set of design decisions, and they are the concerns a platform team actually owns.

So the state of play is this: your agent's integrations are portable, and your agent is not.

That is not an accident of timing. Interface standards are cheap for a platform vendor to support, because they increase the number of things a customer can plug into the platform. Lifecycle standards are expensive, because they increase the number of platforms a customer can leave for. Vendors ship the first kind early and the second kind late, and they have done it in every infrastructure cycle since the JVM.

What are the Four Unportables?

Here is the framework I use when a client asks how exposed they are. Four lifecycle primitives, none of them standardized, ranked by how hard they are to unwind.

1. Registry. How an agent is declared, versioned and promoted from dev to production. Google ships an Agent Registry; AWS handles it through AgentCore Runtime; Microsoft through Foundry Agent Service. The deployment spec you write is the platform's spec, and it is usually the first artifact a team builds tooling around. This is the shallowest hook and the easiest to abstract, which is why it is worth abstracting first.

2. Session. The unit of isolated execution and how long it may live. All three vendors use the word "session" and none of them means quite the same thing by it. AWS documents eight-hour isolated sessions. Your concurrency model, your timeout handling and your retry semantics get written against whichever contract you started on, and those assumptions are invisible until they break somewhere else.

3. Memory. AgentCore Memory, Foundry's scoped managed memory, Google's Memory Bank. You can almost always export the contents. What does not export is the scoping semantics: what the platform decides an agent is allowed to recall, across which sessions, for how long, and under whose authority. Two platforms can hold identical memory rows and produce different agent behavior, and there is no format that captures the difference.

4. Identity. Entra Agent ID, AgentCore Identity, Google's Policies layer. The agent's principal is issued by the platform, and every authorization rule, every audit trail and every least-privilege decision you make is written against that principal. This is the deepest hook by a wide margin, because moving it means rewriting your authorization model, not your deployment scripts.

Call it the Four Unportables: Registry, Session, Memory, Identity. The protocol layer above them went neutral this month. This layer did not, and there is no working group announcement pending that says it will.

What is the Redeploy Test?

One question, before any vendor conversation.

The Redeploy Test: take your most valuable production agent and name what survives a redeploy onto a different cloud's agent platform, unchanged. If the honest answer is the prompt and the tool definitions, you are portable in exactly the two layers that were never the risk.

The test is useful because it is answerable in an afternoon and because it produces a number rather than a posture. Most teams I run it with find that roughly the reasoning layer moves and none of the operational layer does. That is not a failure. It is a map of where the actual switching cost sits, and it is very rarely where the architecture diagram suggests.

It also reframes the vendor conversation. Info-Tech Research Group's enterprise agentic stack breaks the problem into six layers and proposes six evaluation criteria, and the one worth pressing hardest is deployment compatibility and flexibility. Ask a vendor to demonstrate the Redeploy Test rather than describe their commitment to open standards. Every one of them supports MCP. That tells you nothing about the four things above.

What I'd actually do

I work with Fortune-level enterprise clients architecting and building agentic frameworks, and the sequence below has held up across several of these evaluations.

Run the Redeploy Test on one agent this week, in writing, and circulate the answer. It costs an afternoon and it is the only artifact in this space that survives contact with a procurement conversation.

Then abstract in order of reversibility, not in order of difficulty. Registry first: keep your agent definitions in your own repository in your own format and generate the platform spec from it, so the platform manifest is an output rather than a source. Memory second: own the store, or at minimum own an export path that captures scoping rules and not just rows. Identity last, and deliberately, because the correct move there is usually not to abstract it but to keep the blast radius of it small and documented.

Do not confuse protocol adoption with portability. Supporting MCP and A2A is now table stakes and costs a vendor almost nothing. It is a reason to shortlist a platform. It is not evidence that you can leave one.

And be honest about the timing. Roughly 99% of companies plan to put agents into production and somewhere between 9% and 14% have actually done so. Most enterprises are making this decision now, at the exact moment when the cost of getting it wrong is a rewrite rather than a migration. That window is the whole opportunity, and it closes quietly.

---

Primary source: Amazon, Microsoft, and Google Are Converging on the Same Enterprise Agent Architecture, The New Stack, August 2026. A2A governance move reported by Axios, 17 August 2026; stack layering from Info-Tech Research Group; production-rate figures from Ness Digital Engineering.

More on this: the multi-agent orchestration architecture pillar, managed agent runtime vs self-hosted, and agent control plane portability.

Get the next one. I write one piece a week on the orchestration, decisioning and governance that make enterprise agents safe to ship. Subscribe at buildnextgen.ai.

---

Swipe the framework