Google Launches Agent Sandbox on GKE and Open-Sources Agent Substrate

In just a few short years, AI agents have evolved from novelty chat interfaces into autonomous systems capable of function calling, code execution, and persistent terminal use. But executing untrusted agent logic safely at scale is a fundamentally different challenge than running traditional microservices. This week, Google Cloud made its boldest move yet into agent-native infrastructure, launching GKE Agent Sandbox in general availability and introducing Agent Substrate, a new open-source project designed to handle the extreme scale and density demands of the next generation of AI workloads.

The announcement, published on the Google Cloud Blog, signals a broader shift across the Kubernetes ecosystem: the control plane is no longer just for long-running services. It is being rebuilt for millions of ephemeral, bursty, and highly isolated agent executions.

From Preview to Production: Agent Sandbox Goes GA

Google first unveiled Agent Sandbox at KubeCon North America in November 2025. Since then, adoption has exploded: Google reports more than 16x growth in sandbox deployments on GKE in under five months. The company has worked closely with key customers including LangChain and Lovable, who are deploying millions of agent instances into production.

Agent Sandbox is an open-source, cloud-native execution environment built directly on Kubernetes. It provides secure, low-latency sandboxing for AI agents using technologies like gVisor and Kata Containers, with default-deny Kubernetes network policies baked in from day one. The GA release delivers on four core requirements:

Pod Snapshots for Idle Agents

AI agents are notoriously bursty — they run for seconds, then sit idle for minutes or hours. Instead of wasting compute to keep idle pods warm, Agent Sandbox integrates with Pod Snapshots to suspend idle workloads and resume them in seconds upon request.

Warm Pools at Sub-Second Latency

Initializing a new sandbox for every request introduces painful cold-start latency. Agent Sandbox introduces a Sandbox API with an integrated warm pool that can allocate 300 sandboxes per second, per cluster, with 90% of allocations completing in under 200 milliseconds.

Cost-Effective Standby Capacity

To minimize the cost of maintaining warm pools, Agent Sandbox is integrated with standby capacity buffers using suspended VMs. This cold pool of pre-provisioned sandboxes can quickly replenish the warm pool at a fraction of the cost of keeping them live.

Hardware-Agnostic Performance

Google claims that Agent Sandbox delivers up to 30% better price-performance when running on its custom Axion processors compared to comparable hyperscaler offerings.

Agent Substrate: A New Layer for Ultra-Scale Agents

The most forward-looking part of the announcement is Agent Substrate, a new open-source project designed to address what Google calls “the next mode of infrastructure.”

Agentic workloads are scaling to tens or hundreds of millions of instances while simultaneously becoming increasingly idle, waiting for human interactions or event triggers. Standard Kubernetes is optimized for thousands of long-running services. It was never designed for the “chatter of millions of sub-second tool calls” that would otherwise overwhelm a traditional control plane.

Agent Substrate introduces a minimal control plane that pairs the secure runtime and snapshotting capabilities of Agent Sandbox with a purpose-built scheduling layer. It bypasses some of Kubernetes’ limitations “without reinventing the rest of it,” optimizing critical paths for lower latency, higher scale, and greater efficiency.

One of the most ambitious explorations within Agent Substrate is bringing data locality into the core of the scheduler — ensuring that agent state and scheduling decisions work together to shave off every possible millisecond of overhead. Google is explicitly inviting the community to collaborate: “By kicking off the Agent Substrate project in the open, we are inviting the community to help design and build this critical next mode of infrastructure.”

The AI Inference Race Heats Up on GKE

Agent infrastructure is not the only place Google is pushing Kubernetes forward. The company also released an independent benchmark report showing that the GKE Inference Gateway dramatically outperforms competing managed Kubernetes services on LLM inference workloads.

Using prefix caching and model-aware routing instead of naive round-robin load balancing, GKE Inference Gateway achieved:

15.7% higher throughput in tokens per second
92.8% shorter time-to-first-token (TTFT)
62.6% lower inter-token latency

Snap Inc. reported prefix cache hit rates of 75–80% using the gateway in production, thanks to the open-source nature of the underlying llm-d project and its seamless integration with Envoy-based service meshes.

Meanwhile, Across the Ecosystem

AWS: Zone-Aware Routing in ECS Service Connect

Amazon is also tightening Kubernetes-adjacent infrastructure. Last week, AWS announced zone-aware routing for Amazon ECS Service Connect, a managed service mesh that routes traffic preferentially within the same Availability Zone. The feature can reduce cross-AZ data transfer costs and cut median network latency by approximately 24% in multi-AZ deployments — with no application code changes required.

containerd v2.3.3: CRI Hardening

The containerd project released v2.3.3, a patch release containing several CRI (Container Runtime Interface) fixes. Notable improvements include rejecting CreateContainer calls when the target sandbox is not running, ensuring sandbox shutdown on RunPodSandbox hook failures, and surfacing OCI error bodies in registry 403 responses.

etcd v3.7.1 Lands

etcd, the distributed key-value store at the heart of every Kubernetes cluster, shipped v3.7.1. The release includes RangeStream support, bootstrapping from v3store, and a protobuf overhaul — capabilities that Kubernetes v1.37 will build upon for more efficient Watch/List operations.

DRA Device Taints Graduate to GA

Closer to the Kubernetes core, the Dynamic Resource Allocation (DRA) Device Taints and Tolerations feature graduated to General Availability via the resource.k8s.io/v1 API. This milestone stabilizes how clusters restrict access to specialized hardware like GPUs using dedicated device-level taints, giving operators and hardware vendors a production-ready framework for fine-grained resource scheduling.

Node Lifecycle Conditions

Kubernetes also introduced several new well-known node conditions including GracefulNodeShutdownInProgress, DrainInProgress, Drained, MaintenancePlanned, and MaintenanceInProgress. These standardized states expose structural cluster disruptions to downstream automation tools, giving controllers and operators the signals they need to coordinate maintenance workflows and improve overall workload uptime.

What This Means for Platform Engineers

The message from this month’s Kubernetes news is clear: the control plane is evolving. Kubernetes is no longer just a container orchestrator for microservices. It is becoming the foundational layer for AI workloads — from inference gateways that optimize GPU utilization, to agent sandboxes that execute untrusted code in isolation, to entirely new control planes designed for sub-second, millions-of-instances scale.

For platform engineers, the implications are significant. The skills that matter most are shifting from traditional cluster administration toward understanding how to integrate AI-native infrastructure layers — sandboxing, snapshotting, warm pools, prefix caching, and model-aware routing — into existing Kubernetes estates. The projects shipping this month suggest that the platforms managing the next decade of workloads will look very different from those that managed the last one.