Google Cloud is pushing a new layer of open infrastructure for autonomous software. Agent Substrate, an open orchestration runtime for multi-turn AI agent workflows, is heading into the Cloud Native Computing Foundation's Sandbox program, and Google presented it as part of an open AI-native stack for Kubernetes on November 10, 2026. The timing matters because enterprises want agents that run for hours and touch real systems, and they need a way to contain each one without giving up efficiency.
What Agent Substrate Does
Most agent tooling focuses on the model call. Agent Substrate focuses on the lifecycle around it. Google describes it as providing lifecycle management and execution targets for workflows where an agent takes many steps over time, which means starting, pausing and resuming agents as work comes and goes.
Isolation is the core design choice. Each agent runs in its own sandbox, and Google pairs the runtime with gVisor, which Google describes as a user-space kernel that intercepts and virtualizes system calls. In Google's framing, untrusted agent code cannot compromise the host kernel or reach neighboring tenant workloads. According to a technical summary of the project's documentation, the runtime can also use Cloud Hypervisor microVMs through the same API.
Suspending idle agents is the other half of the design. When an agent goes quiet, the runtime snapshots its state to tiered storage and returns the machine to a pool. When the agent is needed again, it can resume on any ready worker. Google says a frozen agent can resume in under 500 milliseconds with its prior state intact, although the post does not explain how that figure was measured.
What Developers Need to Know
The suspend-and-resume model has a practical catch. Open network connections, such as database sessions or connections to Model Context Protocol servers, are not preserved across a suspend. Agent code has to reconnect after resuming, which is a design change for teams used to long-lived sessions.
GPU support is the bigger open question. Google's Substrate documentation says GPU device passthrough into actor containers is not supported, and it notes that gVisor cannot snapshot live CUDA contexts. Google's November 5 Cloud blog, however, describes gVisor as supporting GPUs, which conflicts with that documentation. Teams running GPU-heavy agents should confirm which statement applies to their workload before planning production capacity.
Maturity is also disputed. Google describes a 1.0 milestone, but the project's GitHub README still calls it pre-1.0, and a technical review of the repository found no final v1.0.0 release in its listings. The CNCF describes Sandbox projects as experimental and not yet widely tested in production, so teams should treat the project as early-stage.
Before adopting it, platform teams should check a short list:
- Which isolation mode fits the workload: gVisor or a microVM.
- Whether agent code can reconnect cleanly after a suspend and resume.
- Whether any agent needs GPU access, and how that is supported.
- Which release status the team is willing to accept for production.
The Open Stack Around It
Agent Substrate sits inside a broader set of components that Google has placed in the CNCF or open-sourced. The November 10 post lists OpenRL, KubeRay for distributed compute, gVisor for isolation, llm-d 1.0 for model serving and TorchTPU alongside Agent Substrate. Together they are meant to let teams run open models, distributed inference and agents on the same Kubernetes foundation.
For platform teams, the appeal is consistency. An organization already running Kubernetes can add agent workloads to existing clusters, apply the same policies and monitoring, and avoid building a separate sandboxing system for each agent framework. That matters as agent workloads spread across departments that each want their own tools.
Why It Matters
Agent containment is becoming a core infrastructure question rather than an afterthought. A model that can call tools and modify files needs a boundary that holds even when its instructions go wrong. Kernel-level isolation and cheap suspension address two of the hardest operational problems: keeping agents separated from one another and avoiding payment for machines that sit idle.
Because the code is open source, teams are not tied to a single vendor's cloud, which is a meaningful difference for regulated industries that want to keep agent workloads in their own environments. Supported clusters, per the technical review of the documentation, are GKE Standard clusters running version 1.37 or later, so portability claims should be tested against the actual deployment target.
The competitive context is also worth noting. Google separately announced a managed Agent Compute Engine on October 22, which uses a hardware-attested microVM instead, and for which no preview date or pricing has been given. Agent Substrate is the open counterpart: a runtime that any team can inspect, modify and run, with the trade-offs that come with early-stage open-source software.
