Google DeepMind pitches one API for agent state and remote sandboxes

Google DeepMind’s Ivan Leo has outlined the Interactions API and Managed Agents, tools designed to preserve context and run coding agents in persistent remote sandboxes. The practical pitch is less state-management plumbing for developers building agents, with credential handling kept outside the model’s view, according to Leo’s presentation.

Google DeepMind Watch analysis

What happened

Leo, a member of Google DeepMind’s developer-experience team, described the two offerings in a 17-minute talk covered by BigGo’s episode page. The Interactions API uses an interaction ID to carry context across turns, including multimodal work; Leo said developers no longer need to manage Gemini’s thought signatures manually. A new typed steps model replaces the older outputs array.

Managed Agents provide a persistent remote sandbox through an API call. Developers can return to the same environment using its ID, load files from GitHub or Google Cloud Storage, and package locally tuned skills for cloud use. Leo also described a proxy that injects credentials into outbound requests so the model does not receive the underlying token. These are capabilities as presented in the talk, not independent security test results.

Our top picks

• Interaction IDs carry context across turns
  Pass the ID back to preserve context, including across multimodal calls, rather than manually stitching state together.
• Typed steps make outputs clearer
  The replacement data model labels generated content, tool calls and thought signatures by type.
• Managed Agents keep a sandbox alive
  An environment ID routes later requests back to the same remote workspace, with its files and installed packages.
• A proxy keeps credentials out of model context
  Leo says outbound requests can have credentials injected by a proxy instead of exposing tokens to the agent.
• Local skills can move to the cloud
  Developers can package Antigravity skills and files for use with a remote Managed Agent.
• The stated pricing charges for model use
  Leo said developers would not pay for sandbox storage, and that up to 1,000 named agents are supported.

Why it matters

Agent builders often end up writing the machinery around the model: preserving context, provisioning a sandbox and managing credentials. Google’s proposal is to take on more of that work behind a unified interface. That could make it quicker to move from a local agent prototype to a persistent cloud workflow, while interaction IDs and environment IDs keep conversational state and execution state distinct.

There is also a migration implication. Leo said new models will be available through the Interactions API, making it more than an optional convenience for developers committed to Gemini. The talk gives a concrete account of the intended tools and terms, but not an independent assessment of their reliability or security.

Our read

This is a substantial attempt to sell the scaffolding around agents, not just another model endpoint. The most useful idea is the separation of interaction state from sandbox state; the credential proxy is the feature that deserves the closest scrutiny before anyone hands an agent access to sensitive systems. Developers should check the current documentation and test their own workflows before treating the talk’s limits and pricing as settled.

What to watch

• Whether Google publishes current documentation for the Interactions API and Managed Agents.
• How the API migration affects developers using existing Gemini endpoints.
• What controls, logging and independent testing are available for the credential proxy.
• Whether the stated named-agent limit and sandbox pricing remain current.

Discussion spark: Would you trust a managed agent with access to your code if credentials were injected by a proxy, or would you insist on running the sandbox yourself?

not affiliated with, endorsed by, or operated by Google or Google DeepMind