There is a comfortable lie that gets repeated whenever someone asks which of the big three managed LLM platforms to standardize on: they're all the same, so just use whichever cloud you already pay for. It's comfortable because it's half true, and it's a lie because the half that's false is the half that will cost you a re-platforming project in eighteen months.

The half that's true is the models. In 2026, model breadth has stopped being a differentiator. Claude runs on all three. So do Llama and Mistral. The interesting question was never which models can I rent — it's what gets wrapped around them, and what happens when you try to leave.

AWS Bedrock: bring your own framework

Bedrock's pitch is the widest pure-play model rental counter: 100-plus foundation models from 15-plus providers, Amazon's own Nova 2 family, plus a marketplace that roughly doubles the count. But the part that matters for agents is AgentCore, and AgentCore's defining choice is what it doesn't do.

It doesn't make you adopt an agent framework. AgentCore Runtime is a serverless host — session isolation, SigV4 and OAuth auth, bidirectional streaming, managed memory, CloudWatch observability — and it will run an agent you built in Strands, LangGraph, or CrewAI without rewriting your orchestration logic. Through 2026 it added stateful MCP server support (elicitation, sampling, progress notifications), AG-UI for real-time front ends, Node.js deployment, and Step Functions integration so agent reasoning steps can sit inside production workflows with human-approval gates.

The catch: AgentCore is a host, not a guide. If you don't already have an agent framework and an opinion, you'll spend your first week assembling one. The platform hands you primitives and assumes you know the shape of what you're building.

Bedrock's strength and its weakness are the same fact: it has no opinion about how you build an agent.

Vertex AI: the open-protocol bet

Google spent Cloud Next 2026 rebranding Vertex AI into the Gemini Enterprise Agent Platform, but the bones are unchanged and they're good. The native model is Gemini; the Model Garden carries 200-plus, Claude included. The agent story is two pieces: the Agent Development Kit (ADK) — open-source, now stable across Python, Go, Java, and TypeScript — and Agent Engine, the managed runtime that handles scaling, sessions, and a memory bank that reached GA this year.

The non-obvious thing Google did right was bet on protocols it doesn't own. ADK speaks MCP for tool access, and Google authored A2A, the Agent2Agent protocol for inter-agent communication, then handed it to 50-plus partners. The division of labor is clean: MCP standardizes agent-to-tool calls, A2A standardizes agent-to-agent calls. An A2A agent doesn't care whether the agent on the other end was built in ADK, LangGraph, or CrewAI.

The catch: the smooth path runs through Gemini and ADK. You can bring Claude and other frameworks, but the runtime, the observability dashboard, and the deployment ergonomics are tuned for Google's own kit. The protocol openness is real; the gravitational pull toward Gemini is also real.

Azure AI Foundry: the identity moat

Microsoft renamed Azure AI Foundry to simply Foundry, and its catalog is the largest of the three by an order of magnitude — models sold directly by Azure (the Azure OpenAI GPT-5.4 line, plus Grok, Llama, Mistral, DeepSeek) sitting on top of an open catalog that runs into the thousands. The Foundry Agent Service went GA on a runtime built around the Responses API, with MCP support (including OAuth passthrough), multi-agent workflows, and hosted agents across new regions.

But Foundry's actual moat isn't the catalog. It's that agents get an Entra Agent ID — a first-class identity in Microsoft's directory — and plug natively into Teams, Office, and the governance plane your security team already audits. For a regulated enterprise that lives in Microsoft 365, that's not a feature, it's the whole argument.

The catch: the value is inseparable from being a Microsoft shop. Outside that ecosystem, you're paying for integration depth you can't use.

What actually locks you in

Here's the part the "just use your existing cloud" advice misses. The model isn't the lock-in — Claude is portable by definition, since it's the same Messages API on all three with only the endpoint and model-ID format changing. The lock-in is the orchestration and governance layer you build on top.

Bedrock's Automated Reasoning checks — formal-logic verification of model outputs, the only guardrail of its kind — are genuinely differentiated, and a compliance argument built on them doesn't move to another cloud. Foundry's Entra-bound agent identities are, by design, not going anywhere. That is where the eighteen-month re-platforming project comes from — not the weights, the wiring.

If you'd rather not rent the wiring at all, the alternative is assembling it yourself: serverless inference APIs for raw token throughput, or self-hosted serving engines when you want the model on your own metal. The managed platforms are worth it precisely because the runtime, memory, and governance are the hard parts — but that's also exactly why they're the parts that bind you.

How to actually choose

The honest version of the cliché is this: pick the cloud holding your data, then look hard at the agent runtime before you write orchestration you can't carry out the door. The models are a commodity. The runtime is the marriage.