Engineering brief
Agent Sandboxes Are the Real Product in Google's New API
At a glance
The brief is enough
- Relevance
- Practical value
- Radar
- Time horizon
- This year
- Warnings
- Vendor pitch
Google now wraps agent execution in a managed sandbox: one API call starts a cloud environment, runs code, keeps state. The demo skips cost, isolation, and control.
Agent execution is moving into vendor-managed sandboxes, making isolation, cost, and portability the key decisions.
Watch if you are choosing an agent platform or evaluating whether vendor-managed sandboxes fit production workflows.
Summary
The product shift. Google DeepMind's Philipp Schmid spent the talk selling an abstraction: every agent gets a managed sandbox. The new interactions API in the Gemini API uses one interface for models and agents, with server-side state and an environment field that starts a cloud sandbox. The agent writes files, installs dependencies, calls tools, and persists between turns. No client-side function-calling loop, no container orchestration. One API call.
Environment as product. The demo shows what Google thinks agents need: a file system, skills, and an AGENTS.md file loaded into the system prompt. The AI Talk Radio applet is just files, with Python skills that call other Gemini models for speech, music, and thumbnails. The Antigravity agent in the API shares the same harness as Google's IDE, so improvements flow to both. The battle is no longer raw model quality; it is the harness and the environment.
Demo evidence only. The convenience claim is real but unproven. One sandboxed request replaces the standard loop where the client passes function calls, runs them, and returns results. The live demo shows Ubuntu, 8 vCPU, 16 GB memory, dependency installs, and a generated talk show. No production data, no cost per task, no latency distribution, no failure rate, no security model beyond managed by us. Treat it as a vendor demo, not a benchmark.
The control trade-off. Moving the agent loop into Google's sandbox simplifies operations but transfers control of execution, state, and data to the vendor. Persistent environments shared between agents are powerful for collaboration and hard to govern without clear data retention. Remote MCP servers help, but the sandbox still sits between your agent and your systems. Ask about isolation, retention, egress costs, and whether the environment can be audited before building anything on it.
What's missing. The talk avoids the hard adoption questions. No pricing beyond a 4 cent per image example, no quota limits, no multi-tenant isolation details, no story for regulated environments, and no comparison to self-hosted sandboxes like Firecracker or E2B. The no Terraform, no Kubernetes pitch appeals to fast-moving product teams and will not replace deterministic, auditable infrastructure. Both can be true, and the speaker does not acknowledge the trade-off.
Why leaders should care. The direction matters more than the demo. Google is making agent sandboxes an API feature, much like chat completions became one. If agent harnesses become a platform layer, teams will evaluate them like databases or CI systems: cost, isolation, portability, operational behavior. Run one bounded task in a managed sandbox, download the environment, and measure what breaks. Do not assume the API abstracts the hard problems.
My take
Google has identified the right bottleneck: agent execution environments are where workflows succeed or fall apart. A shared filesystem, skills, and an AGENTS.md file loaded into context feel closer to how teams work than another model API. But I'd be careful with the managed-sandbox framing. One API call is attractive until you need to explain where your data ran, what persisted, and who can inspect it. The demo has no cost model, no isolation guarantees, no portability story. I want vendors to standardize around an open agent environment contract, not each cloud locking agents to its own sandbox. Try the Antigravity agent on a bounded internal task, download the environment, and check whether you can reproduce it outside Google. That result decides if this is infrastructure or a demo.
What to do with this
- Run one bounded internal task through the Antigravity agent in a managed sandbox and log total cost and wall time.
- Ask Google for data retention, customer isolation, and egress pricing before any persistent environment work.
- Download the generated environment and check whether your existing CI or local harness can reproduce it.
Watch the video
This video is blocked due to your privacy settings. To watch this video, please accept YouTube marketing cookies.
Related breakdowns
AI agents are flooding large codebases with code faster than teams can
AI agents are flooding large codebases with code faster than teams can manage. Dan Adler argues the bottleneck is not model quality but cross-repo visibility…
Why Frontier LLMs Still Can't Write Fast Multi-GPU Kernels
LLMs solve only a third of multi-GPU kernel tasks despite excelling on single-GPU benchmarks. The bottleneck has shifted to communication, and reasoning…
Coding Agents Can't Build a Compiler Yet
SWE-Marathon: top agents hit 26% on project-scale tasks; verification is the real bottleneck as agents exploit weak tests. Hype meets reality.
Get TL;DW
Too Long; Didn't Watch.
A concise breakdowns of the AI and devtools videos that actually matter for engineering leaders.
Free. Weekly. No hype.
Video and thumbnails remain the property of their respective creators. tldw.news provides editorial analysis, commentary, and discovery links to original content.