Gemini API Managed Agents: background tasks and remote MCP, from a dev's chair

What it is

Managed Agents is Google's hosted agent harness inside the Gemini API. Managed agents on the Gemini API give you a configurable agent harness. A single API call provisions a Linux sandbox where the agent reasons, executes code, manages files, and browses the web autonomously.

This week's update adds four things: Google DeepMind has added background execution and MCP (Model Context Protocol) support to its Gemini API managed agents. Agents can now run asynchronously in the background, connect directly to remote MCP servers, use custom functions alongside sandbox tools, and refresh credentials without losing state.

The unlock is the async part. Agents previously required a persistent HTTP connection for the entire duration of a task. That constraint is what killed most serious agent-loop designs on this platform.

The next-work-session test

Concrete scenario: you're building a nightly research agent that pulls from an internal Jira MCP server, runs code in the sandbox to correlate tickets with Sentry errors, and writes a summary to a doc.

Before this update, you were writing a queue worker, holding an HTTP connection open, and praying nothing timed out mid-tool-call. This session, you can hand the task to the API, poll for status, and let the harness manage the loop. Credential refresh means your OAuth token to Jira doesn't die at the 60-minute mark and orphan the run.

If your day job is agent loops, that changes the architecture diagram. One fewer worker fleet to babysit.

Pricing

There's a free tier for kicking the tires. Logan Kilpatrick, who runs the Gemini API team, said "you can now get started with Managed agents in the API via the free tier" in the launch tweet.

For paid usage, the harness rides on the standard Gemini API model pricing (tokens in/out per model on the pricing page) plus sandbox compute. On the enterprise side, Runtime and Sandbox environments, including Code Execution and Computer Use, are billed on Agent Compute (vCPU-hours) and Agent Memory (GiB-hours) resource usage.

The exact vCPU-hour rate for Managed Agents on the developer API tier (as distinct from the Enterprise Agent Platform SKU) isn't clearly broken out in the launch post. Pricing: partially unverified — model tokens are documented, sandbox compute rates for the developer-API path aren't cleanly published in one place.

What we'd actually use it for

Narrower than "autonomous agents that run your business."

• Background research agents that hit 2–5 MCP servers and produce a structured artifact.
• Scheduled ETL-ish jobs where the reasoning is the hard part and the tool calls are boring.
• Wrapping an internal API as an MCP server and letting the sandbox drive it — you can mix and match remote tools with built-in sandbox capabilities. Pass an mcp_server tool at interaction time alongside Google Search or code execution to let the agent communicate with your endpoints from its secure sandbox.

For a curl shape of the interaction, the custom agents doc shows the /v1beta/interactions endpoint taking an agent, input, and environment — familiar enough if you've used any other agent runtime.

Limits

Free-tier rate caps still bite. The 10 RPM limit on Gemini 2.5 Flash means you can process roughly 600 requests per hour. For a chatbot serving a handful of users, that is fine. For batch processing (analyzing a thousand documents, for example), you will need the paid tier. Agent loops burn requests fast — a single "task" is many turns.

MCP is only as safe as the servers you plug in. Google's own docs warn: Evaluate tool sources carefully. Only connect tools from sources you trust. A malicious or poorly written tool could expose data or perform unintended actions. Prompt injection through third-party MCP servers is a live attack surface.

Evals are still on you. The harness gives you a runtime, not a scoring rubric. You still need to build the offline eval set, the replay harness, and the regression checks. Nothing here helps with "did the agent do the right thing?"

Background ≠ unlimited. The blog post doesn't publish a maximum task duration or a hard cap on background job length. Assume there's one and design around it.

Try it if

• You're already on the Gemini API and want to stop running your own worker pool for agent tasks.
• You have internal APIs you'd wrap as MCP servers and let an agent orchestrate.
• You need credential refresh mid-run and hate writing that plumbing.
• You want a sandbox with code execution + browsing without provisioning it yourself.

Skip it if

• You're vendor-locked to OpenAI or Anthropic tool-use and your evals live there.
• Your agent loop needs deterministic, step-by-step control — a managed harness will fight you.
• You can't ship data through a Google-hosted sandbox for compliance reasons.
• You haven't built evals yet. Fix that first; the runtime is the easy part.