Amazon, Microsoft, and Google Are Building the Same Thing: The Enterprise AI Agent Lock-In Trap

Look closely at what AWS, Microsoft, and Google shipped for AI agents this year and you notice something odd. Different names, different branding, and underneath, the exact same product.

That convergence is convenient right up until you try to leave. Here's what they're all building and why it should make you a little cautious.

What all three are actually building

Strip away the marketing and the three big clouds are assembling the same five-part stack for running enterprise AI agents:

• a managed runtime to execute the agent
• memory so it remembers context
• identity so it can authenticate and be governed
• tools so it can call your systems
• observability so you can see what it did

The products are AWS Bedrock AgentCore, Microsoft's Azure AI Foundry with its Agent365 control plane, and Google's Vertex AI agent stack. They look different on the pricing page. Architecturally, they're the same idea built three times.

This isn't a coincidence. When you're solving the same problem-running agents safely inside an enterprise-you land on the same pieces. The market basically agreed on the shape of an agent platform in early 2026, and each hyperscaler raced to own it on their own cloud.

Why the convergence feels great at first

If your data and identity already live in one cloud, that cloud's agent runtime is the fastest path to production. Your storage is there, your identity system is there, your logging is there. The platform snaps into all of it. You get governance, audit trails, and deployment almost for free.

For a team that just wants agents running with proper controls, that's a real gift. I get the appeal.

The catch nobody puts on the slide

Here's the trap. When your agent's runtime, credentials, state, and telemetry all live inside one cloud, moving it somewhere else isn't a config change. It's a rebuild.

Take AWS Bedrock AgentCore. An agent built on it is wired to AWS identity, networking, and storage. Picking it up and moving it to Azure or Google isn't a matter of swapping a few integrations, because the IAM bindings, the VPC setup, and the storage hooks are all AWS-specific. You don't move the agent. You rewrite it.

That's the difference between switching APIs and switching clouds. Rewriting a few integrations is annoying. Re-implementing identity, state, and telemetry on a new platform is a project.

But don't the open protocols fix this?

Partly, and it's worth being precise here. Open standards like MCP, which connects agents to tools, and agent-to-agent protocols do standardize how agents talk to things. That's real progress.

But talking is not the whole problem. Portability has three axes:

1. the framework your agent uses
2. the model it runs on
3. the cloud it lives in

Open protocols mostly help the first two. They don't move your deployment, your identity setup, or your stored state to another cloud. Fail on any one of those axes and you've just traded one kind of lock-in for another.

What cloud-agnostic actually takes

Real portability means being deliberate on all three axes from the start, not bolting it on later.

• Keep the agent logic in a framework you control rather than the cloud's proprietary primitives, so the brain of the agent isn't welded to one vendor.
• Keep the model swappable behind an abstraction, since prices and quality shift monthly.
• Keep a control plane above the clouds-an agent gateway or management layer that governs, observes, and audits agents no matter which cloud or framework produced them.

The good news is this layer is emerging. Governance tools like Microsoft Purview, Databricks Unity Catalog, and Google's Agent Governance Framework are starting to give you audit trails and data lineage across agents. The catch is that using one cloud's governance tool can quietly pull you back into that cloud. Neutral is the goal.

What I'd do about it

You don't have to avoid the hyperscaler platforms. They're genuinely good, and for a single-cloud shop the lock-in may be a price worth paying for speed. Just make it a decision, not an accident.

Before you build on one, ask the boring questions:

• If we had to move this agent to another cloud in a year, what breaks?
• Where does its state live?
• Who owns its identity?

If the honest answer is "everything breaks," you're choosing lock-in, and that's fine as long as you chose it on purpose.

The bottom line

Amazon, Microsoft, and Google are building the same enterprise agent platform, and each one is easiest to adopt inside its own cloud and hardest to leave. Open protocols standardize how agents communicate, but they don't make your deployment portable.

If moving clouds later matters to you, keep your agent logic, your model, and your control plane vendor-neutral from day one.

Convenience now, or freedom later. Just make sure you know which one you picked.