Google shipped a meaningful upgrade to the Gemini API on July 7, 2026: its Managed Agents now run in the background, connect to remote Model Context Protocol servers, call your own custom functions, and refresh their credentials mid-session. Together, these move Managed Agents from a demo-friendly feature into something you can actually put in production.
If you build tools, apps, or automations, this is the update that lets a Gemini agent kick off a long job, reach into your private database, run your business logic, and keep going without blocking your app or leaking your keys. Here is what changed, and a five-step workflow for building an async agent on top of it.
What Google Added to Managed Agents
Managed Agents give you a server-side sandbox where Gemini can execute multi-step work. The July release adds four capabilities that close the gap between a prototype and a shippable system. The quickstart docs cover each one, and the short version is below.
The Four New Capabilities at a Glance
| Capability | What it does | Why it matters |
|---|---|---|
| Background execution | Pass background: true to run an interaction asynchronously and get an ID to poll or reconnect to later | Long jobs no longer block your app or time out a request |
| Remote MCP servers | Connect an agent straight to an MCP server for private databases and internal APIs | No custom proxy middleware to build and maintain |
| Custom function calling | Register your own tools alongside the built-in sandbox tools | Your business logic runs client-side via a requires_action signal |
| Credential refresh | Update tokens and keys by reusing an existing environment_id | Sandbox files, packages, and repos stay intact across a refresh |
Background Execution: Fire and Forget Agents
The headline feature is asynchronous runs. Set background: true on an interaction and the API returns immediately with an ID. The task continues remotely while your application does other things, and you poll the ID for status or reconnect to it later. The background execution docs spell out the polling and reconnection flow.
This is the pattern production systems need. A research agent that reads fifty documents, or a data agent that crunches a large export, should not hold an HTTP request open or risk a gateway timeout. Background mode makes the agent a job you start and check on, not a call you wait on.
Remote MCP: Connect Agents to Your Own Tools
The Model Context Protocol has become the common language for wiring AI to external tools and data. With this release, a Managed Agent can talk to a remote MCP server directly, reaching private databases and internal APIs without you standing up a bespoke proxy in between.
That is a real reduction in glue code. Instead of writing and securing a middleware layer that translates between Gemini and your systems, you point the agent at an MCP endpoint and let the protocol handle the contract. Custom function calling complements this: built-in sandbox tools run automatically server-side, while your registered functions trigger a requires_action response so your client executes the sensitive business logic on your terms.
Build It: An Async Research Agent in Five Steps
Here is a concrete workflow that uses three of the four new features together. The goal: an agent that gathers and summarizes a large set of sources in the background and writes results into your own store.
- Create the agent environment and note its
environment_id. You will reuse this to keep the sandbox warm across runs and credential refreshes. - Attach a remote MCP server that exposes your document store or database, so the agent can read sources and write summaries without custom proxy code.
- Register a custom function for anything sensitive, such as posting the final summary to an internal API. It fires as a
requires_actionstep your client controls. - Start the interaction with
background: trueand capture the returned ID. Your app is now free to move on while the agent works. - Poll the ID for completion, then refresh credentials with the same
environment_idif tokens expire, keeping files and packages intact between runs.
How to integrate: wrap the poll in a webhook or a scheduled check so your product surfaces the result when it is ready, rather than making a user wait. The agent becomes a background worker your app orchestrates, not a chat you babysit.
How This Fits the Broader Agent Race
Google has been steadily hardening its agent stack. The Managed Agents upgrade lands shortly after the Interactions API reached general availability, and it mirrors the industry-wide shift toward agents that run remotely, speak MCP, and report back asynchronously.
The competitive picture is easy to read: every major lab now wants developers building durable, production agents on its API rather than gluing together one-off scripts. For how a rival stack frames the same problem, see our breakdown of Claude Managed Agents, and for Gemini's earlier async groundwork, our look at Gemini API webhooks for long-running jobs.
What to Do Next
If you already build on Gemini, the fastest path is to take one synchronous agent you run today and make it a background job.
- Pick a long task that currently risks timeouts, and add
background: trueso it runs async. - Swap custom proxy code for a remote MCP connection to your database or API, following the agents documentation.
- Move sensitive steps into custom functions so your client, not the sandbox, executes them.
- Plan for credential refresh by reusing the
environment_idinstead of rebuilding the environment.
Frequently Asked Questions
What are Gemini API Managed Agents?
They are a server-side sandbox in the Gemini API where a Gemini model can run multi-step work using built-in tools, with Google managing the execution environment for you.
How does background execution work?
You pass background: true on an interaction. The API returns an ID immediately, the task runs remotely, and you poll the ID for status or reconnect to it later.
Do I need custom middleware to reach my own database?
No. Remote MCP support lets a Managed Agent connect directly to a Model Context Protocol server for private databases and internal APIs, removing the proxy layer.
What is the difference between built-in tools and custom functions?
Built-in sandbox tools run automatically server-side. Custom functions you register trigger a requires_action response so your own client executes them, which is useful for sensitive business logic.
What happens to my sandbox when I refresh credentials?
You reuse the existing environment_id with new network configuration. The sandbox filesystem, installed packages, and repositories remain intact.
Is this ready for production use?
Google positions the release specifically for building reliable, production-ready agents, citing async execution, external integration, custom logic, and secure credential management as the enablers.
