Google’s Open Agent Runtime Separates Idle Sessions From Kubernetes Workers

An agent may run a tool for seconds, then wait for a model response or a person for much longer. Giving every waiting session a continuously active Kubernetes Pod can tie memory and control-plane objects to work that is idle. Google’s Agent Substrate proposes a different split: preserve the session as an actor, and lend it an execution worker only when it needs to run.

Persistent identity, reusable compute

Google announced on November 5 that Agent Substrate, gVisor and OpenRL would move into the Cloud Native Computing Foundation after entering the CNCF Sandbox. Agent Substrate also reached version 1.0 and became generally available on Google Kubernetes Engine. The open-source runtime is presented as portable across Kubernetes environments; the GKE managed capability is a separate delivery option. ^[1]

In the architecture, an Actor holds an agent’s memory, files and identity. A Worker is a reusable execution sandbox. A Gateway enforces inbound and outbound access and injects credentials according to the Actor’s identity. When a session pauses, the system snapshots its state and returns the Worker to a warm pool; a later request resumes the Actor on an available Worker. ^[1]

The benefit is not merely container density. Separating identity and persistent state from the underlying process can make the lifecycle easier to reason about: a session can be idle without holding compute, and the system can apply a central policy at a gateway. But that also makes snapshot correctness, identity binding and authorization between resume events critical.

Benchmark numbers need a workload attached

Google reports that Agent Substrate can restore sessions in under 500 milliseconds, run millions of sandboxes at 10 times the density of standard container runtimes, and perform more than 500 suspend-and-resume activations per second. These figures are from the vendor announcement. They do not specify every workload, persistence, networking or isolation condition a buyer needs to reproduce before sizing a deployment. ^[1]

A useful pilot should measure the shape of the team’s own agent work: active compute time, idle wait time, snapshot size, resume latency at the tail, and how often a session retries after a model or tool call fails. Include state durability across worker restarts and node drains. “Under 500 ms” is not enough unless the measurement includes the state volume and the time from the application’s perspective.

The isolation boundary matters as much as density. Google describes gVisor as a userspace application kernel that handles system calls between the container and host. Its own documentation describes the security model and tradeoffs; using it should not be treated as equivalent to proving the whole agent execution path safe. Teams should test network egress, file access, mounted credentials, tool permissions and what happens when an agent resumes with stale authorization. ^[3]

Open governance is a milestone, not an outcome

The CNCF Sandbox application describes Agent Substrate’s actor and worker model and lays out future roadmap items such as stronger actor identity, network policy and scale goals. An application or roadmap is not evidence that every listed capability is finished. Google’s announcement says the projects are working through Sandbox onboarding with community maintainers and independent build infrastructure; that status is different from graduating to a higher CNCF maturity level. ^{[1] [2]}

Open governance can widen review and contribution, but users still need to inspect who maintains the code, where releases are built, how security reports are handled, and how breaking changes are communicated. The managed GKE service may add operational convenience; it also means teams should distinguish what is available upstream from what is delivered by a cloud product.

For infrastructure teams, this stack is worth evaluating when agents spend most of their lifetime waiting, need persistent working state, and execute code or packages that require isolation. Compare it against simpler per-job containers using the same workload and security requirements. Count the operational parts too: snapshot storage, gateway policy, telemetry, cleanup, and recovery after partial failure.

For related background, see our coverage of API streaming limits for AI responses and durable permissions for long-running agents.