Google Expands Managed Agents in the Gemini API: Background Tasks, Remote MCP, and More
Google added background execution, remote MCP server support, custom function calling and credential refresh to Managed Agents in the Gemini API, aimed at production-ready agents.
Google has announced a set of updates to Managed Agents in the Gemini API, addressing some of the practical friction developers hit when moving agents from prototypes to production. The changes were detailed in Google's announcement, authored by Philipp Schmid and Mariano Cocirio of Google DeepMind.
Managed Agents work through the Gemini Interactions API: you call a single endpoint, and Gemini handles reasoning, code execution, package installation, file management and web access inside an isolated cloud sandbox. The new capabilities extend what that sandbox can do and how it behaves over time.
Background execution for long-running tasks
Holding an HTTP connection open while an agent works is fragile, especially for tasks that take a while to complete. With the new background: true flag, interactions run asynchronously on the server. The API returns an ID immediately, and client applications can poll for status, stream progress, or reconnect later once the agent finishes remotely. This turns managed agents into workers that don't block the calling application.
Remote MCP server integration
Previously, connecting an agent to private databases or internal APIs meant writing custom proxy middleware. Now, managed agents can connect directly to remote Model Context Protocol (MCP) servers. Developers pass an mcp_server tool at interaction time, alongside built-in capabilities like Google Search or code execution, letting the agent reach external endpoints from inside its secure sandbox. Google points to its best-practices guidance for extending agents with external tools and APIs.
Custom function calling alongside sandbox tools
Developers can now add custom tools next to the built-in sandbox tools. The API uses step matching: built-in tools execute automatically on the server, while custom functions transition the interaction into a requires_action state, handing control back to the client to run local business logic. This gives teams a way to combine Google-managed execution with their own application-specific logic in the same interaction flow.
Credential refresh without losing state
Access tokens and short-lived API keys expire, which is a common pain point for any long-running or multi-step agent workflow. The update lets developers refresh credentials or rotate keys by passing an existing environment_id along with a new network configuration on the next interaction. New rules replace old ones immediately, and — importantly — the sandbox keeps its filesystem state, installed packages and cloned repositories intact. Agents don't need to restart from scratch just because a token expired.
Where to start
Google frames these updates as turning managed agents into asynchronous workers that operate inside real development environments without blocking the calling application. The announcement points developers to the Gemini Interactions API overview and the managed agents quickstart for details on custom agent definitions, environment configurations, network rules and advanced streaming patterns. Examples in the announcement use the @google/genai JavaScript SDK, with Python and cURL examples available in the separate Antigravity agent documentation. The announcement also notes that AI coding agents can install the Interactions API skill directly via npx skills add google-gemini/gemini-skills --skill gemini-interactions-api.
What this means for teams building web products
If you're building agents that touch internal systems, run for more than a few seconds, or need to survive a token expiring mid-task, these are the exact failure points that tend to break demos in production. Background execution removes the need to babysit open connections. Remote MCP support removes a layer of custom middleware many teams were already building by hand. And credential refresh without losing sandbox state means agents can run longer workflows without brittle restart logic. None of this changes what agents can reason about — it changes how reliably you can run them at scale, which is usually the harder engineering problem.