The uncomfortable truth: converged platforms, trapped agents
Enterprise AI agents are production-grade, model-driven software actors that use tools, memory, identity, and governance layers to act on behalf of users across business systems, yet they remain tightly bound to each cloud’s operational stack despite providers now offering nearly identical platform architectures. Over the past nine months, Amazon, Microsoft, and Google have each introduced or renamed an enterprise agent platform, and all three have converged on the same core architecture, with runtime, memory, tool gateway, identity, observability, and governance appearing in Bedrock AgentCore, Microsoft Foundry, and the Gemini Enterprise Agent Platform respectively. This should be good news for cloud platform interoperability and multi-cloud strategy: common primitives, shared concepts, and an emerging blueprint for enterprise AI agents. In practice, however, the convergence highlights a paradox. The platforms look the same, but enterprises still cannot pick up an agent from one provider and run it on another without reassembling almost everything around it.
What happened: the rise of the enterprise agent stack
The agent platform story is now clear: the big three clouds have turned scattered components into a defined layer. AgentCore reached general availability with seven composable services—runtime, gateway, memory, browser, code interpreter, identity, and observability—explicitly marketed as the foundation for enterprise AI agents. Microsoft renamed Azure AI Foundry to Microsoft Foundry, with Foundry Agent Service providing a managed runtime, Entra-backed agent identity, scoped memory, and OpenTelemetry-based tracing. Google folded its previous offerings into the Gemini Enterprise Agent Platform, where Deployments sit alongside Memory Bank, Sessions, Agent Registry, Policies, and Gateways under an agent-first information architecture. AWS, meanwhile, recently released Loom, an open-source, opinionated agent platform that shows how organizations can build, deploy, and govern AI agents on AWS with security controls baked in from the start. Together, these moves confirm that enterprise AI agents are no longer experiments; they are a first-class workload type that every provider wants to anchor inside its own ecosystem.
AWS Loom: governance-first design that still locks you in
AWS Loom is the clearest signal of how vendors imagine AI agent governance—and why that imagination still reinforces lock-in. Loom packages a unified management UI and backend API with identity provider integration, scope-based authorization, and lifecycle management for agents, memory resources, MCP servers, and agent-to-agent integrations. Administrators land on a catalog dashboard; end users see only a chat interface, agents in their own group, and their own conversation history. Governance runs through tag profiles that enforce mandatory tags like application, group, and owner on every deployed resource, plus optional tags such as cost center identifiers. Identity propagation is handled with a full authorization code flow and the RFC 8693 token exchange process supported by AgentCore Identity, so both end-user and agent identities travel through downstream access tokens while delegation stays intact. Human-in-the-loop review ensures sensitive tool calls pause for approval before execution. This is thoughtful AI agent governance—but every piece assumes AWS runtimes, AWS identity, and AWS observability. The design solves internal control problems while deepening dependency on one cloud.
Why architectural parity still does not equal portability
Despite architectural parity, cloud platform interoperability remains mostly aspirational. The same primitives exist everywhere—runtime, memory, tool gateways, identity, observability—but they terminate inside one provider’s stack. A typical enterprise AI agent uses a managed session store, a long-term memory service, a tool gateway wired to that provider’s APIs, an agent identity derived from its directory, and telemetry pushed into the provider’s logging service. Each choice appears harmless; together, they decide which cloud the workload lives in. Moving that agent a year later means rebuilding the whole assembly, recreating identity flows, memory layouts, tool definitions, and traces—exactly the state enterprises were in before platform as a service gave applications a portable shape. According to one analysis, "Identity, telemetry, and deployment all terminate within a single provider, which makes the operational layer beneath the agent the part that resists moving". The missing ingredient is a shared "agent contract" that defines how an agent declares its needs independent of where it runs.
Fragmented standards, and what enterprises should demand next
There are signals that an interoperable future is possible, but they remain scattered. Loom’s use of the RFC 8693 token exchange process shows that standards can carry both user and agent identities through delegated chains without losing context. Most of the primitives a neutral platform would need—identity flows, tool gateways, memory abstractions, OpenTelemetry traces—already exist. What does not exist is a PaaS-style contract for agents, the equivalent of what buildpacks and service brokers gave applications when developers stopped thinking about machines and started thinking about apps. Until there is a portable description of an enterprise AI agent—its tools, memory, identity model, and policies—that can be run on multiple clouds, multi-cloud strategy will remain marketing language rather than operational reality. Enterprises should stop accepting "agent platforms" that strengthen vendor lock-in and start asking a harder question: can the same agent artifact run on two different clouds without a rewrite? Until the answer is yes, architectural convergence is a trap dressed up as progress.
