How Google fits more agent sessions onto fewer Kubernetes Pods.
Agent Substrate saves each agent’s workspace, borrows a shared sandbox only while work is active, and returns it afterward. The model runs as a separate service.
Google designed Agent Substrate for sessions that spend most of their time waiting.
One long-lived agent session
ActiveRun code and use tools
→
WaitingModel, tool or human response
→
ActiveContinue from the same workspace
The workspace persistsMemory · files · terminal state
Google’s isolated per-session Pod pattern
1 session=1 Pod
The Pod keeps CPU and memory while the agent waits.
Kubernetes cannot hibernate the Pod.
Large idle fleets consume Pod limits and control-plane memory.
Google starts with an isolated pattern where one long-lived agent session keeps one Pod, including while it waits. Kubernetes cannot hibernate that Pod. Shutting it down requires saving and rebuilding the session state elsewhere.
An idle agent can keep its workspace without keeping its own Pod running.
Request arrives
A new message arrives for a saved agent session.
Restore workspace
Memory and files load onto a warm Worker.
Run the turn
The sandbox uses CPU and tools, and calls the model service.
Save workspace
Memory and files are saved. The Worker returns to the pool.
Request received
Standard Pod pathSeconds addedGoogle says each request can wait through the Pod lifecycle.
→
Restore a saved sessionUnder 500 msGoogle-reported resume time onto a warm Worker.
Agent Substrate keeps saved session state separate from the Worker that runs it. Google says the standard Pod path adds seconds and reports restoring an Actor onto a warm Worker in under 500 milliseconds. Idle sessions release CPU and memory while the warm pool serves active turns.
The saved session is an Actor. The reusable sandbox is a Worker Pod.
Kubernetes
Keeps the Worker pool running.
Provision nodes
Keep Worker Pods healthy
Scale Worker capacity
Agent Substrate
Moves each request through the Worker pool.
Route the request to one Actor
Restore the Actor on a Worker
Save the Actor after the turn
The Actor keeps the agent’s identity, memory and files. A Worker Pod can run different Actors over time.
The open-source demo mapped about 250 saved Actors onto eight physical Pods. Many dormant sessions can share a small warm pool. The demo does not size that pool for simultaneous turns.
Agent Substrate resumes the workspace. A separate service runs the model.
Agent Substrate manages
Saved ActorMemory, files and terminal state persist while idle.
→
Warm WorkerCPU sandbox runs the active turn, then returns to the pool.
The application still manages
Model serviceGPU inference runs separately and the Actor calls it over the network.
External servicesDatabase and MCP connections must reopen after suspension.
No live GPU stateThe current GKE release cannot pass a GPU into an Actor or snapshot a CUDA context.
Connections reopenApplications must reconnect to databases and MCP servers after restore.
Agent Substrate EgressPolicy is unsupported on GKEThe GKE integration cannot yet apply Agent Substrate’s hostname and IP destination rules.
Agent Substrate reduces the CPU reserved for idle workspaces. It does not run the model or preserve external connections. The open-source v0.5.0 release includes egress and identity features that the October 14 Agent Substrate on GKE documentation still lists as unsupported.
Availability checked October 19, 2026. All GKE customers can evaluate the integration. Supported production use requires access to the private general-availability program. The public repository describes its APIs as early and subject to change.