Gemini API's managed agents get background execution, remote MCP, and credential refresh

Google shipped a set of updates to Managed Agents in the Gemini API on July 7 that reads less like a new-capability announcement and more like a checklist of what breaks when you run agents in production. Background execution, remote MCP server connections, custom function calling alongside sandbox tools, and mid-session credential refresh — four features, all aimed at failure modes anyone running long-lived agents already knows by name.

Managed Agents sit behind the Gemini Interactions API: one endpoint, and Gemini handles reasoning, code execution, package installs, and file management inside an isolated cloud sandbox. The pitch has always been "call one endpoint, we run the loop." This update is about making that loop survive contact with a real deployment.

Background execution kills the held-open connection

Pass background: true and the interaction runs asynchronously server-side. The API hands back an ID immediately; your client polls for status, streams progress, or reconnects later once the agent finishes. This is the fix for a problem every agent builder hits eventually: an HTTP connection held open for a multi-minute, or multi-hour, task is one flaky proxy timeout away from losing the whole run. Decoupling "the agent is working" from "my client is still connected" is table stakes for anything that runs unattended.

Remote MCP servers replace custom proxy middleware

Instead of writing a bridge service to expose a private database or internal API to the sandbox, you now pass an mcp_server tool at interaction time, alongside built-ins like Google Search or code execution. The agent talks to your endpoints directly from inside its sandbox. This is the practical payoff of MCP becoming a standard: instead of every provider inventing its own connector format, you point a managed agent at any compliant MCP server and it's a tool, full stop.

Custom functions run next to sandbox tools

You can register your own functions alongside Gemini's built-in ones. The API uses step matching to route calls: built-in tools execute automatically inside the sandbox, and calls to your custom functions transition the interaction to a requires_action state so your client executes the business logic locally. This matters because "run this in Google's sandbox" and "run this against my internal service with my auth" are different trust boundaries, and pretending otherwise is how agents end up either over-permissioned or unable to do anything useful.

Credential refresh without losing sandbox state

Access tokens and short-lived API keys expire; long-running agents outlive them. Now you can pass the same environment_id with a new network configuration on a later interaction, and the new credentials replace the old ones immediately, while the sandbox keeps its filesystem, installed packages, and cloned repos intact. That last clause is the one worth underlining: state persistence across a credential swap means you don't pay for token rotation by restarting the whole environment.

Why this batch, not a new model

None of these four features is a research result — there's no new benchmark, no new model card. What's notable is that all four target the same seam: the gap between an agent that answers a prompt and an agent that's a long-running worker with its own lifecycle, credentials, and external dependencies. Background execution decouples runtime from connection lifetime. MCP decouples tool access from custom integration work. Step matching decouples sandbox trust from client trust. Credential refresh decouples the environment's identity from its state.

I've built agent systems where each of these was a real, separately-solved problem: a polling layer bolted on because sessions timed out, a hand-rolled MCP bridge, a token-refresh path that also happened to restart the sandbox and lose an hour of installed dependencies. Seeing a provider ship all four as first-class API behavior, rather than leaving them as integration work for every team building on top, is the actual signal here — managed agents are being built for the operational reality of running them, not just the demo.