En 30 segundos
Jack Wotherspoon, a developer experience engineer at Google DeepMind, presents managed agents as a way to run coding agents in cloud sandboxes instead of on a developer’s laptop. The Gemini API handles the sandbox and Antigravity harness, while the Interactions API manages agent turns and environments preserve files between agents. Teams can add tools, skills, repositories, and scheduled triggers without building the infrastructure themselves. Wotherspoon walks through credential isolation and a workflow in which a filing researcher passes saved metrics to a quant agent and then a report writer. He closes with a financial research app built from managed agents and shows how the same pattern can be embedded in products.
- 1Managed agents run coding agents in cloud sandboxesInstead of running an agent harness on a personal machine, a developer can call an agent that works in a managed cloud environment. It can write code, research, run tests, and return results without taking over the developer’s laptop.
- 2Cloud sandboxes isolate work and scale beyond a laptopA sandbox can run research and verification without disturbing local tools. Managed environments also make it easier to share a team’s setup or incorporate agents into an application without depending on an individual’s computer or subscription.
- 3One API call replaces much of the setup workBuilding a cloud agent yourself can require provisioning a VM or container, preparing the environment, engineering a harness, and configuring networking and security. Gemini Managed Agents package those pieces behind an API call.
- 4Interactions and environments hold different kinds of stateInteractions carry the conversation and reasoning turns; environments preserve the sandbox filesystem. A later agent can start with a fresh context while reusing files created by an earlier agent.
- 5Secrets stay outside the sandboxAn egress proxy places a dummy token in the sandbox and injects the real credential only when a request goes to an allowlisted service. The agent can use an API without seeing or extracting the secret itself.
- 6Specialized agents can hand work through a shared workspaceIn the demo, an SEC researcher saves company metrics, a quant agent reuses that environment to analyze them, and a report writer turns the results into a memo. Each agent has a narrower task and can start with fresh conversational context.
Conclusiones
- Run agents in cloud sandboxes when you need isolated work, shared setups, or capacity beyond one laptop.
- Managed agents package the sandbox and harness behind an API call, reducing the infrastructure work needed to run agents at scale.
- Keep conversation history and filesystem state separate so a new agent can reuse prepared files with a fresh context.
- Store credentials outside the sandbox and let a proxy inject them only for allowlisted service calls.
- Break larger workflows into specialized agents that hand off files and results through a shared environment.
Lee la transcripción completa por capítulos
What managed agents are
Wotherspoon defines cloud or managed agents as coding agents that run in a sandbox instead of on a developer’s machine. They can research, write code, run tests, and return verified results.
I’m Jack Wotherspoon, a developer experience engineer at Google DeepMind, and I’m going to talk about managed, or cloud, agents. Instead of running a coding-agent harness on your own machine, you can run the agent in a sandbox in the cloud.
A cloud agent can write code, reason, research, search the web, write and run tests, and return with verified results. That work stays away from your local machine, so it does not take over your browser or trigger pop-ups while you are trying to work.
Why run agents in the cloud
Cloud sandboxes isolate work from a personal laptop and make it easier to share an agent setup with colleagues or use it inside an app. Managed agents also scale better than relying on one person’s machine.
A laptop also does not scale well. You may have customized an agent or built useful skills, but sharing that setup with a colleague or integrating it into an application is harder when everything depends on your machine or personal subscription. Managed agents make it easier to scale the work.
From infrastructure setup to one API call
Running agents yourself means managing a VM or container, preparing files, building a harness, and setting network and security rules. Gemini Managed Agents handle much of this infrastructure behind a single API call.
Building a cloud agent yourself is tedious. You need to start a container or VM, load the right files, manage it, engineer a harness, and configure networking, firewall rules, and security. Gemini Managed Agents package those pieces in the Gemini API so the workflow can begin with a single call.
With that call, you get a sandbox and the Antigravity harness already set up. As an application needs more agents, you can make more API calls instead of managing the underlying infrastructure and scaling it yourself.
The Interactions API
The agent-focused Interactions API represents multi-step work such as writing files and calling tools. An agent can be configured to run remotely in a managed environment.
The Interactions API is Google’s agent-focused SDK and client interface. Earlier model APIs centered on giving a model input and receiving output; agents need to take multiple steps, write files, and call files or MCP tools. The Interactions API is designed to represent that work.
To run an agent in the cloud, the call uses the Antigravity agent and sets the environment to remote. That setting tells the system to create a managed agent rather than run the work locally.
How the managed-agent system works
The Gemini API provides built-in tools and can call custom functions or MCP servers, while a sandbox runs on Google Cloud infrastructure. The environment can receive files, skills, repositories, and other setup.
Under the hood, a request goes through the Gemini API, which provides server-side tools such as Google Search and filesystem operations. Developers can add their own functions or MCP tools, while a sandbox runs on Google Cloud infrastructure.
When the managed-agent call arrives, the service spins up the sandbox. You can upload files into it, including agent skills, an AGENTS.md file, or a GitHub repository to load when the environment starts.
The building blocks
Wotherspoon describes the Antigravity harness, a persistent environment, skills, credentials, and triggers. These pieces define how an agent plans work, accesses files and services, and runs on a schedule.
The first building block is the Antigravity harness, which decides how to plan work and call tools. The environment is a separate persistent workspace: one agent can create files there, and another can later pick up that same environment and continue.
Skills let a team upload its playbooks or repeatable instructions. Credentials let the service provide tokens or MCP OAuth access to services. Triggers add scheduled runs, such as an agent that analyzes information before the market opens or checks a team’s Jira board each morning.
Choosing a model for the workflow
Teams can change the model used by an agent, selecting a faster model for efficient tasks or a more capable one for deeper analysis. Wotherspoon highlights Gemini 4 Argon and its long-output support.
You can choose which model the harness uses. A faster, more efficient model may suit a simple workflow, while deeper reasoning or financial analysis may call for a different model. Wotherspoon points to Gemini 4 Argon, which he says launched the previous day, and recommends testing it for financial and document-analysis tasks.
He also highlights long decode for Gemini 4. Rather than treating the output limit as a fixed 64K tokens, the one-million-token context budget can be shared among input, thinking, and output. That can support long outputs such as extensive mathematical reasoning or financial models.
Separate interaction history from environment files
Interactions hold conversation turns, while environments hold the sandbox filesystem. A second agent can reuse the first agent’s files with a fresh context, enabling multi-agent handoffs.
Interactions and environments are two separate stateful resources. Interactions preserve the conversation history and reasoning turns; an environment preserves the files, data, and packages in the sandbox. Passing an interaction ID continues a conversation, while passing an environment ID reuses the workspace.
That separation enables a handoff: one agent can collect quarterly filings and save them, then a second agent can start with a fresh context window but reuse the same workspace. It can fetch annual reports, analyze the files, and save its own results for the next agent.
Tools, files, and reusable agents
Managed agents include code execution, file operations, and Google Search, and can connect remote MCP services. Teams can mount skills and repositories, then save a refined agent configuration for later use.
Managed agents come with tools for code execution, reading and writing files, and Google Search. They can also connect remote MCP servers, bringing in services that support daily tasks or features inside an application.
You can mount files in the workspace, such as AGENTS.md, skills, and a GitHub repository. That lets an agent follow the same playbooks you use on a personal machine, while keeping its work in a reproducible cloud environment.
After refining an agent workflow, you can save it through the Agents API and call it again by its agent ID. That makes a tested setup reusable across multiple runs.
Credentials, triggers, and multi-agent workflows
A proxy injects credentials outside the sandbox, and scheduled triggers can run agents on a recurring basis. Specialized agents can call one another and pass work through files in a shared environment.
Secrets never enter the sandbox. A proxy sits between the sandbox and external services; the agent sees a placeholder token, not the real GitHub or API credential. When it calls an allowlisted service, the proxy injects the secret into the outbound request, so the agent cannot inspect or exfiltrate the key.
Triggers can schedule an agent to run, for example, to prepare a daily market briefing or scan email before the day begins. Managed agents can also call other managed agents, letting specialized agents handle a narrow task and hand files to the next step.
Demos and getting started
A filing researcher, quant analyst, and report writer collaborate on an Nvidia analysis by reusing one sandbox. Wotherspoon then shows a managed-agent app that creates a financial report and points viewers to AI Studio.
In the first demo, an SEC filing researcher gathers information about Nvidia and saves metrics to a shared environment. Step traces show its function calls and file operations, so a team can inspect what the agent did and improve the workflow.
A quant agent then reuses that environment, reads the saved metrics, runs Python analysis, and prepares a forecast. A third agent can take the research and analysis and turn them into a report; with the right MCP servers, the final step could also write to Google Docs or send a Slack message.
Wotherspoon next shows how a managed agent can be built into an application. In the demo, an agent connects to company receipts in Google Drive and uses a skill to turn the data into an interactive financial summary.
The same approach can turn a personal coding-agent workflow into a managed agent that runs for a company or inside an app. Google’s Gemini API and AI Studio gallery already include examples for creating games, researching documents, and other tasks.
He opens a financial research example in AI Studio. The app takes a stock ticker and uses several managed agents to gather and analyze information, while the interface can show the steps as the agents work.
The agents synthesize their findings into a report with analysis, takeaways, charts, and links to source documents. Wotherspoon points viewers to AI Studio and the managed-agent documentation as places to get started, then thanks the audience.
Más de este canal
20:55EN
18:27EN
17:56EN
35:19EN
20:58EN
18:31EN