Agent Compute Engine vs Substrate: 10x Claim Checked [2026]

Google Cloud announced Agent Compute Engine on October 22, 2026, a managed service that runs each AI agent session in its own hardware-isolated microVM with a separate guest kernel, identity-based networking and checkpointing for idle sessions, built on Cloud Hypervisor and Google Cloud's Titanium infrastructure. The service is not generally available: Google says a customer preview is coming "in the coming months" with no firm date and no price, while the companion open-source Agent Substrate runtime already runs on Google Kubernetes Engine for non-production workloads. Google says Agent Compute Engine already powers the Gemini agent for work tasks and supports the Gemini platform, Google Antigravity and internal model-evaluation and reinforcement-learning pipelines.

Google Cloud announced Agent Compute Engine on October 22, 2026 https://cloud.google.com/blog/topics/ai-infrastructure/introducing-agent-compute-engine-and-expanded-agent-governance/ , a purpose-built compute service that gives each AI agent its own hardware-isolated microVM. The same announcement introduced Agent Substrate on Google Kubernetes Engine GKE , an open-source runtime for teams that want to keep agents on Kubernetes. Nine days later, the real story is the split between the two, and a pile of benchmark numbers that belong to only one of them. Agent Compute Engine is not generally available. Google says a customer preview is coming “in the coming months,” with no firm date and no price. Agent Substrate, by contrast, already runs on GKE for non-production workloads. That gap matters for anyone planning a budget, because the managed service and the open-source runtime solve the same problem with very different operating models. Platform teams already running GKE Agent Sandbox https://shattered.io/gke-agent-sandbox-gvisor-300-per-second-2026/ now have two more paths to weigh. Don't miss new tech stories on Google Add Shattered once in the Google app and our stories show up in your news suggestions. Add now https://www.google.com/preferences/source?hl=en&q=https%3A%2F%2Fshattered.io%2F What Google Announced on October 22 Google unveiled Agent Compute Engine at AGNTCon + MCPCon, according to coverage from TechTimes https://www.techtimes.com/articles/329428/20261023/google-cloud-unveils-agent-compute-engine-ai-agent-credentials-kept-outside-hardware-sandbox.htm . The company describes it as managed infrastructure for interactive and enterprise AI agents. Each agent session runs in a hardware-isolated microVM with its own identity, networking, configurable images, lifecycle controls and checkpointing for idle sessions. MarkTechPost https://www.marktechpost.com/2026/10/22/google-cloud-agent-compute-engine-microvm-ai-agents/ summed it up in its headline: a microVM per AI agent. Google also pointed to two governance products as part of the architecture: Agent Gateway and Agent Registry. Neither is a separate launch this week, but the announcement ties them to the compute layer. The idea is simple. An agent that can write code, call tools and browse the web needs a place to run, a way to prove who it is, and a choke point where its outbound calls get checked. Google says Agent Compute Engine already powers the Gemini agent for work tasks. That detail carries weight. It means the service is not a lab prototype, even though customers cannot touch it yet. Google also says the platform supports the Gemini platform, Google Antigravity and internal model-evaluation and reinforcement-learning pipelines. The second product announced the same day is Agent Substrate on GKE. Google calls it an open-source, secure-by-default execution runtime optimized for GKE but built to run on any Kubernetes cluster. It works with agent frameworks and harnesses including Claude Code, OpenClaw and Hermes. Google positions it for teams that want customization, multi-cloud portability, or an existing Kubernetes operating model. How Agent Compute Engine Isolates Each Agent Containers share a host kernel. That is fine for a web service you wrote yourself. It is a weaker bet for an agent that executes code a model generated five seconds ago, after reading a web page nobody vetted. Agent Compute Engine answers with a microVM per agent, so a compromised guest still faces a hardware boundary before it reaches the host or a neighbor. One microVM per agent Google describes zero-trust execution, kernel isolation and identity-based network security for each agent. TokenPost reports https://www.tokenpost.com/news/technology/38834 that every microVM gets its own guest kernel and root access inside a hardware-isolation boundary built with Cloud Hypervisor. The same report says the design uses Google Cloud’s Titanium infrastructure processing unit and combines copy-on-write memory sharing with checkpoint-and-restore, so idle microVMs can pause and come back later. That pause-and-resume cycle is the economic core of the product. Agents spend much of their lives waiting on a model response, a human approval or a slow tool call. A service that bills for idle time wastes money, and one that tears down state loses the work. Application-aware checkpointing is Google’s attempt to avoid both problems at once. Think about a coding agent that opens a repository, runs tests, waits twenty minutes for a reviewer and then resumes. On a plain container platform, that agent either holds its compute the whole time or loses its working directory. A checkpointed microVM can park cheaply and wake with its memory intact. Whether Google’s version delivers that in practice is exactly what the preview will test. Credentials stay outside the sandbox The TechTimes headline says it plainly: agent credentials sit outside the hardware sandbox. The service tokens and API keys that let an agent read a database or write to storage never live inside the microVM. If a prompt injection hijacks the agent, the attacker lands in a box with nothing worth stealing. TokenPost’s account matches, noting that service credentials stay outside the microVM. This design choice deserves more attention than the density claims. Most agent incidents described so far follow one pattern: the agent holds a powerful secret, and a crafted document redirects it. Moving the secret out of reach does not fix prompt injection, but it shrinks what a successful injection can do. Agent Substrate on GKE: The Open-Source Path Agent Substrate takes the opposite approach on control. Google describes it as an open-source runtime for Kubernetes designed for agent isolation, checkpointing, suspension and fast state restoration. Reports say it derives from the secure-runtime and snapshotting concepts of Agent Sandbox, with a smaller control plane aimed at higher scale and lower latency. Google presents it as a new project built alongside Agent Sandbox, not a replacement or retirement of it. Availability is where reports diverge. Launch coverage on October 22 presented Agent Substrate alongside Agent Compute Engine. Some secondary reports date its availability on GKE to September 15, and Google’s own post is titled “Agent Substrate available on GKE.” The safe reading: Google reportedly introduced the open-source project in May, GKE customers can run it on non-production workloads today, and production support comes through an allowlist. No unrestricted general availability has been announced. The runtime also gained a networking story on October 28, when Google published guidance for GKE networking dataplanes supporting large agentic workloads. The guidance reportedly connects Agent Substrate with Agent Sandbox and GKE Dataplane V2 recommendations, aimed at fleets large enough to strain normal Kubernetes scheduling limits. Agent Compute Engine vs Agent Substrate Compared Google insists the two products are complementary, and the table below shows why. One is a managed service you consume. The other is software you operate. Pick based on who you want carrying the pager. | Attribute | Agent Compute Engine | Agent Substrate on GKE | |---|---|---| | Form | Managed Google Cloud service | Open-source Kubernetes runtime | | Announced | October 22, 2026 | October 22, 2026 alongside Agent Compute Engine | | Isolation | Hardware-isolated microVM per agent | Zero-trust isolation for agent sandboxes | | Where it runs | Google Cloud | Any Kubernetes cluster, optimized for GKE | | Release status | Not generally available, preview in coming months | Non-production on GKE, production by allowlist | | Harness support | Powers the Gemini agent | Claude Code, OpenClaw, Hermes | | Public price | None announced | None announced | | Best fit | Teams that want Google to run it | Teams standardized on Kubernetes or multi-cloud | Notice what the table implies. A shop that already runs hundreds of services on GKE has a ready home for Agent Substrate and a shorter path to a pilot. A team without Kubernetes expertise gets little from the open-source option and should wait for the managed preview. The decision tracks existing skills more than raw features. The 10x Density and 200,000-Agent Numbers, Read Carefully Headlines about the launch mash the benchmark figures together. Careful readers should not. TokenPost spells out that the 10x density claim and the 200,000-agent benchmark apply to Agent Substrate, not to Agent Compute Engine. Google has published no comparable numbers for the managed service. | Claim | Figure | Applies to | |---|---|---| | Density versus standard container runtimes | Up to 10x | Agent Substrate | | Agents in the validation run | 200,000 | Agent Substrate | | Suspend/resume activations | 500 per second | Agent Substrate | | Suspend/resume latency | Under 500 ms | Agent Substrate | | Published benchmarks for the managed service | None | Agent Compute Engine | These are vendor numbers from vendor tests. Google has not published the hardware, the agent workload or the idle-to-active ratio behind the 200,000-agent run. A sandbox that wakes in under 500 milliseconds sounds fast, but an agent loop that wakes dozens of times per task will feel every one of those half-seconds. Treat the figures as design targets until an independent lab reproduces them. A separate Google claim, reported at single-source level, says a customer deployment orchestrates hundreds of thousands of secure environments and absorbed spikes above 30,000 sandboxes on one cluster. Google did not name the customer. Until it does, that line works as marketing color, not evidence. What Google Says in Its Own Words Three statements from Google’s announcements capture the pitch. Gautham Thambidorai, VP and Google Fellow for Gemini, said in Google’s Agent Compute Engine announcement post: “Scaling the Gemini agent to planet scale requires compute that spins up rapidly and operates with extreme efficiency. Agent Compute Engine microVMs give us the responsiveness, hardware isolation, and workload density needed to deliver interactive agent sandboxes to our users around the world.” The same post describes the product from the customer side: “Purpose-built for agents, Agent Compute Engine gives every Gemini agent its own high-performance, secure computer to act upon, powering Gemini’s dynamic, high-churn sessions.” The phrase “high-churn” is the tell. Google designed for sessions that start, stall and resume constantly, which is the opposite of the long-lived web servers that cloud pricing grew up around. For the open-source side, Google’s Agent Substrate announcement on the Google Cloud blog says: “Agent Substrate is an open-source, secure-by-default agent execution runtime engineered to run millions of sandboxes with 10x higher density than standard container runtimes.” That sentence is a design claim. The 200,000-agent benchmark is the only public test behind it so far. Why This Matters for Kubernetes AI Agent Security Security teams have spent two years bolting guardrails onto agents that run in ordinary pods. The new Google products admit that approach has limits. Agent Compute Engine puts a hardware boundary and a credential boundary in the platform itself. Agent Substrate brings zero-trust isolation into the Kubernetes world, where most enterprises already keep their workloads. Three threat patterns drive the design. First, prompt injection that redirects an agent’s tools. Second, generated code that tries to escape its sandbox. Third, lateral movement from one tenant’s agent into another’s data. A microVM per agent addresses the second and third directly. Credential separation addresses the first by limiting the prize. Existing cluster hygiene still applies. Teams that harden pods with the steps in this container security hardening guide https://shattered.io/container-security-hardening-kubernetes-2026/ will find the same principles, least privilege and network segmentation, now extended to agent identity. Google’s own detection tooling moves in a similar direction, as seen when GKE gained AI threat detectors https://shattered.io/gke-ai-threat-detectors-outage-2026/ earlier this year. Identity tooling is moving too. Google reportedly introduced IAM Helper on October 27, a suite of agent-facing IAM building blocks and Agent Skills for automating access-management workflows. Only one source reports it, so treat the details as provisional. The direction is clear: agents get their own identities and their own permission trails, separate from the humans who launch them. One caution. Isolation does not equal safety. An agent that legitimately holds permission to email customers can still be talked into emailing the wrong ones. The sandbox contains the blast radius of a breach, not the consequences of a bad decision made with valid access. Governance products like Agent Gateway and Agent Registry exist to cover that second gap, and Google has yet to publish how they enforce policy in practice. Pricing and Availability: What Google Has Not Said Google’s launch materials publish no price, SKU, billing meter or plan tier for Agent Compute Engine or Agent Substrate. They also give no preview date, no supported regions and no version number. That leaves buyers guessing, and the table below separates what is known from what is open. | Question | Status as of October 31, 2026 | |---|---| | Is Agent Compute Engine generally available? | No, customer preview planned in coming months | | Is there a firm preview date? | No | | Is a price published for Agent Compute Engine? | No | | Is a price published for Agent Substrate? | No separate price, open source | | Can GKE customers run Agent Substrate? | Yes, non-production, with production by allowlist | | Are regions or SKUs listed? | No | | Have any products been renamed or retired? | No | One hint exists. Google’s Gemini platform pricing page reportedly lists agent compute at $0.085 per vCPU-hour, with the first 50 hours per month per account free, plus agent memory at $0.009 per GiB-hour and agent storage at $0.30 per GiB-month. The page says runtime and sandbox usage, including code execution and computer use, bills through those meters. Whether Agent Compute Engine will adopt the same meters for enterprise customers is unconfirmed, so budget planners should not copy those rates into a forecast yet. Model costs also move this quarter. Google’s Gemini 4 Argon, released October 13, carries an introductory API price of $2 per million input tokens and $10 per million output tokens, with cached input tokens at 95% off. After the introductory period ends on November 30, 2026, the price rises to $4 and $20. Anyone modeling the cost of an agent fleet should note that tokens, not compute, may dominate the bill. Historical Context: From Containers to Agent Sandbox Cloud providers learned a hard lesson from multi-tenant serverless: shared kernels invite escape attempts, and strong isolation costs memory and startup time. Lightweight virtual machines emerged to trim that cost. AI agents revive the same debate with higher stakes, since the code running inside is now written by a model on the fly. Google’s own path ran through Kubernetes. In May 2026, GKE Agent Sandbox reached general availability, giving teams an isolation primitive for dynamic execution environments. Agent Substrate then arrived as a separate open-source project derived from the same ideas, with a leaner control plane. Agent Compute Engine, announced last week, moves the whole concept out of Kubernetes into a managed service. The sequence tells a story. First Google gave Kubernetes users a way to sandbox agents. Then it chased density. Now it offers to take the infrastructure off customers’ hands. Each step trades control for convenience, a pattern familiar from the jump from virtual machines to managed Kubernetes to serverless platforms like Cloud Run https://shattered.io/google-cloud-run-deploy-docker-12-steps-2026/ . How the Gemini Agent and Model Releases Fit In Infrastructure launches rarely stand alone. On October 8, at Gemini at Work 2026, Google Cloud announced the Gemini agent, a universal agent for work that plans tasks, uses skills and tools, writes and runs code, and connects to business systems. Agent Compute Engine is the runtime under it. Five days later, Google released Gemini 4 Argon as globally available through the Gemini API, AI Studio, the Gemini platform and AI Mode in Search. Gemini 4 Carbon followed on October 28. Google says it scores 88.2% on SEC-bench Pro, a vulnerability-finding benchmark, and limits access to a subset of cyber defenders through its Fairwind Program. A model that finds real flaws in real software raises the stakes for agent sandboxes, since the same capability in the wrong hands makes isolation more valuable, not less. Google also widened model choice. It announced it is bringing OpenAI models to customers and, on October 23, announced general availability of an Anthropic-managed deployment option for Claude models on Google Cloud. The pattern is deliberate. Google wants agents of any lineage to run on its infrastructure, which explains why Agent Substrate lists Claude Code among supported harnesses. Competitive Comparison: Managed Sandbox vs Kubernetes Runtime Google is not alone in chasing agent compute. Futurum Group analysts framed the launch as a “parity test” for cross-cloud governance in their October 30 note https://futurumgroup.com/insights/google-agent-compute-engine-puts-cross-cloud-governance-to-a-parity-test/ , a signal that rivals are expected to answer. Verified details on competing agent-specific compute products are thin right now, so any head-to-head on price or performance would be guesswork. What the market does offer is a spectrum of control. At one end sit fully managed Kubernetes modes, covered in this comparison of EKS Auto Mode, GKE Autopilot and AKS Automatic https://shattered.io/eks-auto-mode-vs-gke-autopilot-vs-aks-automatic-2026/ . In the middle sit sandbox primitives layered on top of clusters. At the other end sits the model Google just announced: one microVM per agent, billed and operated by the cloud. Google’s differentiator is the pairing. A buyer can start with the open-source runtime on any cluster, learn what agents need, and later move to the managed service for the Gemini-grade stack. Rivals will counter with their own managed sandboxes, and security vendors are already extending scans to agent-heavy clusters, as Microsoft Defender’s expanded EKS and GKE coverage https://shattered.io/microsoft-defender-cloud-eks-gke-container-security-2026/ shows. Market Impact for Platform Teams and Vendors The immediate winners are teams building coding agents and long-running research agents. They need isolated execution, they need it cheap while idle, and they have been stitching it together themselves. Teams shipping cloud agents like those built with Cursor https://shattered.io/build-cursor-cloud-agents-2026/ can see their own architecture reflected in Google’s design. Startups that sell sandbox-as-a-service face a tougher pitch. If a hyperscaler offers hardware isolation, checkpointing and identity as built-ins, a standalone sandbox vendor must win on neutrality, developer experience or price. Open-source Agent Substrate adds pressure from below, since it costs nothing to license and runs anywhere Kubernetes does. Google’s week also included other infrastructure news. It reportedly announced a partnership with Oracle to bring Google TPUs to Oracle Cloud Infrastructure and introduced a VMware solution on Google Cloud, both on October 27. Each reaches a different buyer, but together they show Google courting enterprises that refuse to pick a single stack, the same buyers Agent Substrate’s portability pitch targets. Storage vendors gain a quieter benefit. Checkpointed agent state has to live somewhere, and fast snapshot restore pushes architects to compare options in the same way they compare S3, Azure Blob and Google Cloud Storage https://shattered.io/s3-vs-azure-blob-vs-gcs-2026/ for other workloads. Readers tracking the wider shift can browse more cloud computing coverage https://shattered.io/category/cloud-computing/ . Five Predictions for the Next Six Months These are analyst judgments, not reported facts. - Preview arrives before general availability, and pricing lands with it. Preview programs for services a vendor already runs at scale usually come with a rate card, and this one probably will too. - Usage-based billing wins. The Gemini platform meters already point toward per-vCPU-hour and per-GiB-hour pricing with a free monthly allowance. - Rivals announce managed agent sandboxes. The Futurum framing of a parity test suggests competitors will feel pressure to answer in public. - Independent benchmarks challenge the 10x claim. Vendor-run tests rarely survive contact with varied workloads unchanged. - Credential separation becomes a checklist item. Security questionnaires will start asking whether agents hold backend secrets, and vendors without a clean answer will lose deals. What Platform Teams Should Do This Quarter Start with an inventory. List every agent in your organization, the credentials each one holds, and the systems it can reach. Most teams discover agents holding broad tokens that no one reviewed. Fixing that costs nothing and pays off whichever Google product you eventually pick. Next, run a contained pilot of Agent Substrate on a non-production GKE cluster if you already operate one. Enforce admission policy with a tool such as Kyverno https://shattered.io/kyverno-kubernetes-pod-security-2026/ so sandbox pods cannot request privileges they should never need. Measure resume latency under your own workload, not Google’s. Finally, wait on the managed service. Ask your Google Cloud account team for preview access, supported regions and billing meters in writing. Without those three answers, any business case for Agent Compute Engine rests on assumptions. Frequently Asked Questions What is Google Agent Compute Engine? It is a managed Google Cloud service announced October 22, 2026, that runs each AI agent in its own hardware-isolated microVM with dedicated identity, networking and checkpointing. Google says it already powers the Gemini agent. Is Agent Compute Engine available now? No. Google says a customer preview is planned for the coming months and has given no firm date. The service is not generally available. What is Agent Substrate on GKE? It is an open-source, Kubernetes-native runtime for running isolated AI agents. It runs on any Kubernetes cluster, is optimized for GKE, and supports harnesses including Claude Code, OpenClaw and Hermes. How do the two products differ? Agent Compute Engine is the managed service that Google operates. Agent Substrate is open-source software your team operates. Google positions the first for convenience and the second for customization and multi-cloud portability. Do the 10x density and 200,000-agent numbers apply to Agent Compute Engine? No. Per TokenPost’s reading of the announcement, those figures describe Agent Substrate. Google has published no equivalent benchmarks for the managed service. How much does it cost? Google has published no price for either product in its launch materials. A Gemini platform pricing page reportedly lists agent compute meters, but it is unconfirmed that Agent Compute Engine will use them. Does isolation stop prompt injection? No. MicroVM isolation and credential separation limit what an attacker can reach after hijacking an agent. They do not prevent the agent from being manipulated in the first place. Should teams adopt Agent Substrate in production? Not yet for most. It is open to GKE customers for non-production workloads, and production support runs through an allowlist. Pilot it first and benchmark resume latency on your own workload.