Why AI Agents Need Their Own Sandbox: A Deep Dive from a Google DeepMind Engineer

At the AI Engineer conference, Philip, an engineer from the Google DeepMind team, shared the latest progress on the Gemini API in agent architecture. His core argument was clear: every model and every agent should have its own sandbox environment. This isn't a nice-to-have feature — it's the critical infrastructure that lets agents evolve from "chat tools" into "autonomous executors."

From Text Continuation to Autonomous Agents: A Five-Year Paradigm Leap

Philip first reviewed the evolution of NLP model capabilities. In 2018–2019, what excited the industry about BERT and early GPT models was "text continuation" — give the model a few words and it could generate a coherent poem. But this had limited use in real products. Next came the instruction-following stage, where models learned to answer questions. ChatGPT brought the turn-based conversation paradigm, with user input and model output alternating. After that, function calling let models invoke external tools to perform actions.

Now we're in a new stage: give the model a goal, tell it how to verify results and how to deploy, then let it run autonomously for hours or even days. This "goal-driven + thinking + function calling" black-box model demands fundamental changes to the underlying infrastructure. Models are no longer just passively responding — they're actively planning and executing.

Function Calling is the key technology that lets large language models cross from "can only generate text" to "can produce side effects." The basic flow is: the developer attaches a set of function signatures (function name, parameter schema, description) when calling the model. During inference, if the model determines it needs external information or an action, it outputs a structured call request (e.g., {"name": "search", "arguments": {...}}) instead of ordinary text. After the developer (or the runtime) executes that function, the result is passed back to the model as a new message, and the model continues reasoning. It matters because the model itself has no access to real-time data, databases, or the operating system — function calling is essentially giving the model "hands." Compared with traditional plugin approaches, function calling lets the model decide on its own when to call and with what arguments, without needing an external intent-recognition module, so it naturally fits the "goal-driven" paradigm of agents. It's also the prerequisite capability that makes later environment interaction and sandbox execution possible.

Interactions API: An Interface Redesigned for the Agent Era

Google's Interactions API can be understood as a response to OpenAI's Responses API, but it's more developer-friendly. Its design philosophy is: whether you're calling a model or an agent, the interface is completely identical. You provide input (which can be a string or multimodal data), specify tools or an environment, and then get results.

The API introduces several key capabilities. Server-side state management means developers no longer need to maintain conversation history on the client — when sending new input, they just attach the previous turn's ID, and the server automatically stitches together all history. Long-running operations support an async request mode: send a request, get an ID, then wait via streaming or polling for time-consuming tasks like video generation to complete.

According to Philip, the new API also greatly simplifies tool usage. Built-in tools (like Google Search and URL context) can be freely combined with custom function calls, and the model decides on its own whether to search first or call a function first. He demoed on stage building an agent to detect React CVE vulnerabilities in just a few lines of code — the model itself decides when to use Google Search, when to visit a URL, and when to produce structured output via function calls.

Farewell to the user/model Binary: The Synchronized Timeline Model

The Interactions API has a notable design decision: it abandons the traditional user/model turn concept. Philip explained that in the old API paradigm, function call results had to be returned under the "user" role, which is logically awkward — because the function output actually comes from the environment, not the user.

As agents and reasoning capabilities advance, a model may think for a long time, may expose part of its chain of thought, or may expose only a signature. In such cases, the strict user/model binary no longer applies. The new API adopts the concept of "steps" or a "synchronized timeline," where each action or generation is an independent type. A function call result is simply the "function result" type, rather than masquerading as a user message. This design makes future extension of new capabilities much more natural.

Remote Sandbox: The Agent's "Workbench"

This is the most central part of Philip's talk. Google introduced an environment: remote field in the Gemini API — when a developer sends a request, the backend automatically spins up a cloud sandbox. In this sandbox, the agent can run code, create and write files, install dependencies, install custom tools, and call external APIs.

Several key features are worth noting. The sandbox is persistent: across multiple turns of conversation, subsequent interactions can reuse the same environment. The sandbox can be shared: multiple agents can work in the same environment, sharing context through the filesystem, and a sub-agent can pick up work another agent left unfinished. This means you can build a multi-agent collaboration system where agents work together around the same set of file artifacts.

The sandbox also supports injecting "sources," including GCS buckets, GitHub repositories, or inline files. If a skills directory or an agents.md file exists in the environment, the system automatically incorporates it into system instructions. Philip emphasized that the anti-gravity agent is itself filesystem-native — code is the config file, and copying a single file lets you migrate from the UI to a backend deployment.

Sandbox here refers to an isolated, temporary or persistent compute environment, typically implemented with container or lightweight VM technology, equipped with a filesystem, process space, and network capabilities. Its core value lies on two levels. The first is security isolation: code generated by agents can't be trusted — if executed directly on the host environment, it could delete files, read secrets, or launch malicious requests; the sandbox confines risk within its boundaries via namespaces, cgroups, or microVM boundaries. The second is state persistence: ordinary containers are destroyed after a session ends, but agent tasks often span multiple rounds of interaction and need to retain installed dependencies, downloaded data, and intermediate artifacts — hence the need for persistent volumes or environment IDs that can be mounted, snapshotted, and reused. Injecting "sources" like GCS buckets and GitHub repositories essentially mounts external resources into the sandbox as read-only or writable, giving the agent operable context. Multiple agents sharing the same sandbox further turns the filesystem into a medium for collaboration.

