Google brings Agent Substrate 1.0 to general availability on GKE Google brings Agent Substrate 1.0 to general availability on GKE

A production milestone for an existing runtime

Google first announced Substrate availability on GKE on September 15. That announcement already described reusable execution environments, isolated code execution and a runtime portable across Kubernetes installations. The November release advances that existing project to its 1.0 and general-availability milestones. Its purpose remains concrete: coding and personal agents alternate between short bursts of work and pauses for a model, an external tool or a person. Holding a dedicated execution environment through those pauses consumes resources even when no useful work is happening. The runtime separates the agent’s continuing session from the machine that performs its next turn.

State moves between workers

The current product documentation calls an agent instance an Actor and its execution environment a Worker. A request for a suspended Actor claims available capacity and restores the saved session. When the application suspends it again, memory and local files become a snapshot and capacity returns to the shared pool. This changes the deployment model from keeping one Pod attached to each agent. Google supplies installation tooling for customers’ own clusters, so general availability still involves operating infrastructure. A platform now manages two connected resources: stored sessions that can wait and execution capacity that must be ready when requests arrive.

The idle policy belongs to the application

Google’s infrastructure guide explicitly assigns the suspension decision to the application or orchestrator. Substrate does not automatically put every inactive agent to sleep. The guide sizes capacity around peak concurrent activity and peak resume traffic. Its worked example starts with 100,000 registered Actors, ten percent active on average and a twofold burst. That produces 20,000 simultaneously running Actors; at 100 seconds per turn, the system needs 200 resumes and suspends per second. These are planning inputs, not measurements of a customer deployment. The example shows why registered session count alone says little about the hardware a service needs.

The governance change has its own timeline

The release also sits within a broader transfer of agent infrastructure to the Cloud Native Computing Foundation. The gVisor project had already announced its donation on October 2, after acceptance of its application on September 28. Its published plan described external maintainers, independent build systems and a staged change in governance. That history matters because a new umbrella announcement does not make every component a new launch. For infrastructure buyers, governance affects who can review changes and set priorities. Runtime maturity, project ownership and the operating responsibilities of a particular deployment remain separate parts of the purchasing decision.