The paradox of identical agent platforms that cannot move
Enterprise AI agents are production-ready software entities that run on cloud platforms, combine models, tools, memory, and identity, and are governed through shared runtime, observability, and access-control services so organizations can safely automate real work at scale.
Over the past nine months, Amazon, Microsoft, and Google have each launched or renamed enterprise agent platforms built from the same set of parts: runtime, memory, tool gateway, identity, observability, and governance. On paper, this looks like the beginnings of agent architecture standards and a path to multi-cloud AI deployment. In practice, these near-identical stacks still cannot talk to each other, and moving an agent means rebuilding almost everything around it. The result is a new form of cloud provider lock-in that hides behind reassuringly similar diagrams. The industry has recreated the pre–platform-as-a-service world for agents, only this time with models and orchestration flows instead of virtual machines and load balancers.
How convergence happened—and why it did not fix lock-in
Amazon’s Bedrock AgentCore, Microsoft Foundry, and Google’s Gemini Enterprise Agent Platform now expose matching primitives for building enterprise AI agents: session-isolated runtimes, managed memory, gateways to tools, identity, and OpenTelemetry-powered observability. AgentCore alone ships seven composable services—runtime, gateway, memory, browser, code interpreter, identity, and observability—positioned as the default foundation for production agents.
This convergence is not a plot; it is a margin strategy. Infrastructure vendors know that integration is where value and differentiation live, so they integrate everything from identity to telemetry to deployment in their own stacks. The catch is that identity, logging, and deployment pipelines all terminate in one provider, which means the operational layer under the agent resists moving elsewhere. According to one analysis, “moving that agent a year later means rebuilding the whole assembly,” a regression to pre-PaaS fragmentation where every component quietly dictates which cloud you must stay in.
Loom shows the governance layer—and the limits of portability
AWS recently released Loom, an open-source, opinionated platform that demonstrates how to build, deploy, and govern AI agents on AWS with security controls built in from the outset. Loom packages a management UI and backend API with identity provider integration, lifecycle management, and strict governance for agents, memory, Model Context Protocol servers, and agent-to-agent (A2A) integrations. It emerged from a prototype by Heeki Park before graduating into an AWS Labs project.
Loom’s governance stance is explicit. Tag profiles enforce three mandatory tags—loom:application, loom:group, and loom:owner—on every deployed resource, with optional custom tags like cost centers. Access control mixes role type with group tags so administrators see catalogs while end users see only a chat interface, their own groups’ agents, and their conversation history. Agents must pass a review process before publication to production. Loom itself is free and open source; the cost lives in the managed services underneath it. It is a reference for how to govern agents inside AWS—not yet a portable contract for moving those governed agents to another cloud.
Token exchange, MCP, and the missing contract for multi-cloud AI
Loom also shows how hard identity propagation is, and why standards matter. When an agent acts for a user, calls an MCP server, and that server calls a REST API, every hop needs a token that preserves the original user’s permissions. Loom implements a full authorization code flow and uses the RFC 8693 token exchange supported by AgentCore Identity so both user and agent identities travel in downstream tokens while the delegation chain stays intact. Each hop—from agent to MCP server to API Gateway endpoint—gets its own on-behalf-of token, keeping downstream access limited to what the originating user can see.
Most of the primitives a neutral, vendor-independent platform would need now exist: the Model Context Protocol standardizes how agents call tools and data, and A2A covers discovery and communication between independent agents. But protocols are not the same as a lifecycle platform. Until someone defines an agent portability contract—covering runtime expectations, memory semantics, governance hooks, and identity flows across clouds—multi-cloud AI deployment remains aspirational. Enterprises doing diligence on agent platforms today are still pushed to answer whether they accept that identity, telemetry, and deployment will be bound to one provider, and what hidden cost of lock-in they are willing to pay when their first migration arrives.
The hidden cost of agent lock-in—and how to push back
For a platform team shipping a customer support agent this quarter, every small decision—where to store session state, which telemetry service to use, how identity is wired—quietly fixes the future cloud home of that workload. Identity, telemetry, and deployment all terminating in one provider is what makes the operational layer under an agent so hard to move later. Enterprise adoption of ambitious agent use cases stalls when multi-cloud flexibility is impossible, because leaders sense they are rebuilding the kind of brittle, provider-specific stacks they spent a decade unwinding.
The response should be blunt. Treat cloud agent platforms as reference implementations, not as inescapable homes. Loom’s open-source design and its use of RFC 8693 token exchange show one pattern for portable governance and identity. Externalize as much of the agent’s behavior as configuration rather than runtime code so the same logic can, in theory, be retargeted to another runtime. And when vendors talk about enterprise AI agents, ask them the three questions that matter most: what is portable, what is not, and who pays the hidden bill when the next platform shift forces those agents to move.
