This is a submission for the
That may sound less glamorous than a new model, but that's also exactly why it matters. Models are the engines, while Managed Agents are the chassis, gearbox, dashboard, pit crew, and the emergency brake. It is the layer that turns “the model can reason and use tools” into “my application can ask an agent to do useful work, observe what it did, preserve state, collect artifacts, and continue from there.”
That is a very different product. And for developers, it may be the more important one.
The Real Bottleneck was Never Intelligence
For the last couple of years, agent demos have followed a mundane script:
- A model receives a task.
- It calls the required tools.
- It plans and writes code.
- Runs the code and inspects the result.
- Fixes its own mistake.
Everyone nods. But then, a developer tries to build the same thing in production and immediately runs into the actual problem.
The hard part is not only getting the model to think. The hard part is giving it a place to work. A serious agent needs a runtime. It needs a sandbox, files, tool boundaries, memory or state. It needs observable intermediate steps and controls for network access, credentials, cost, and cleanup, not to add developer ergonomics that do not require every team to rebuild the same orchestration layer from scratch.
This is the gap Managed Agents tries to close.
Google’s announcement is not plainly: “Gemini can use tools.” The more interesting claim is this: Google is packaging the agent loop itself as a managed developer primitive.
With Managed Agents, the Antigravity managed agent can run inside a Google-hosted Linux environment, execute code, manage files, use web access, preserve environment state, and return observable execution traces through the Interactions API. That shifts the developer’s job.
Instead of building the whole runtime yourself, you can start from a hosted agent environment and focus on the product boundary around it.
That boundary is where the real engineering begins.
The developer sends a task through the Interactions API. The managed agent receives it, reasons through the task, uses available tools, reads or writes files inside the remote environment, and returns both the final output and structured information about execution.
The key is state.
Google gives developers two major handles:
| Handle | Purpose |
|---|---|
previous_interaction_id | Continue the conversation |
environment_id | Continue working in the same sandbox |
That second handle is especially important. Without environment persistence, every agent task becomes a one-shot performance. With environment persistence, the agent can build on previous files and results.
Turn one can create an analysis. Turn two can improve the chart. Turn three can package the output. Turn four can audit the final files.
That feels less like prompting a chatbot and more like supervising a remote worker with a shell.
A Minimal API Pattern
An agent that runs code, reads files, searches the web, and creates artifacts cannot be a black box. Developers need to know what happened. Not in a vague “the agent analyzed your data” way. They need step traces. They need to inspect tool calls. They need to see what files were touched, what commands ran, what sources were consulted, and where the process failed.
Agent observability has three jobs:
| Job | Why it matters |
|---|---|
| Debugging | You need to know where the process went wrong |
| Trust | Users are more likely to accept output when they can inspect the path |
| Governance | Teams need records for security, compliance, and review |
This is another reason the Interactions API matters. Agentic applications are not only about final text, they are about the work behind the text. A good platform needs to expose that work.
Pricing and Control
Managed Agents is useful, but agentic workflows can spend tokens quickly. A normal chat call is usually bounded by input and output. An agent run may include planning, tool calls, file inspection, code execution, error recovery, generated artifacts, and multiple rounds of iteration.
That means cost control is a product requirement, not an accounting afterthought.
A real integration should include:
| Control | Why it helps |
|---|---|
| Narrow task scopes | Prevents sprawling behavior |
| Budget limits | Stops runaway usage |
| Streaming visibility | Lets users cancel bad runs early |
| Clear stop conditions | Reduces unnecessary iteration |
| Human approval gates | Protects sensitive actions |
| Environment cleanup | Avoids stale or risky artifacts |
Security: A Useful Power Still Needs a Fence
Managed Agents is exciting because it gives the model a place to act. That is also why it deserves caution. An agent that can read private files, process untrusted content, browse the web, and call tools has a real attack surface. The risky combination is:
- Access to private data
- Exposure to untrusted instructions or content
- Ability to communicate externally or take actions
That combination can create prompt injection, data exfiltration, and tool misuse risks. A safer architecture should wrap the managed agent in policy checks, scoped files, network allowlists, human review, and audit logs.
Managed Agents in the Gemini API:
Managed Agents quickstart:
AI Studio Agents documentation:
WebMCP early preview:
SOCIAL SHARE CARD GENERATOR