Summary: Google expanded Managed Agents in the Gemini API with asynchronous background execution, remote MCP server connectivity, custom function calling, and credential refresh across interactions. The article says background jobs return an interaction ID immediately and can run while clients disconnect or poll later. It cautions that the announcement leaves execution limits, authentication, and monitoring details for developers to solve.
Google has shipped a fresh set of capabilities for Managed Agents in the Gemini API, built for developers whose agents have to survive in production. The additions cover asynchronous background execution, remote MCP server connectivity, custom function calling, and credential refresh that spans interactions. For product builders and anyone learning AI tooling, the trajectory is easy to read: agents are moving past simple conversational bots and becoming long-running execution units that operate across systems. This article covers what shipped, how each piece works, where it fits in real products, which questions remain open, and the takeaways worth carrying home.
What Changed: From Synchronous Requests to Asynchronous Workers
So far, calling an agent through the Gemini API has largely been a synchronous affair: the request goes out, the response arrives, and the interaction closes. Workloads that show up in practice — batch document processing, website scraping, report generation — routinely need minutes or longer, and the synchronous model buckles under them. As the official blog notes, holding an HTTP connection open for jobs of that length is fragile.
Google’s answer is background execution: interactions can run asynchronously on the server. With background: true, you get an interaction ID back immediately; from there, the client can poll for status, stream progress, or drop the connection and return later while the agent keeps working remotely. The interaction model moves away from a request-response pattern toward something shaped like a job queue, and that is what allows an agent to operate as an asynchronous worker.
The second piece of the update is remote MCP server integration. Model Context Protocol (MCP) is now the standard way to hook agents up to external tools, though real deployments have often stayed local or confined to one environment. Managed agents can reach remote MCP servers directly, getting to private databases or internal APIs without anyone writing custom proxy middleware — a real convenience for enterprises whose tools sit across departments and cloud environments.
Two further items complete the release: custom function calling that works alongside the built-in sandbox tools, and credential refresh across interactions, which helps keep long sessions secure.
The Mechanics: Background Execution and Remote MCP in Practice
Every code example on the official blog is written with the @google/genai JavaScript SDK; developers on Python or cURL are directed to the Antigravity agent documentation.
Starting Work That Runs in the Background
A long-running analysis starts with creating an interaction that carries background: true. An ID returns right away, and progress checks go through client.interactions.get(). The blog’s trimmed-down example reads:
import { GoogleGenAI } from "@google/genai";
const client = new GoogleGenAI({});
// 1. Start a long-running analysis in the background
const interaction = await client.interactions.create({
agent: "antigravity-preview-05-2026",
input: "Clone https://github.com/googleapis/js-genai, find all TODO comments in the source code, and categorize them by module and priority in a markdown report.",
environment: "remote",
background: true,
});
console.log(`Background task started. Interaction ID: ${interaction.id}`);
// 2. Poll asynchronously without blocking an open HTTP socket
let result = interaction;
while (result.status === "in_progress") {
await new Promise((resolve) => setTimeout(resolve, 5000));
result = await client.interactions.get(interaction.id);
}
if (result.status === "completed") {
console.log("Task Completed:\n", result.output_text);
} else {
console.error(`Task ended with status: ${result.status}`);
}The pattern is: submit, then check back later. No persistent connection has to stay open on your side.
Hooking Up a Remote MCP Server
Pointing a managed agent at a remote MCP server comes down to supplying an mcp_server tool at interaction-creation time, alongside built-ins like Google Search and code execution. In the blog’s example, the agent queries an internal observability server for latency spikes and lines them up against git commits:
import { GoogleGenAI } from "@google/genai";
const client = new GoogleGenAI({});
const interaction = await client.interactions.create({
agent: "antigravity-preview-05-2026",
input: "Check our internal observability server for recent latency spikes in the auth service and correlate them with git commits.",
environment: "remote",
tools: [
{ type: "google_search" },
{ type: "code_execution" },
{
type: "mcp_server",
name: "internal_telemetry",
url: "https://mcp.internal.example.com/mcp",
},
],
});
console.log(interaction.output_text);The agent stays inside a secure sandbox and reaches your endpoints from there, mixing remote tools with its built-in capabilities.
Bringing In Custom Functions
Custom functions fold domain-specific tools into the set next to the built-in sandbox tools. The API splits execution by type: built-in tools are handled automatically on the server, while a custom function flips the interaction into requires_action and hands control to your client to run the local business logic. The blog walks through the flow with a get_weather function:
import { GoogleGenAI } from "@google/genai";
const client = new GoogleGenAI({});
// 1. Define a custom domain function
const getWeatherTool = {
type: "function",
name: "get_weather",
description: "Gets the current weather for a given location.",
parameters: {
type: "object",
properties: {
location: {
type: "string",
description: "The city and country, e.g. San Francisco, USA",
},
},
required: ["location"],
},
};
// 2. Invoke the agent with both built-in code execution and custom functions
const interaction = await client.interactions.create({
agent: "antigravity-preview-05-2026",
input: "Check the weather in Tokyo, write a Python script to convert the temperature to Fahrenheit, and save the result to weather.txt.",
environment: "remote",
tools: [
{ type: "code_execution" },
getWeatherTool,
],
});
// 3. Handle custom function execution cleanly
if (interaction.status === "requires_action") {
// Filesystem and sandbox tools execute automatically and produce a result
}The hybrid arrangement leaves sensitive logic in your hands and gives the agent’s built-in capabilities everything else.
Practical Scenarios for Product Builders
Products that need to offer more than a plain chatbot will find several concrete use cases here.
- Asynchronous document handling: A user uploads a contract, report, or dataset; a background task kicks off to analyze, summarize, or extract the data; a notification lands once it finishes. The flow slots into a job-queue model and keeps the user unblocked.
- Cross-system data correlation: Through remote MCP, agents can draw data from an internal CRM, databases, or third-party services. The blog’s own example — pulling internal telemetry for latency spikes and lining them up with recent code commits — is a natural fit for DevOps and incident response.
- Hybrid tool execution: Custom functions keep proprietary algorithms or sensitive operations on your infrastructure while the agent covers reasoning and sandbox work. One shape this takes: the agent writes a report, then calls a custom function that applies your company’s formatting rules.
- Research jobs that run long: Web scraping, batch analysis, and report generation can each take minutes — exactly the ground background execution was built for. The agent keeps grinding away while the user gets on with other work.
What’s Missing and What You Trade Away
The official blog post works as an announcement, not as a technical reference: the features get the spotlight, and the details a production deployment requires never make an appearance.
- No stated limits: Nothing is said about maximum execution time for background tasks, concurrency limits, or rate limits. Those constraints live in the API documentation, so look there.
- Security and authentication: Attaching agents to remote MCP servers inevitably raises security questions. The blog’s guidance amounts to following best practices when extending agents with external tools; it offers nothing concrete on authentication methods, encryption, or defense against prompt injection. Designing those safeguards falls to you.
- Monitoring and debugging: Background tasks and remote connections each add system complexity. Only careful logging and tracing will tell you what the agent is really doing — most of all when it runs asynchronously.
- Credential refresh: It gets a mention but no explanation. The blog never details the mechanism, so implementing it correctly requires a trip to the documentation.
Lessons for Building on Managed Agents
Read as a whole, the updates capture Google steering agents away from single-turn conversations and toward execution that persists and behaves like a service. Three implications stand out for product builders:
- Put async at the center of the design: The moment long tasks enter your agent’s job description, the user experience has to be rethought — users file the task and get notified when it completes, instead of staring at a spinner.
- Make tool connections standard: Remote MCP gives tool integration a modular shape, and asks in return for tight control over connection configuration and access permissions.
- Invest in observability early: With background tasks and remote connections in the picture, effective debugging depends on logging and tracing done thoroughly.
Before any of this goes into a product, work through the complete API documentation and run a small proof of concept, checking security and reliability before anything else. Tools are groundwork, nothing more; genuine product value comes from the way you design the agent’s task flow and error handling. The blog’s own claim is that these capabilities exist to help you build reliable, production-ready agents — production readiness, though, remains a responsibility you carry.