Agents API and Environment as Code

On top of the sandbox, Google built the Agents API. The core idea is to define an agent's configuration (underlying model, instructions, environment) as a reusable, shareable entity. An environment can be raw (with source files) or can be an existing agent or existing environment.

Philip used a practical scenario to illustrate its value: suppose you need an agent to install the GitHub CLI, add specific skills, and run some health checks. You can have the agent create this environment itself first, and once done, get an environment ID. From then on, every time you call a new agent, it starts from this pre-configured environment. The whole process requires no writing Terraform, no worrying about Kubernetes, microservices, or Firecracker.

To make it easy for coding agents to operate this system too, Google also released the Gemini API CLI — note this isn't a coding assistant, but an API tool for your coding assistant to call. It can generate media assets, create agents, and iteratively refine agents.

Environment as Code borrows from the idea of Infrastructure as Code (IaC). Traditional IaC uses declarative files like Terraform and Kubernetes YAML to describe servers, networks, and dependencies, and a toolchain then converges to the target state. Here, the object of description shifts from machines to an agent's runtime environment: the underlying model, system instructions, available tools, source files, and skills directories are all declared as versionable, replicable entities. The difference is that IaC configurations are typically written and maintained by humans, whereas "Environment as Code" lets the agent generate and commit this configuration itself — Philip's demo of "first letting the agent create the environment, then reusing the environment ID" is exactly this shift. The practical benefit is that developers don't need to directly touch underlying primitives like Kubernetes, microservice orchestration, or Firecracker; the operational complexity is encapsulated within the API abstraction layer.

Live Demo: AI Talk Radio and Sandbox Exploration

Philip showed two demos. The first was AI Talk Radio — a talk-show generator powered by Managed Agents. He asked the agent to produce an episode about "whether pineapple belongs on pizza." The system starts an environment, automatically installs Python dependencies, reads skill files, and then begins researching, writing scripts, generating music and speech, and mixing the output.

You may not have noticed, but this isn't a simple podcast reading. The generated show features multiple "call-in listeners" debating each other, with a host threading it together, presenting real conversational tension. This app is freely available in AI Studio's Gallery, and users can remix it.

The second demo was more technical. In the Playground, Philip selected the anti-gravity agent and asked it about its runtime environment. The agent executed bash commands in sequence to check system information and returned: Ubuntu system, 8 vCPUs, 16GB memory, Python and pip installed. He then asked whether Node.js was available, and the agent continued checking in the same sandbox. The entire agent loop is completed server-side — the developer only needs a single API call.

Why This Matters

From a broader perspective, the sandbox environment solves the core obstacle to deploying agents. Without a sandbox, an agent's "execution capability" can only be limited to calling a constrained set of external APIs; with a sandbox, the agent gains a complete compute environment and can install tools, write code, debug errors, and produce files just like a human engineer.

One line from Philip captures the essence: in the past, building agents often required managing function calls on the client — passing the call request, executing it somewhere, then passing back the result. With managed agents and remote sandboxes, everything happens in a single API call.

The trend behind this is: competition in AI infrastructure is shifting from "model capability" to "runtime environment." Whoever can provide a safer, more persistent, and more easily shared agent sandbox will own the gateway to the next generation of AI application developers.

Runtime Environment in traditional software refers to the host conditions a program depends on to execute — the operating system, language runtime, dependency libraries, and resource quotas. In the agent context, it takes on new meaning: it's not only where code executes, but also where the agent observes the world, leaves traces, and collaborates with others. Model capability determines "how smart an agent can think"; the runtime environment determines "how much it can do." As model capabilities gradually converge (the gap between flagship models on benchmarks is narrowing), a persistent, shareable, and auditable runtime becomes a source of differentiation. That's why Google, OpenAI, Anthropic, and others have shifted their engineering focus over the past two years from pure model training to agent runtime — it directly determines which company's API developers use to build next-generation applications, and is therefore seen as the new gateway-level infrastructure.

One-line Summary

Google DeepMind launches the Interactions API and remote sandbox, upgrading agents from chat tools to autonomous executors.

Paragraph Summary

At the AI Engineer conference, Google DeepMind engineer Philip shared progress on the Gemini API's agent architecture, with the core claim that every model and agent should have its own sandbox environment. The article traces the five-year evolution of NLP models from text continuation and instruction following to multi-turn dialogue, function calling, and goal-driven autonomous execution, noting that the underlying infrastructure must change accordingly. The new Interactions API unifies the calling interface for models and agents, supports server-side state management, long-running async operations, and built-in tool composition, while abandoning the user/model binary in favor of a synchronized-timeline step model. The most critical innovation is the remote sandbox: persistent, shareable, and capable of source injection, where agents can run code, install dependencies, and collaborate on outputs. On top of it, the Agents API realizes Environment as Code, freeing developers from managing Kubernetes or Terraform. Live demos of AI Talk Radio and sandbox exploration confirm the system's combined capabilities.