Agent Compute Engine: Google claims 10x density, but no pricing or boot time published
Google Cloud launched Agent Compute Engine on October 22, 2026, a service that gives each AI agent its own hardware-isolated micro-VM with no standard network interface and not a single backend credential inside the sandbox. The service is already running internally for Google's own Gemini agents — but every performance figure circulated so far applies to its counterpart Agent Substrate, openly available on GKE, not to ACE itself, and no boot time, density, or pricing has been published for the service customers will actually get.
The news
At the AGNTCon + MCPCon conferences on October 22, 2026, Google Cloud launched Agent Compute Engine (ACE), a compute service that, according to the company, gives each AI agent its own hardware-isolated micro-VM with "container speed and zero credentials held inside the sandbox" (Google Cloud blog). The post was authored by Google Distinguished Engineers Ramanathan Venkatapathy and Rohit Jnagal.
Two things distinguish the launch from a mere announcement: the service is already running in production internally at Google, where, according to the company, it powers Gemini as an agent for work tasks, and a customer preview is announced "in the coming months" — with no fixed date.
Its counterpart, Agent Substrate, has moreover been available on GKE since September 15, 2026. That is where all the figures Google has published belong — a distinction easy to lose in the flood of coverage, but crucial for what has actually been independently verified.
Why Google claims a new format is needed
Google's motivation, so far advanced only in the company's own words, rests on two claims that neither VMs nor containers fit agent traffic:
- VMs are too slow. "Each VM boots and configures an entire machine, so starting, suspending, and resuming one takes seconds to minutes. Agents start, pause, and resume constantly, so the overhead piles up," Google writes in the blog post. Agents constantly shift between activity and rest, and the startup cost multiplies.
- Containers are too leaky. Containers, according to Google, lack full isolation and kernel- and root-level control — a problem when the sandbox's job is to run code, shell commands, and browsers that the model requests.
The surrounding frame, according to Google, is that "agentic workloads have grown to become one of the fastest-expanding consumers of compute and storage in our fleet," and that traditional compute primitives cannot run hundreds of millions of agents at the required cost and latency. These are company statements about its own fleet, not measurements independent parties can verify.
The "brain" outside, the "hands" inside
Google's split of each agent into two parts is the core of the security model. "The harness, or 'brain,' calls the model and decides what to do next. The sandbox, or 'hands,' runs the code, shell commands, and browser the model requests," the blog post explains. Crucially, the brain sits outside the sandbox — which is why the hands can be kept entirely without credentials.
The network where there is no network
ACE's micro-VMs, according to the technical walkthrough, have no standard network card, no default gateway, and no direct VPC access. Instead, all traffic crosses a virtio-vsock boundary — a host-local channel — to a local proxy and then to an external gateway (MarkTechPost).
That is where the central trick happens: the guest holds only a session-scoped SPIFFE certificate and a short-lived identity token. The Agent Gateway swaps in the real backend credentials in flight, after policy checks have been performed. In other words: even if an agent exfiltrates everything it can see internally, the attacker gets, by design, only an identity valid for a single session in a single sandbox — not a key into the backend systems.
Four identities per agent
The identity model has four tiers per agent workload: the user's identity, a delegated on-behalf-of identity, a short-lived Agent Workload Identity used for sandbox traffic, and an Agent Workforce Identity. The walkthrough's wording is concrete: "The workload identity is worthless for direct API calls if exfiltrated. It only identifies which sandbox sent a packet." This is Google's own design premise — and precisely for that reason it is a claim that should be tested, not merely believed.
The numbers — and what they actually apply to
Google has published benchmark figures, but they apply to Agent Substrate on GKE, not to ACE itself:
- Up to 10x higher compute density than traditional compute
- 500 activations per second with under 500 ms suspend/resume, measured in a benchmark with 200,000 agents
- Over 1,000 sleeping agents per host
All of these figures are Google's own, not independently verified, and the two secondary sources trace back to the same announcement. For Agent Compute Engine itself, no boot time, density, or pricing has been published — MarkTechPost sums up the gap directly: "No published boot time, density, pricing, or preview date for Agent Compute Engine itself."
The technology positioned as the basis for the density and security claims is copy-on-write memory sharing (sleeping agents share memory instead of holding their own copies) and Titanium IPU technology for security (Crypto Briefing). Google claims, among other things, that the copy-on-write approach delivered the 10x density benchmarks — but this too is the company's own statement. In Agent Substrate on GKE, the isolation options are Cloud Hypervisor micro-VMs or gVisor sandboxes.
What remains before the numbers can be taken as final
Several central questions remain open:
- No independent benchmarks. All performance figures come from Google itself, about a product (Agent Substrate) that is related to, but not identical with, what customers will get access to.
- No customer voices. ACE runs at Google itself, but no external customers have described their experience.
- Vague preview timeline. "Coming months" is the extent of the precision available.
- Unknown pricing. Without price figures, the density claims are hard to translate into cost savings.
- Outstanding mechanics. The details of checkpointing sleeping agents and the full network internals are so far known primarily through secondary summaries of Google's technical post.
The concrete things to watch for: the customer preview (which will make independent measurements possible), published ACE-specific figures for boot time and density, and a pricing model. Until then, Google's zero-credentials architecture is a well-documented design — and the claims about speed and density remain the company's word against its own product.