Google shipped four changes to Managed Agents in the Gemini API on July 7, and the release note reads like a maintenance list: background execution, remote MCP servers, custom function calling, credential refresh. Three of those are conveniences. One of them quietly changes how you're supposed to build a long-running agent — and it's on the free tier, so the change reaches you whether or not you were planning an upgrade.

Here is the whole release in one screen, then why the boring-sounding one matters most.

What actually shipped#

The one that changes your architecture#

The other three are quality-of-life. Background execution is the one that moves a line on your diagram.

Until now, a Gemini agent task that took ten minutes needed a connection held open for ten minutes. That's fine on a demo and a liability in production: a dropped Wi-Fi connection, a server redeploy, a load balancer's idle timeout, or a closed laptop lid kills the run, and you're left reconstructing where it got to. Everyone building serious agents already worked around this with their own queues.

background: true folds that pattern into the API. You start the task, you get a handle, and completion arrives by polling or a subscription. The agent's work is now decoupled from the caller's connection.

Background execution isn't a feature so much as a demotion of the HTTP request from "the thing that holds your task" to "the thing that kicked it off." That demotion is the entire difference between a demo agent and a production one.

If you've read our take on triggering an agent — cron vs webhook vs queue, this is the same lesson arriving as a default: slow work belongs on a job model, not a synchronous call.

Remote MCP narrows the self-host case — it doesn't close it#

The second-most-important change is remote MCP. The reason a lot of teams kept agents on their own infrastructure was reach: the agent needed to touch your systems, and a managed runtime in someone else's cloud couldn't get to them without a tunnel. Remote MCP removes that specific objection. A Gemini Managed Agent can now connect to the MCP servers you already run.

That reopens the where-to-run-a-long-running-agent decision that a lot of founders thought they'd settled. But it reopens it, it doesn't decide it. Three reasons to self-host survive intact:

  1. Latency. An agent that makes twenty tool calls per task pays the round trip to your MCP server twenty times. If those tools live next to your agent, you save it; across clouds, you don't.
  2. Data residency. If the data can't leave your infrastructure for legal or compliance reasons, "the cloud agent can reach your tools" is not a feature — it's the problem.
  3. Cost and concurrency control. A managed runtime is convenient until you're running thousands of concurrent agents and want to own the bill and the backpressure.

What to do about it#

If you're on Gemini and you've been holding connections open for long agent runs, this is a free reliability upgrade — move to background: true and delete your homegrown keep-alive. If you self-host mainly because your agent needed to reach your own tools, re-run that decision now that remote MCP exists; you may be self-hosting for a reason that no longer applies. And if you self-host for latency, residency, or cost, none of that changed today — hold your ground.

The headline is four features. The story is that Google just made the default way to build a Gemini agent look a lot more like the way experienced teams were already building one by hand.

Details and parameter names are as announced on July 7, 2026; check the current Gemini API docs before you wire it up.