Google’s Managed Agents preview moves more of the agent runtime into the Gemini API. Instead of building a planning loop, Linux sandbox, file workspace, web tools, and background job system from scratch, a developer can invoke Google’s Antigravity agent and receive a hosted environment where the agent reasons, executes code, manages files, and browses the web.
Announced on May 19, 2026, the preview is aimed at long-running work that exceeds a normal request-response call. It is available through the Interactions API and Google AI Studio, with enterprise support also described as preview. The convenience is significant, but “managed” describes infrastructure ownership—not the transfer of product responsibility to Google.
What Antigravity provides
Antigravity is Google’s general-purpose managed agent powered by Gemini 3.5 Flash. A single interaction can provision a remote Linux environment and run the agent loop inside it. The agent can plan, call tools, execute code, create and modify files, and retrieve live information.
An environment can persist across follow-up interactions, allowing the agent to resume with files and state intact. Google’s quickstart documents native context compaction around long sessions so the agent can remain focused rather than endlessly appending history.
This solves several engineering problems: sandbox provisioning, runtime installation, turn orchestration, streamed progress, and file handoff. It does not guarantee that the plan is correct, code is safe, or files are appropriate to publish. Every artifact still needs validation.
The public preview label matters. Agent IDs, limits, included compute, pricing, and APIs may evolve. Production teams should isolate integration code, pin supported SDK versions, and monitor the official changelog and documentation.
Custom agents as versioned files
Developers can customize Antigravity inline or register a reusable managed agent. System instructions shape behavior. Tools can override the defaults. Files and skills can be mounted into the environment.
Google recommends a project structure built around AGENTS.md, skill folders containing SKILL.md, and workspace data. This makes an agent definition reviewable in version control. A change to a prompt or skill can go through the same approval process as code.
Versioned files improve governance only if the runtime records which version was used. Store a commit or content hash beside each interaction. Otherwise, a future investigator may see the current skill but not the one that produced the output.
Inline overrides are useful for one task, yet they can bypass the intended reusable definition. Organizations should log overrides, restrict who can supply them, and ensure they cannot silently weaken network or tool policy.
Remote MCP and custom functions
Managed Agents can be configured with remote MCP servers or custom function definitions. MCP gives an agent a standard way to discover and call external tools. Functions connect directly to application APIs. Neither should be exposed wholesale.
Google’s documentation allows developers to replace default tools and configure server access. The important design work remains local:
- allow only the operations needed for the agent’s purpose;
- separate read and write credentials;
- require confirmation for consequential side effects;
- validate tool arguments outside the model;
- record tool name, schema version, requester, and result;
- use idempotency keys for retried operations;
- sanitize tool output before it becomes new instructions.
A remote MCP server is another trust boundary. It can change behavior, return malicious content, or become unavailable. Register servers by an approved URL, authenticate through a controlled credential mechanism, and monitor their availability and schema.
Background execution for long tasks
Standard HTTP connections often time out before research or multi-step agent work finishes. Gemini’s Interactions API supports background execution. Setting the documented background option makes the API return an interaction ID while work continues on the server.
The client can poll status, reconnect to a stream, inspect progress, or cancel the interaction. Follow-up calls can chain from a completed interaction. Google documents constraints around continuing an interaction that is still in progress, so clients should treat the status machine as authoritative.
Background execution changes application design. A web request should enqueue or register the interaction, persist its ID, and return control to the user. A worker or webhook-like monitor can update status without asking the model to rediscover the task.
Store:
- interaction and environment IDs;
- agent definition version;
- requesting user and approval scope;
- start, update, completion, and cancellation timestamps;
- model and tool consumption;
- output file identifiers and validation results;
- failures and whether a retry created a new interaction.
Do not use the chat transcript as the job database.
Sandbox security is configurable, not automatic
Every managed agent runs in an OS-isolated sandbox, but Google’s agent overview says outbound network access is unrestricted by default. Developers can restrict or disable it with an allowlist. For sensitive work, default-open networking is usually too broad.
The sandbox may encounter prompt injection on webpages or in mounted files. Network restrictions reduce exposure. Tool allowlists and human approval reduce impact. Credentials should use least privilege and short lifetimes. Google documents secure header transformation mechanisms that keep credentials outside the sandbox, but teams must still decide which authority each credential grants.
Environment lifecycle also affects privacy and reproducibility. Google states that environments are permanently deleted after seven days of inactivity and that virtual machines spin down after brief inactivity. Important results must be downloaded to approved storage before deletion. Sensitive temporary files should not remain merely because the environment will eventually expire.
Pricing and operational limits
Managed Agents use pay-as-you-go billing based on Gemini model tokens and tool usage. Google’s overview estimates that one interaction can consume roughly 100,000 to 3 million tokens depending on the task. It says environment compute is not billed during the preview; that is a launch condition, not a permanent promise.
Budget for web tools, external APIs, storage, human review, and failed attempts as well as model tokens. Put a token and tool budget around the entire interaction, not only one model turn. Cancel tasks that have lost their business value.
The managed runtime can lower engineering cost, but it may not lower per-task cost for simple work. A conventional Gemini call or deterministic function is more appropriate for one-step extraction or transformation. Managed Agents earn their overhead when a task genuinely needs files, code, tools, and extended execution.
Best-fit use cases and limitations
Good candidates include research that creates artifacts, data analysis in a temporary environment, code-assisted document production, and a multi-system workflow with explicit review. Weak candidates include low-latency chat, repetitive high-volume classification, critical actions without a human checkpoint, and workloads that cannot permit remote execution.
Preview agents can misunderstand objectives, create plausible but incorrect artifacts, or spend many loops on the wrong approach. Use acceptance tests and independent validators. A slide deck should be rendered and inspected; a data analysis should reproduce from code; a downloaded file should be checked for type and content.
Relating Managed Agents to Medux asynchronous jobs
The architecture resembles an external media workflow even when the services are unrelated. A managed agent starts a background interaction and tracks an interaction ID. Medux media processing returns its own task identifier that must be polled until completion. Those IDs belong to different state machines and must not be conflated.
If a developer separately registers an authorized Medux remote MCP server, a managed agent could potentially request a supported media operation. That would be a custom configuration, not native Gemini support, and current compatibility, authentication, and policy would need verification. The existing Medux tutorials demonstrate Codex and Claude workflows rather than a Gemini integration.
The Codex MCP video-editing tutorial shows the signed-upload, task creation, polling, and download pattern. The voice cloning and TTS tutorial shows another asynchronous operation with sensitive identity implications.
A safe orchestrator stores both the Gemini interaction ID and the Medux task ID, requests approval before upload or voice cloning, avoids duplicate submissions on reconnect, and validates the downloaded output. Managed infrastructure can simplify the loop, but durable state and responsibility still belong to the application.