Google’s launch of Managed Agents in the Gemini API matters for a reason that goes beyond a product announcement: it suggests the company wants to sell not only models, but the operational layer that makes agents usable in the real world.
That distinction is important. For the last two years, “agent” demos have often been less about model intelligence than about engineering stamina. If a developer wanted something that could reason, call tools, browse the web, execute code, manipulate files, and keep state across multiple turns, the work usually sprawled outward. You needed orchestration logic, sandboxing, permissions, environment management, persistence, and plenty of glue code to hold the loop together. The model was only one piece of the system.
Google is now trying to absorb more of that burden into the platform itself.
The centerpiece is the new Antigravity agent in the Gemini API, available through the Interactions API and Google AI Studio. According to Google, a single call can provision a secure remote Linux environment where the agent can reason, plan, use tools, execute code, browse the web, and manage files. Follow-up calls can reuse the same environment, which means files and session state can persist across interactions rather than disappearing after every prompt.
That may sound like a tidy feature list, but the more consequential story is structural: Google is productizing agent infrastructure as a managed service.
What Google is actually shipping
The official framing is straightforward. Managed Agents let developers run agents in Google-hosted cloud sandboxes instead of building the runtime themselves. Antigravity is the first general-purpose version of that approach, and Google says it is powered by Gemini 3.5 Flash.
On the Antigravity documentation page, Google describes the agent as a general-purpose managed agent that can reason, execute code, manage files, and browse the web inside a secure Linux sandbox hosted by Google. By default, the agent can use code execution, Google Search, and URL Context, while filesystem capabilities are enabled when the remote environment is specified. In practice, that means the agent is not just generating text about actions it might take; it is operating inside an environment where it can actually perform them.
That difference is still easy to underestimate. Much of the frustration around agents comes from the gap between an LLM that can describe a workflow and a system that can carry one out reliably. A managed environment narrows that gap because it gives the model a place to act.
Google is also pushing a declarative approach to agent building. Instead of asking developers to write large amounts of orchestration code, the company says custom managed agents can be defined in markdown files such as AGENTS.md and SKILL.md. Developers can extend Antigravity with their own instructions, skills, and data, then register that setup as a managed agent.
That is an appealing pitch because it reframes agent development as configuration and composition rather than infrastructure assembly.
Why this is more than a convenience feature
The cleanest way to understand Managed Agents is to ask what Google is choosing to commoditize.
The answer is: a big chunk of the agent stack that many teams have been rebuilding from scratch.
For a long stretch of the current AI cycle, building “real” agents meant stitching together a model API, a tool loop, a sandbox, file handling, network access, state management, and some custom rules for retries and control flow. Every team made roughly the same architectural decisions, usually with different wrappers and different failure modes. The result was a lot of duplicated effort hidden behind flashy front-end demos.
Managed Agents imply that Google sees this repetition as a platform opportunity. If developers increasingly want agents that can do work rather than just chat, then the hard part is not merely serving tokens. It is running a constrained, inspectable, persistent execution environment tied to a model that knows how to use it.
That is what makes this launch notable. Google is not only competing on model quality; it is moving up the abstraction ladder and saying the harness itself is part of the product.
If this works, it could reduce one of the biggest barriers to agent adoption: the engineering overhead required to make autonomous workflows feel production-ready. Developers would spend less time wiring up sandboxes and tool permissions and more time defining what the agent should do.
That is a strong value proposition, especially for smaller teams that do not want to become accidental infrastructure companies.
The real appeal is operational, not philosophical
There is a temptation to read every agent release as a statement about artificial generality. This one is more practical than that.
The attraction of Managed Agents is not that they promise some dramatic leap in machine capability. It is that they package a series of unglamorous but essential operational components behind one interface. The secure Linux sandbox matters. Code execution matters. File management matters. Session persistence matters. Tool integration matters. These are the things that turn a clever prompt into a repeatable workflow.
Google itself indirectly acknowledges this in the announcement. The company notes that production-grade agents have required complex infrastructure and isolated sandboxes that developers had to scaffold and manage as they prepared to scale. Managed Agents are supposed to abstract that complexity away.
That is the right target. The biggest bottleneck for many agent products is not imagination; it is operational friction.
The markdown angle is clever
The AGENTS.md and SKILL.md approach is also worth taking seriously. It sounds minor, but it points to a useful design instinct: treat agents as versionable artifacts.
Markdown-defined agents are legible. They are easy to diff, review, and keep in source control. They offer a more portable mental model than deeply embedded orchestration code, especially for teams where product, engineering, and prompt design overlap. In the best case, they could make agent behavior easier to inspect and iterate on.
Of course, there is a tradeoff. Simplicity at the definition layer does not eliminate complexity underneath. A markdown file can express instructions and skills, but reliability still depends on the underlying harness, tool permissions, sandbox behavior, and model judgment. Declarative packaging is helpful, but it does not magically solve the harder problem of making agent outputs consistent and safe.
So the markdown story is promising, but it should be understood as an interface improvement, not a guarantee of robust behavior.
Where skepticism is still warranted
Managed infrastructure solves some problems, not all of them.
A secure remote sandbox is better than pretending an agent can operate safely without one, but developers will still care about visibility, control, cost, latency, and failure handling. The more work Google takes over, the more important those questions become. If an agent has a multi-step tool loop, writes files, browses live sources, and persists state, then observability is not optional. Developers will want to know what happened, why it happened, and how to constrain it.
There is also the usual platform concern: convenience can create dependency. The more an application is built around a provider-specific managed harness, the harder it may become to move elsewhere later. That does not make the model wrong. It just means the economic logic is obvious. Google is making the Gemini API more valuable by bundling the execution layer around it.
That is smart platform strategy. It is not neutral.
Still, even skepticism should acknowledge the practical merit here. Agent development has been full of bespoke scaffolding that probably should become infrastructure. If Google can make that layer easier to use without making it opaque or brittle, Managed Agents could save real time for developers building serious applications.
Conclusion
Managed Agents in the Gemini API are significant because they shift the conversation from “what can the model say?” to “what parts of the agent stack should be native platform services?”
Google’s answer is increasingly ambitious: not just inference, but the sandbox, the tool loop, the file system, the browsing layer, the session lifecycle, and even the developer-facing format for defining agents. Antigravity is the clearest expression of that bet so far.
There is no reason to treat this as magic. It will not eliminate the hard parts of reliability, governance, or product design. But it does address a real pain point that the agent market has repeatedly tried to paper over: too much of the work has lived outside the model, in infrastructure every team had to assemble for itself.
By turning that infrastructure into a managed service, Google is making a more grounded claim than most agent announcements do. It is saying the future of agents may depend less on ever grander demos and more on who provides the best working runtime for them.
