Google releases Agent Substrate 1.0 for AI agent workloads

What shipped this week

Google Cloud said on November 5 that Agent Substrate 1.0 was generally available on Google Kubernetes Engine. The public upstream repository published its v1.0.0 release later that day at 23:55 UTC, or 01:55 on November 6 in Bucharest. The company also announced the donation of Agent Substrate, the gVisor runtime and the OpenRL training project to the Cloud Native Computing Foundation. Those are two developments with different consequences. A release gives teams a version to evaluate. A donation changes how a project can be governed and developed over time.

The foundation decision predates the announcement. For Agent Substrate specifically, CNCF’s public record shows the oversight vote passed on September 29. The contribution agreement was marked signed and an onboarding issue opened on October 20. CNCF describes Sandbox as its entry stage for early projects. Google’s separate claim of general availability concerns its managed product. The two labels answer different questions about who can use the service and how the open project is governed.

Source notes: 1, 2, 3, 5, 6.

Why a waiting agent still costs money

Imagine a coding agent that checks out a repository, runs a test and then waits for a developer to answer a question. Its work may exist partly in files and partly in the memory of the processes it started. Rebuilding the environment after every pause can discard useful state. Keeping every session running, including those that will sit untouched for hours, reserves capacity that another job could use.

Agent Substrate separates the session from the worker that executes it. In its terminology the session is an Actor. An active Actor occupies a worker in a pool. When an eligible Actor is suspended, its state can be written to storage and the worker reused. A later request can restore the state on an available worker. That makes the length and frequency of idle periods central to the economics. A continuously active task has little idle time to reclaim. A sparse workload can benefit more, provided storage operations and keeping a pool warm cost less than the compute that is freed.

Google says idle restores can take less than half a second and cites up to ten times the density of conventional containers. Those figures describe Google’s claims. TSN reported them with the same attribution. We found no independent reproduction establishing that the figures apply to typical customer clusters. A large repository, a cold worker pool and many users returning after a shared break could each change the result.

Source notes: 1, 4, 5.

What the sandbox can protect

The worker that runs generated code is one boundary. gVisor puts a user-space application kernel between that code and much of the host’s kernel interface. Google documents a separate microVM option for compatible nodes. Platform teams still have to decide which destinations an Actor can reach, what data it can read and what credentials it can exercise. An isolated process with a token allowed to change a production repository can still make an authorized change to that repository. The sandbox cannot tell whether that change was the one the operator intended.

A checkpoint also creates a new place where sensitive state may persist. An agent can have source code, personal data or information obtained from a tool in memory while it runs. Operators need to know where a snapshot lands, how long it remains, which identity can restore it and what audit records are available. Google documents a scoped snapshot-transfer identity for the managed offering. That implementation detail gives administrators a concrete permission to review before enabling a pilot.

Source notes: 1, 3, 4.

What a migration would actually require

Google’s managed documentation specifies GKE Standard 1.37 or later for the control plane and node pools. It excludes Autopilot and says some node configurations are unsupported. It also says open network connections, including database and MCP sessions, do not survive suspension. An agent may resume with its files and process state intact and still need to reconnect to the outside world. Any task with an external write needs a way to determine whether that write already succeeded before it tries again.

The upstream release notes give operators another reason to stage upgrades. One change removes shared network policies between pools whose names are similar. Another changes how the scheduler accounts for memory consumed by microVM Actors. Those changes may matter to security boundaries and capacity even if an application’s prompts stay the same. A version pin and a test deployment offer a clearer comparison than updating the runtime and the workload together.

For a first comparison, run the same tasks under a dedicated environment and a pooled one. Measure the time from a user request to the first successful action, including the slowest restores when the pool is busy. Check how often the agent has to reconnect, whether a suspended job can resume across a node replacement and how much snapshot storage it creates. Include idle workers and storage in the cost comparison. A headline restore time answers a narrower question than whether a user can finish the task faster or the platform can run it more cheaply.

The release is most immediately relevant to teams whose agents alternate between bursts of work and long waits. A lightweight service that can restore its state from a database may already have a simpler answer. For workloads that do need a live working environment, the public milestone gives teams a version to pin and a set of limits to test against before changing production.

Source notes: 2, 4.