Amazon, Microsoft, and Google are converging on the same enterprise agent architecture

There's a pattern playing out right now that anyone who lived through the early cloud wars will recognize immediately. Amazon's Bedrock AgentCore, Microsoft's newly renamed Foundry, and Google's Gemini Enterprise Agent Platform look like three competing products on the surface. Underneath, they're the same thing wearing different logos: a runtime, a memory layer, a tool gateway, an identity system, observability, and governance. Eighteen months ago this was a scattered pile of libraries. Now it's hardening into a platform layer, and all three hyperscalers got there independently within the same nine-month window.

This is basically the Cloud Foundry moment again, minus the part where an open contract shows up to save everyone. Between 2011 and 2016, Cloud Foundry and Heroku took the mess of VMs, load balancers, and message queues and wrapped it in a single application contract, so developers could ship code without caring where it ran. AWS's AgentCore, which hit general availability in October 2025 with seven services including an eight-hour execution runtime and OpenTelemetry-based tracing, is doing something similar — but only inside AWS. Same story with Microsoft's Foundry Agent Service and its Entra Agent ID for identity, and with Google's newly rebranded Gemini Enterprise Agent Platform, which folded Vertex AI's Agent Engine into something called Deployments. Each one solves the plumbing problem. Each one solves it for exactly one cloud.

The trap is subtle because no single decision feels like lock-in. A team picks a model, a framework, a memory store, a tool gateway, an identity layer — each choice reasonable on its own. But session state ends up in one provider's managed store, traces land in that provider's telemetry service, and the agent's identity is minted by that provider's directory. Try moving that agent a year later and you're rebuilding the whole stack, which is precisely the pre-PaaS pain enterprises thought they'd escaped a decade ago.

What's missing is the buildpack-and-service-broker equivalent for agents — a shared contract for packaging an agent as one portable artifact, binding it to a model or memory provider the way Twelve-Factor apps bind to a database, and treating evaluation, cost, and quality regression as first-class operational signals rather than an afterthought. The raw materials exist already: MCP for tool access, A2A for agent-to-agent communication, OpenTelemetry's emerging GenAI conventions for tracing. The Linux Foundation even stood up an Agentic AI Foundation in December 2025, with AWS, Google, and Microsoft signing on as platinum members and Anthropic, Block, and OpenAI contributing founding projects. But a protocol for how agents talk to tools says nothing about how you version an agent, roll it back after a bad eval, or export its memory to a different cloud.

So the real fight isn't happening in the marketing decks about agent capabilities. It's happening one layer down, in who controls the lifecycle contract nobody's written yet. Kubernetes didn't just win adoption — it defined what a deployment even means for an entire industry. Whoever fixes that same definition for agents decides what a platform team is allowed to swap out later, and right now that's shaping up to be three separate answers from three separate hyperscalers, each one conveniently incompatible with the other two.