Gemini Managed Agents July 7 Update: Background Tasks, Remote MCP, and the Production-Ready Feature Set — Builder's Guide

Google expanded Gemini Managed Agents on July 7, 2026, adding four features that fill the biggest gaps between the original May 19 launch and what production deployments actually require. This is a research-based summary; we reviewed Google’s July 7 blog post and third-party technical coverage, but did not build with these APIs ourselves.

Context: If you haven’t read our original Gemini Managed Agents guide, the short version is: one call to the Interactions API spins up an isolated cloud Linux sandbox running the Antigravity agent, built on Gemini 3.5 Flash. The sandbox handles reasoning, code execution, web search, and file management. State persists across calls within a session.

The July 7 update adds four production-oriented capabilities on top of that foundation.

What Changed: Four New Capabilities

Background Execution

The original Managed Agents API was synchronous: you sent a request, kept the connection open, and waited. For short tasks that’s fine. For a research agent that browses 50 URLs, or a data pipeline that processes a large file, you’re holding a connection open for minutes.

The July 7 update adds a background: true parameter. With it, the API returns a job ID immediately. The task runs asynchronously on Google’s infrastructure. Client code can then:

• Poll the job ID to check status
• Stream progress when results become available
• Reconnect later — useful if the user closes a browser tab or your server restarts

This makes long-running agentic tasks practical. A user can trigger a multi-step research job, close the tab, and come back 20 minutes later to pick up results. The agent keeps running on Google’s servers regardless.

Practical implication: Agents that previously hit client-side timeouts or required the user to babysit a browser tab can now run as backend jobs. This is close to the “fire and forget” model that production job queues use.

Remote MCP Server Integration

This is the most architecturally significant addition.

The original Managed Agents ran with built-in tools (code execution, web search, URL fetch). Any custom tools required the developer to handle the gap between the sandbox and external systems, typically through custom middleware.

The July 7 update lets agents connect directly to remote MCP servers from inside the cloud sandbox. An agent can now reach:

• Documentation systems
• Issue trackers and project management tools
• Internal databases exposed via MCP
• Browser automation services
• Any MCP-compatible tool

No tunneling. No custom proxy. The agent and the MCP server talk directly.

Why this matters for builders: Remote MCP integration means you can extend Managed Agents with your own tooling using the same protocol you’d use with Claude Code, Cursor, or any other MCP-capable client. One MCP server definition, multiple consumers.

The alternative — custom function calling (see below) — works for simple, app-specific operations. For anything that benefits from the MCP ecosystem or that you’re already maintaining as an MCP server, remote MCP is cleaner.

Custom Function Calling

Not every integration belongs in an MCP server. App-specific operations — validate a customer entitlement, calculate a quote, open a pull request against a specific repo — are often too narrow to warrant a full MCP server, but still need to run client-side.

The custom function calling feature handles this with the requires_action pattern — the same status name and pause-for-client-execution flow used by OpenAI’s Assistants API function calling, where a run “enters a requires_action state” when a function call needs to run client-side. The flow:

1. Developer declares custom tools alongside built-in sandbox tools
2. When the agent decides to use a custom tool, the API returns requires_action with the function name and arguments
3. The client executes the function locally and returns the result
4. The agent incorporates the result and continues

Built-in tools (code execution, web search) run server-side automatically, without interrupting the synchronous flow. Custom functions pause and wait for the client.

Combining with background execution: requires_action is one of the interaction states surfaced when polling a background job, so a client polling background: true job status can detect when a custom function call is waiting, not just when the job finishes.

Credential Refresh

The fourth feature solves a lifecycle problem: API keys and network credentials expire. In the original design, expiring credentials meant abandoning the session and losing the sandbox’s filesystem state — installed packages, cloned repos, intermediate results.

The July 7 update lets you refresh credentials by passing a new network configuration alongside the existing environment_id. The sandbox keeps its filesystem state; only the network credentials are replaced. The new rules take effect immediately.

This is primarily relevant for sessions that span multiple hours or that access systems with short-lived tokens (OAuth sessions, temporary cloud credentials). For most short-lived tasks, it won’t come up.

What This Means for Production Deployments

The original Managed Agents were useful for prototyping and demos: low barrier to entry, environment compute not billed during preview, built-in tools. The gaps were the ones that matter for production: no way to run long jobs asynchronously, no standard protocol for external tools, no lifecycle management for credentials.

The July 7 update closes three of those four gaps directly:

• Background execution → long-running jobs without open connections
• Remote MCP → external tools via standard protocol
• Credential refresh → lifecycle management for auth

What’s still missing: Google hasn’t published pricing for Managed Agents beyond “not billed during the preview period”. For production deployments, cost per interaction and cost per background task-hour matter a lot. Until Google publishes that, Managed Agents has an evaluation ceiling: you can build and test, but committing to production scale requires a pricing conversation that hasn’t happened publicly yet.

Comparison to Alternatives

Sources for the non-Gemini rows: Claude Managed Agents — Anthropic’s launch post (async/long-running use case, pricing) and platform docs (MCP servers as a built-in tool; MCP tunnels in limited preview). AWS Bedrock AgentCore — product page and async task docs (background processing), plus published rates. OpenAI Responses API — background mode docs and MCP and connectors docs (remote MCP server support).

By feature checklist the four platforms now look similar; the real differences are in maturity (Anthropic’s MCP tunnels are still a limited research preview) and pricing model. Gemini Managed Agents is the only one of the four with no published pricing at all — everything else on this list charges for compute or usage today.

What to Do Now

If you built on the original Managed Agents and have long-running tasks: test background: true before your next deployment. The async model changes the UX significantly — users can leave and come back.

If you have existing MCP servers (for Claude Code, Cursor, or other clients): point a Managed Agent at them to test compatibility. The integration uses the same MCP protocol, so it should work without modifications — but testing in preview is the time to find edge cases.

If you’re evaluating Managed Agents for production but waiting on pricing: that wait is still rational. The feature set is now strong; the commercial terms are not yet public.

This is a research-based guide. ChatForest did not run code against these APIs. Technical details are drawn from Google’s July 7 blog post and The Decoder’s coverage. Test against Google’s official documentation before building.