Written by AI agents, curated and verified by me.
Managed agents in the background: convenient, and one more dependency
- Agentic Engineering
- Automation
On 7 July, Google announced four additions to managed agents in the Gemini API. Agents now run asynchronously in the background, they call remote MCP servers directly, they mix your own functions with the built-in tools, and credentials can be rotated without losing the sandbox. Google frames this as a response to developer feedback, so you can build “reliable, production-ready agents”. The underlying point is the same as in June. Long-running orchestration keeps moving to the vendor side.
What did Google announce?
Four things, all in the Interactions API. First, background execution: set background: true and you get an ID back immediately, then poll for status, stream progress, or reconnect later. No open HTTP connection required. Second, remote MCP servers as a tool of type mcp_server, configured with name and url, meant for private databases and internal APIs.
Third, custom functions alongside the sandbox tools. Google calls this step matching: built-in tools run automatically on the server, while custom functions move the interaction to requires_action so your client executes the local business logic. Fourth, credential refresh: pass your existing environment_id with a new network configuration, the new rules replace the old ones immediately, and the sandbox keeps its filesystem state, installed packages, and cloned repositories. The announcement names no pricing and no GA date; the links point to preview documentation.
What you gain
The gain is concrete and not small. Anyone who wanted an agent to run for hours has so far built the infrastructure for it: a sandbox that survives, a job system with queue and retry, a status model the frontend hangs off. That falls away. Credential refresh also solves something that is genuinely annoying in practice. A token expires, and until now that often meant rebuilding the environment and losing its state. Swapping the network rules while the cloned repository stays put saves real steps.
The direct MCP call is sensible too. An agent that reaches your internal APIs without routing every call through your own process is simply less code.
And what you hand over
This is exactly where the other side sits. A direct MCP call means the connection to your internal API originates in Google’s environment, not yours. That is a decision about network boundaries and access rights, not just convenience. Background execution means there is now a stretch between start and result where you can poll but not intervene. And a sandbox that keeps its state across credential changes is a piece of runtime you do not own and cannot move elsewhere.
The GA of the Interactions API already made this point: the loop moves to the vendor. This announcement continues that line. It does not just make managed execution possible, it makes it pleasant enough that people stop questioning it.
How I would handle it
Not as a matter of principle, but as a matter of scope. For work that lives in the Google ecosystem and whose result you review anyway, the managed sandbox is a reasonable shortcut. For anything that writes data unattended or is meant to run across vendors, your own frame still pays off. Step matching helps here more than it first sounds: whatever you define as a custom function comes back to you via requires_action. That boundary is where you keep control, and it is worth drawing it deliberately instead of pushing as much as possible to the server.
The rest is the old rule, see agentic engineering: the capabilities come from the vendor, the verification stays with you. An agent that works unobserved for hours is no progress if nobody has defined how you would tell that the result is correct.