AWS, Microsoft, and Google converge on session-aware agent runtimes—but disagree on isolation

Over the past few months, AWS, Microsoft, Google, and Anthropic each quietly shipped similar runtime updates that signal a fundamental architectural shift in how AI agents operate at scale.

The architectural convergence#

The pattern is striking: Microsoft isolated agents in sessions on Foundry; Anthropic decomposed Managed Agents into a session, harness, and sandbox; AWS routes each session to its own Firecracker microVM; and Google separates agent code execution into a dedicated sandbox while keeping request-level scaling for the reasoning loop. The common thread is not a new model capability—it's a shift from treating agent work as ordinary load-balanced HTTP traffic to treating it as long-running, stateful sessions that require dedicated compute isolation and lifecycle management.

Enterprise agents break the assumptions that made traditional load balancing work. Unlike stateless API requests that can route to any available worker, agents maintain conversational state across multiple turns, execute model-generated code influenced by user input, and need strong security boundaries. When an enterprise support agent processes a refund request across multiple steps, losing context between turns breaks the workflow. When untrusted code runs server-side, running it on a shared kernel violates enterprise tenant isolation requirements.

Why session affinity isn't enough#

Load balancers can use session affinity (consistent hashing on conversation IDs) to preserve routing continuity, but this only solves state preservation. It doesn't address the security boundary problem. A 2025 incident where Asana's MCP server exposed data across 1,000 organizations showed why: the server validated users but failed to consistently enforce agent and tenant context in cached responses. Isolation requires more than routing strategy—it requires a dedicated execution environment per session.

Four platforms, different substrates#

The convergence on session-aware scheduling reveals itself most clearly in lifecycle management. AWS documents that an AgentCore session transitions through Active (processing) → Idle (provisioned, waiting) → Terminated (after 15 minutes idle or 8 hours max). This is the lifecycle of a long-running environment, not an HTTP request. Billing follows the same logic: cost drivers shift from request volume to active sessions, concurrency, and idle time.