Google’s Managed Agents Put Your Runtime in Google’s Cloud

Google’s Managed Agents, now in Public Preview, can give a Gemini agent a Google-hosted Linux sandbox. Google documents the default Antigravity agent as able to reason, run code, install packages, manage files, and browse the web there. The service manages the environment and its lifecycle, which makes it an agent runtime rather than just another model API.

That can remove a lot of infrastructure work from an agent product. It also moves more of the product into Google’s cloud. Depending on the configuration, Google’s managed service can provide the runtime, filesystem, network policy, stored interactions, and resume behavior instead of application code.

The July 2026 update makes that especially clear. With background execution, a developer can receive an interaction ID immediately while the agent continues working remotely. The client can poll for status, stream progress, or reconnect later. That resembles a managed job runner, not a stateless inference endpoint.

Google hosts the normal execution boundary

Managed Agents can use Google Search and code execution inside the sandbox. They can also connect to remote MCP servers, which expose tools and data to the agent. Custom functions are a meaningful exception: when the agent needs one, the interaction pauses and hands control back to the client. The client runs its own business logic and returns the result. That gives teams a place to keep payment approval, database writes, and other sensitive operations outside Google’s sandbox.

That division also limits what a remote tool can do. The agent requests the operation, while the application retains the authority to approve it and perform it locally.

A managed environment currently has four CPU cores and 16 GB of memory. Google snapshots and stops it after 15 minutes of inactivity. The environment remains resumable for seven days after its last activity, then Google deletes it.

Filesystem state, installed packages, and cloned repositories can persist across interactions during that period. Teams can refresh a short-lived OAuth token or API key without losing the working directory. They can also download a complete environment snapshot as a tar file. That is a real portability valve, but moving the workload would still mean replacing Google’s orchestration and lifecycle behavior.

Background work depends on stored server-side state

Interaction history has separate retention rules. Paid projects store interactions for 55 days by default and can choose automatic deletion after 7, 14, 28, or 55 days. Free projects keep them for one day. Setting store=false turns storage off, but it also disables background execution and prevents continuation through previous_interaction_id. Resumable background agents therefore depend on Google keeping that server-side state.

Networking follows the same pattern. Outbound access is unrestricted by default, although teams can restrict it to an allowlist or disable it entirely. Credentials can be injected through the egress proxy, and Google warns that an agent may use any credential it can access. Those are useful controls, but they are controls expressed through Google’s environment configuration.

Preview pricing leaves the runtime cost open

Managed Agents is attractive because it absorbs work that every serious agent product eventually creates: background jobs, persistent files, package installation, network rules, credentials, tool connections, and teardown. The tradeoff is not that a workload becomes impossible to move. It is that the normal operating boundary now follows Google’s runtime contract.

The cost picture is still provisional. Managed Agents is in Public Preview, and Google currently charges for Gemini tokens and tools but not for the environment itself. Its documentation says a single interaction typically consumes 100,000 to 3 million tokens across repeated reasoning loops. That range describes current usage, not a fixed allowance or a promise about future environment pricing.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com