As enterprises scale AI agents, Google is betting that idle infrastructure costs could become a major barrier to adoption. To address that challenge, the company on Thursday launched Agent Compute Engine, a service that suspends inactive agents and restores them on demand while preserving their execution state.
AI agents often spend long periods waiting for instructions, tool responses, or human approvals. While enterprises can reduce costs by shutting down the underlying compute resources, restarting agents typically requires rebuilding the execution environment and restoring context, adding latency. Google says its new Agent Compute Engine addresses that trade-off by preserving agent state in hardware-isolated microVMs that can be suspended and resumed on demand.
That choice of microVMs is intended to reduce the overhead associated with conventional virtual machines, which typically take longer to boot and require more resources to initialize, the company wrote in a blog post.
Additionally, microVMs offer stronger isolation than containers, which are commonly used by enterprises for running AI agents on shared infrastructure.
Unlike containers, which share the host operating system’s kernel, microVMs run their own kernels, providing a stronger isolation boundary for agents executing AI-generated code or handling untrusted inputs, limiting the potential impact of compromised agents, the company added.
The ability to suspend and resume an agent’s computing environment swiftly will help CIOs save costs, at least for long-running coding and research agents that hold state for hours or days, said Amit Kumar Jena, AI development head at IT consulting firm Kanerika.
More so because traditional cloud compute was not built for long-running agents that activate thousands of times and otherwise sit idle, echoed Manoj Chandra Jha, principal analyst at Nord-IQ Research.
As agents move from pilots to fleets of thousands, idle compute cost when using traditional cloud compute can become a major binding constraint for a CIO, as it increases cost by a significant margin, Jha added.
For developers, that same ability to hold agent state while suspending and resuming a task can reduce the engineering overhead of maintaining long-running tasks, according to Jena. “It lets developers stop building their own save-and-resume layer. A lot of code that exists only to survive the goes away,” Jena said.
However, the new service comes with its own set of trade-offs, especially vendor lock-in, operational complexity, and uncertain cost savings.
Agent Compute Engine is closely integrated with Google Cloud, which could make it difficult for enterprises to move agent workloads to another cloud provider or run them across multiple platforms without reworking parts of their infrastructure, said Pareekh Jain, principal analyst at Pareekh Consulting.
That means enterprises could also become dependent on Google’s approach to managing agent state, identity, and execution environments, he added.
Further, the potential cost savings will also depend on how different agents use compute resources. Workloads with continuously active, compute-intensive agents are likely to see smaller gains, Jha said.
“CIOs should ideally count how many agents hold state across more than a few minutes of idle time. That number should decide whether they should care about the new engine,” echoed Jena.
The service’s maturity is another consideration for enterprises evaluating adoption, Jha said. The Compute Engine is not yet in preview, meaning enterprises would be betting on Google’s roadmap rather than proven production performance, he added.
The other issue, according to Jena, is the likelihood of an increase in storage costs.
Storage costs may rise because each microVM requires disk space to retain its working state, and at scale, storing thousands of persistent agent environments could add significantly to infrastructure bills, making it harder for finance teams to predict the net savings, Jena added.
The idea behind the service is not entirely novel.
“AWS has run a microVM per session in AgentCore since 2025 and stops billing CPU while the agent waits. Microsoft’s hosted agents in Foundry suspend between turns and keep the filesystem,” Jena said.
Google, however, is claiming a step beyond suspending an environment between tasks, with ACE’s checkpointing mechanism preserving memory and execution state so an agent can resume from where it left off rather than reconstructing its context and restarting execution, Jena added.
Even so, developers might face certain issues with the checkpoint feature, particularly when agents are interrupted while interacting with external systems.
“If the lands between an API call and its confirmation, the agent wakes up unsure whether the payment went through or the commit landed, and it tries again. Every external action has to be safe to repeat. Most agent code today isn’t written that way,” Jena said.
Developers could also face challenges around drift and debugging, Jena pointed out.
Agent environments that remain active over weeks can diverge from their original configurations as files, dependencies, and software versions change, making bugs harder to reproduce and the environment harder to audit, he said.
Therefore, developers would need to set expiry policies and periodically rebuild workspaces from fresh base images to maintain consistency, he added.
Debugging could become more complicated, too, because developers would need to inspect suspended virtual machines to diagnose problems that emerge after an agent resumes, and the tooling for debugging d environments is still relatively immature, Jena further added.