Why AI Agents Need Their Own Computers
Google’s Agent Compute Engine and the infrastructure behind useful autonomy
Page 1
AI AGENTS AND INFRASTRUCTURE
Why AI Agents Need Their Own Computers
Google’s Agent Compute Engine and the infrastructure behind useful autonomy
23 October 2026 | BunCosmos Research Lab
A useful AI agent needs somewhere to put its work. An answer can live in a conversation,
but a finished assignment may involve a spreadsheet, a browser session, a collection of
downloaded documents and a script that has already run several times. Once an assistant
begins doing these things, the computer around the model becomes part of the product.
Google’s announcement of Agent Compute Engine on 22 October 2026 brings that usually
hidden machinery into view. The company says the service already supports its own
Gemini agent workloads and will enter customer preview in the coming months. It is a
computing environment for agents, rather than another foundation model. Its purpose is
to make their actions faster to start, easier to preserve and more tightly controlled.1
The significance is easiest to see through an ordinary request. Imagine asking an assistant
to examine a year of invoices, identify unusual charges and produce a report. Reading the
documents is only the beginning. The assistant may need to extract tables, compare
currencies, write calculations, check discrepancies and revise its conclusions. A
convincing paragraph is of little use if the underlying files disappear halfway through the
assignment.
From conversation to a working environment
An agent usually operates through a loop. A model receives instructions and information,
proposes an action, and receives the result when software carries out that action. The
surrounding controller decides which tools exist, how to interpret their outputs and
whether work should continue. Google’s technical account separates this controller, often
called the harness, from the environment that executes commands. Its design places the
harness outside the sandbox that runs code and browser activity.2
Some agents only need access to a few structured services. A full computing environment
becomes more useful when the assignment requires a browser, a filesystem or the ability
to run unfamiliar code. The case for a private workspace therefore depends on the work
the application is meant to perform.
That separation helps explain why model capability alone cannot determine reliability. A
very capable model can still encounter a missing file, an expired connection or a tool with
excessive permissions. Conversely, a well-designed application can prevent an otherwise
BunCosmos Research Lab | buncosmos.ai 1
Page 2
BUNCOSMOS RESEARCH LAB
plausible action from reaching a sensitive system. The quality of an agent therefore
depends on the relationship between reasoning, execution and permission.
For the invoice example, a durable working environment would hold the original
documents, the extraction results and the calculation script. The user could ask why a
charge was flagged and the assistant could return to the relevant evidence. This does not
make the conclusion automatically correct. It makes the work available for inspection,
correction and continuation.
A private workbench on a shared machine
Cloud services must fit many customers onto physical hardware without allowing their
work to interfere. Containers are a familiar way to package software with its
dependencies while sharing an operating system kernel. Their efficiency has helped make
modern cloud applications practical, but sharing that kernel is an important part of their
security model.3
A virtual machine provides a different boundary: software runs inside a guest operating
system separated from the host by a virtual machine monitor. Cloud Hypervisor, the open
project used in Google’s announced architecture, is written in Rust and concentrates on
modern cloud workloads with relatively little emulated hardware. Its design illustrates
how a virtual machine can be made lighter without abandoning the idea of a separate
guest environment.4
Google describes ACE as providing a hardware-isolated microVM for each agent session.
Its technical design also keeps persistent user credentials outside that environment and
mediates network access through proxies. These are architectural safeguards described
by the provider, rather than independent proof that every possible compromise has been
prevented.2
The practical purpose of isolation is containment. If an agent runs a defective script or
opens an untrusted file, the damage should encounter boundaries before reaching
another customer’s workspace or the wider host. Isolation creates a place where
imperfect software can operate with a smaller potential blast radius. Whether the
application should permit a particular action remains a separate question.
The surprisingly expensive problem of waiting
An agent’s computer is not busy every moment the agent appears active. It may be waiting
for a model response, a remote service or a human decision. Giving every waiting session
permanently reserved memory and processor capacity would make a large fleet
expensive. Destroying the session instead creates another problem: reconstructing it can
erase useful state and delay the next step.
BunCosmos Research Lab | buncosmos.ai 2
Page 3
BUNCOSMOS RESEARCH LAB
Google’s related Agent Substrate runtime addresses this lifecycle by saving idle
environments and returning their computing resources to a shared pool. When work
resumes, the saved environment can be restored. The open runtime was announced for
Google Kubernetes Engine on 15 September, before the October ACE announcement. It
can run on Kubernetes beyond Google’s cloud.5
The October announcement attributes a benchmark involving 200,000 agents, 500
activations per second and suspend or resume latency below 500 milliseconds to Agent
Substrate. These are company-reported infrastructure measurements for that runtime,
rather than an independent demonstration that ACE can successfully complete 200,000
simultaneous business assignments.1
This distinction matters because an activation is an event in a computing system. A
completed assignment is an outcome for a user. An environment can wake quickly and
still run an agent that misunderstands a document. Infrastructure measurements
establish part of the experience; they do not measure the whole experience.
Identity is not the same as permission
Software needs a dependable way to establish which running process is making a request.
The SPIFFE standards describe identities for workloads and documents that allow other
systems to verify those identities. A workload here means a running piece of software,
rather than a person logging into a website. This allows security decisions to follow the
software that is actually communicating.6
Knowing an agent’s identity is only the beginning. An organisation must also decide which
services it may contact and what it may do there. Google’s Agent Gateway documentation
describes a policy enforcement layer for traffic entering and leaving agent systems. It
supports controls across connections between users, agents and tools, together with
telemetry that records interactions.7
The accompanying Agent Registry provides a catalogue of agents, tools, Model Context
Protocol servers and other approved components. A registry helps establish which
destinations belong in the organisation’s AI environment; the gateway provides a place to
enforce access decisions as requests pass through.8
Consider an assistant authorised to examine invoices but not to pay them. It may need
permission to read an accounting service and save a report. That does not imply
permission to alter bank details or release money. A trustworthy deployment has to
preserve this difference even when all of those functions happen to be exposed by the
same application.
Availability varies by deployment. As of 23 October, Google’s documentation lists Agent
Gateway support for GKE, Cloud Run and cross-cloud environments as forthcoming early
previews. The architecture should therefore be distinguished from the features customers
can already use.7
BunCosmos Research Lab | buncosmos.ai 3
Page 4
BUNCOSMOS RESEARCH LAB
Why a sandbox cannot solve every agent failure
Keeping credentials away from generated code reduces one route to credential theft. It
does not settle whether the agent has understood the user’s intentions. A malicious
document could still try to persuade the model to use an available tool incorrectly, or to
place information into an otherwise permitted outgoing request.
This is a well-established research problem. The AgentDojo benchmark, first published in
2024, evaluates agents using tools over untrusted data, including attempts to redirect
them through prompt injection. Its design treats successful task completion and resistance
to attack as related but distinct properties. That distinction remains useful when assessing
newer platforms.9
An invoice assistant, for example, could encounter a document instructing it to send the
report to an unfamiliar address. The application needs more than a secure computer: it
needs a defensible connection between the user’s request and the proposed recipient. A
record showing that an action occurred is valuable, but it cannot by itself establish that
the action was authorised.
These observations do not diminish the value of stronger infrastructure. They explain its
role. Isolation, identity, network controls, application permissions and human approval
address different failure paths. Their usefulness comes from how they work together, and
from whether the boundaries remain understandable to the people relying on them.
What the next stage must demonstrate
For customers, the unresolved questions are concrete. How quickly does an environment
return after a long pause? What happens when a service fails midway through a task? Can
permission be revoked while work is running? Does the activity record make a mistaken
action easy to reconstruct? How much does preserving a workspace cost over days rather
than minutes? These are evaluation questions, not claims that the announced service has
failed them.
Google’s October announcement establishes a direction and describes an architecture.
Customer preview and later deployment will provide opportunities to test that
architecture under different workloads. Comparisons will be most informative when they
include completed tasks, recovery behaviour, security testing and total operating cost
alongside startup speed.
The broader change is already visible. As assistants begin producing finished work, their
environments need many of the qualities expected of any serious workplace: continuity,
controlled access, records and recoverable mistakes. The computer behind an agent may
be less conspicuous than the model that speaks, but it increasingly determines whether an
ambitious request becomes something a person can actually use.
BunCosmos Research Lab | buncosmos.ai 4
Page 5
BUNCOSMOS RESEARCH LAB
Sources and further reading
Source links were checked on 23 October 2026. Dates distinguish current announcements from earlier research and technical documentation.
1. Google Cloud. Introducing Agent Compute Engine and expanded agent governance. 22 October 2026. cloud.google.com | Read source
Inside Agent Compute Engine: Building the compute foundation for the agentic era. 22 October
2. Google Cloud. 2026. cloud.google.com | Read source
3. Kubernetes. Containers. Documentation accessed 23 October 2026. kubernetes.io | Read source
4. Cloud Hypervisor. Project overview. Accessed 23 October 2026. cloudhypervisor.org | Read source
Agent Substrate brings high-density, scalable, trusted infrastructure to GKE. 15 September 2026.
5. Google Cloud. cloud.google.com | Read source
6. SPIFFE. SPIFFE Concepts. Documentation accessed 23 October 2026. spiffe.io | Read source
7. Google Cloud. Agent Gateway overview. Documentation accessed 23 October 2026. docs.cloud.google.com | Read source
8. Google Cloud. Agent Registry. Documentation updated 22 October 2026. docs.cloud.google.com | Read source
AgentDojo: A Dynamic Environment to Evaluate Prompt Injection Attacks and
9. Debenedetti and colleagues. Defenses for LLM Agents. First submitted 19 June 2024. arxiv.org | Read source
BunCosmos Research Lab | buncosmos.ai 5