On July 7, 2026, Google shipped four updates to Managed Agents in the Gemini API: background execution for long tasks, direct connections to remote Model Context Protocol servers, custom function calling next to the built-in sandbox tools, and a way to rotate network credentials without losing agent state. For mobile teams, n8n automations, and multi-agent orchestrators, this is the beat where server-side agents stop being a demo and start behaving like real production workers.
The smol.ai AINews newsletter flagged the Gemini Managed Agents refresh as one of the week's pivotal orchestration moves, alongside Claude Cowork on mobile and Meta's Muse Image agentic loop. The through-line is the same: the agent runtime is moving off the caller's device and onto managed infrastructure, with the phone and the workflow engine reduced to observers. This guide walks through what actually shipped, why each change matters for a mobile plus automation stack, and how to wire it into an n8n pipeline without rewriting the app.
The 30-Second Version
What Actually Shipped on July 7, 2026
The June launch of Managed Agents put the model, a sandbox, code execution, and Google Search behind one API. The July update fixes the four things you hit as soon as you try to run something real: connections that time out, tools you cannot register, MCP servers you cannot reach, and credentials that expire mid-task.
| Change | What it does | Impact on mobile and automation teams |
|---|---|---|
| Background execution | Set background: true on an interaction and the task runs asynchronously on Google servers | Long agent runs no longer need an open HTTP connection from the phone or the n8n runner |
| Remote MCP servers | Agents connect directly to your MCP endpoints from inside the managed sandbox | Private databases and internal APIs plug into the agent without a custom proxy |
| Custom function calling | Interactions pause with requires_action so the client executes local business logic | Business rules and side effects stay on your servers, not in the Google sandbox |
| Credential refresh | Rotate tokens by passing the same environment_id with a new network config | Long-lived sessions survive key rotation, and rotated secrets do not blow the agent working state |
Why Background Execution Is the Headline Change
Before this update, calling the Interactions API meant holding the HTTP connection open for the entire task. If the agent cloned a repo, scanned a codebase, or ran a slow analysis, the connection itself became the point of failure. A dropped Wi-Fi handoff on mobile, a proxy timeout in front of n8n, or a container restart on the runner all killed the run.
Setting background: true on an interaction moves the task fully server-side. Your caller returns immediately with an interaction id, and the agent keeps working on Google's infrastructure until it either finishes, hits requires_action, or fails. That single flag changes three things at once for mobile and automation:
- The phone stops babysitting. A mobile app fires a task, closes the socket, and reopens the state only when a push arrives. Battery, background limits, and radios all get their budget back.
- The n8n workflow stops holding a runner slot. The start node kicks off the interaction, writes the id to a row, and exits. A separate webhook or poll picks the task up when it is ready.
- Retries move up a layer. The client no longer retries the whole prompt on a broken socket. It retries the polling, which is cheap and idempotent.
The right question for a July 2026 stack is not "can our runtime keep a Gemini connection open for ten minutes". It is "which of our long tasks should be background interactions with a durable id we poll from anywhere".
Remote MCP: The Agent Reaches Your Systems, Not the Other Way Around
Before this change, the sandbox only saw the built-in tools plus whatever you inlined in the prompt. To reach a private database or an internal API, you either shipped a custom proxy, mirrored the data through Google Cloud, or gave up and did it client-side. Remote MCP flips the direction.
Point the agent at an MCP endpoint and the sandbox opens a secure connection to your server. The agent discovers the tools you expose, calls them like any built-in, and the results flow back into the same conversation state. Practically, that means:
- Internal APIs stop needing a public shim. An MCP server behind a VPN or a signed tunnel is enough.
- Tool authorship stays in your repo. The same MCP server that powers your Claude Cowork or Hermes setup now powers Gemini too.
- Governance stays with you. Rate limits, per-tenant scoping, and audit logs live on your MCP server, not in Google's console.
MCP Is Becoming the Common Socket
Custom Function Calling: Where Your Business Logic Lives
Built-in tools run inside the Google sandbox. That is fine for code execution, search, and generic file work. It is not fine for anything that touches your customers, your billing, or your production database. Custom function calling gives you a clean seam.
You register the function schema in the interaction config. When the agent decides to call it, the interaction transitions to requires_action. Your client sees the pending call, runs the actual function on your servers, and posts the result back. The agent picks up where it left off. The pattern is familiar to anyone who has used the OpenAI Responses API or the Anthropic tool-use loop, but the state now lives on Google's side of the wire.
What to keep in-sandbox vs on your servers
- In the sandbox: code execution, web search, file manipulation, generic scraping, ad-hoc data crunching.
- On your servers via custom functions: writes to your database, sends to your customers, spend against your budgets, anything that needs your identity or your policy.
- On your MCP server: reusable internal tools you already expose to other agent runtimes, so the same tool works from Gemini, Claude, and OpenAI.
Credential Refresh Without Losing State
A long-lived agent that installs packages, clones repos, and builds up a working directory has real value trapped in that sandbox. Before this update, rotating a token meant a fresh environment and a fresh setup. The new flow is: pass the existing environment_id on the next interaction along with a new network configuration, and the sandbox keeps its filesystem, its installed packages, and its cloned repos intact.
In practice, that closes the last gap between a Gemini managed agent and a real background worker. Rotate keys on the hour without breaking the loop. Swap a database password without kicking a five-hour data run. Refresh a scoped token when a user re-authenticates in the mobile app, and the agent picks up the new credential on the next call without noticing.
Wiring the New Managed Agents into an n8n Workflow
The four updates map cleanly to four small nodes in an n8n workflow. Nothing new to install, no custom queue, no long-poll node held open for ten minutes.
Step 1: Kick the interaction in the background
The first node calls the Interactions endpoint with background: true and any MCP or custom function config the task needs. It writes the returned interaction id, the environment id, and the timestamp to a task row. The workflow then exits.
Step 2: Handle requires_action with a webhook
A webhook trigger receives the requires_action event, resolves it against the task row, runs the local function, and posts the tool output back to the interaction. The same webhook is the natural place to enforce your per-tenant permission checks and audit logging.
Step 3: Poll or subscribe for completion
Either a small poller (every 30 seconds) or a completion webhook flips the task row to done, writes the final output, and triggers whatever downstream nodes need the result. Because the agent runs server-side, this step is idempotent and cheap to retry.
Step 4: Rotate credentials in place
When a scheduled rotation fires or a user re-auths in the mobile app, a small node calls the Interactions API with the same environment id and the new network config. No sandbox restart, no re-clone, no lost packages.
Do Not Poll for the Whole Result
What This Means for Mobile Apps
A mobile app that talks to a Gemini managed agent should be a client of the task, not the host of it. That shift removes three familiar mobile pain points at once:
- No more long-lived socket on cellular. The phone posts a task, gets an id, and can be swiped away without breaking the run.
- Push is the natural UI. The server notifies the app on requires_action or completion, and the app opens the deep-linked review screen.
- State survives across devices. Because the sandbox and the environment id live server-side, the same task id opens on a phone, a tablet, or the web with identical state.
We covered the same pattern from the Claude side in the Claude Cowork mobile and web background AI agents guide. The Gemini update makes it a two-vendor story rather than a one-vendor bet, which is the right posture for anything that has to run for years.
How This Compares to Other Managed Agent Runtimes
The three big managed agent runtimes have converged on the same shape: durable id, sandboxed tools, human-in-the-loop pause, and now MCP as the shared socket. The details still differ, and the differences matter when you pick where a specific workflow should live.
| Capability | Gemini Managed Agents (Jul 2026) | Claude Cowork (Jul 2026) | OpenAI Responses API |
|---|---|---|---|
| Background execution | Yes, background: true | Yes, cloud-hosted tasks | Yes, background responses |
| Remote MCP | Yes, direct in sandbox | Yes, via Claude runtime | Yes, via connectors |
| Custom function calling | Yes, requires_action | Yes, tool use | Yes, tool calls |
| Credential refresh in place | Yes, same environment_id | Session-scoped | Session-scoped |
| Built-in tools | Code, search, files | Code, files, browser | Code, files, web |
| Best fit | Long server-side jobs with your MCP tools | Cross-device background agent UX | Streaming tool loops from your app |
For the wider picture on how these runtimes fit into an agentic-coding harness, see our orchestration era of agentic coding guide. For the specific pattern of splitting an agent into an executor and an advisor, see the executor and advisor pattern for AI agent orchestration. Both patterns sit naturally on top of the new Gemini flow.
Rollout, Pricing, and What to Watch
Managed Agents are still labelled as an evolving product surface, and pricing is per interaction plus underlying model calls. A few things to plan for before you move a real workflow onto it:
- Interaction cost is not just tokens. Background tasks bill for sandbox time on top of model usage. A task that thinks for ten minutes costs more than the same prompts run inline.
- Environment lifecycle is your problem. The API keeps state per environment_id, but nothing gets garbage-collected automatically. Tag every environment with an owner and a retention policy.
- MCP posture is your job. The agent connects to whatever endpoint you point it at. Enforce auth, per-tool rate limits, and structured audit logs on the MCP server itself, not on the caller.
- Compliance follows the sandbox. Data that reaches the sandbox is processed on Google infrastructure. Route regulated flows through your MCP layer with the right redactions.
Where This Fits in the Halmob Stack
At Halmob, most engagements look like the same three-layer picture: a mobile app that has to feel instant, an n8n automation layer that does the real work, and an agent that keeps the two aligned. The Gemini Managed Agents update lands directly on that stack. Background execution takes long tasks off the phone and off the n8n runner. Remote MCP gives us one integration point for internal tools that every agent runtime can use. Custom function calling keeps our business logic where it belongs. Credential refresh finally lets long-lived sandboxes survive real-world key rotation.
The playbook we ran for the Claude side in the Claude Cowork background agents guide transfers here almost line for line: give every workflow a task id, split on the first human decision, push a state change with a deep link instead of a payload, and treat the review screen as the product surface. If you already run n8n on AWS ECS Fargate, the new Gemini flow slots in on top of the same task table, retry policy, and push channel.
For teams weighing which agent runtime to standardize on, the routing angle from our model routing layer for mobile AI agents and n8n flows still applies: pick the runtime per workload, not per vendor. Gemini Managed Agents is now a strong default for long server-side jobs that need your MCP tools, without giving up the option to route the interactive parts to Claude or OpenAI.
The Bottom Line
The July 7, 2026 update turns Gemini Managed Agents into a credible production runtime for background AI agents. Background execution removes the long-connection failure mode. Remote MCP gives the agent a proper door into your internal tools. Custom function calling keeps business logic on your servers. Credential refresh keeps long-lived sandboxes alive through real-world rotations. For a mobile plus n8n plus agent orchestration stack, the practical move this week is small: pick one long workflow, run it with background: true, point it at your MCP server, and let the phone or the browser observe a durable task id instead of holding a socket open.
For source material, start with the Google announcement on expanding Managed Agents in the Gemini API, the original Managed Agents launch post, and the smol.ai AINews newsletter for the wider July 2026 agent-orchestration context. When it is time to move one of your workflows onto this stack, Halmob can design the task table, the MCP surface, and the review screen that make managed agents safe to ship.