An announced runtime can shape architecture planning before it becomes deployable. Keep the availability date beside every feature in the decision.
Google announces a runtime built for agents
Google’s October 22 announcement introduces Agent Compute Engine. It says preview access will arrive in the coming months. The announcement does not establish general availability today.
Google describes hardware-isolated microVMs that can run code, tools, and browser workflows. Each microVM has persistent Hyperdisk storage for its workspace and context. The design also supports pausing and resuming agent execution.
The company’s isolation and performance statements describe its architecture and measurements. They are not an independent security assessment or a guarantee against every failure.
Identity and execution state need separate controls
The announcement gives each agent an identity and describes credential handling outside the microVM. That can reduce the need to place raw credentials within agent execution.
Persistent storage creates another operational decision. Determine which files and context survive a session, who can read them, and how the application removes them after the work ends.
For a proposed integration, write down the identity used for each tool call. Check the relationship between that identity, the agent’s workspace, and the person who authorized the task.
Agent Substrate is a different deployment route
Google also describes Agent Substrate, an open-source execution runtime on Google Kubernetes Engine. It targets teams that want control and customization in Kubernetes.
The same announcement discusses broader agent governance. Those controls have their own access and rollout conditions. A governance announcement does not make every runtime feature available in every project.
Teams already running GKE should examine the actual runtime, documentation, and operational requirements before treating Agent Substrate as a substitute for the announced managed service.
Build an availability and operations checklist
I would compare a currently usable runtime with the announced service using the same workload. Leave any unavailable feature marked pending until the project can actually access it.
- Record the product, project, and access status.
- Identify the execution boundary and outbound network controls.
- List persistent files and their retention requirements.
- Check identity creation, credential delivery, and revocation.
- Test pause, resume, and cleanup with harmless work.
Avoid basing a production date on a phrase such as “coming months.” Plan around an accessible runtime, then reconsider the new service when its preview terms and usable interfaces are published.
The Agent Platform sandbox article covers an existing product release. Our GKE sandbox analysis examines a separate runtime benchmark.
Sources
Which requirement needs a working runtime now, and which can wait for the announced preview?
Checked October 25, 2026. Prepared with AI-assisted research and drafting, with claims checked against the linked sources. MustHave.ai has not performed the proposed product tests.
