Gemini API managed agents explained: what Google launched

Google’s new managed agents in the Gemini API handle a problem plenty of development teams have hit: how do you go from a chatbot to software that plans a task, calls tools and executes code, without building the whole control layer yourself? The pitch is straightforward — define an agent, describe how it should behave, run it through an API. Less stitching runtime components together by hand.

The company is no longer selling the Gemini API as a simple model endpoint. It is pushing toward agents — software systems that reason through a sequence of steps and use approved tools to finish a job — inside a platform that Sundar Pichai said now serves 8.5 million developers a month and moves 19 billion tokens per minute. For Australian software teams deciding whether to build their own agent stack or rent more of it from a vendor, the shift is practical: less orchestration code to write and maintain, a faster path from prototype to a working service.

What Google means by a managed agent

An agent, here, isn’t just a chat window. It is software that interprets a goal, decides what step comes next, calls a tool or executes code, then uses that result to decide what to do after that. A managed agent means Google hosts more of the runtime. The launch post says developers define the agent with files such as AGENTS.md, which spells out the role and instructions, and SKILL.md, which packages reusable capabilities the agent can call.

Google’s language is deliberately operational. Rather than standing up an agent loop, wiring tool calls, handling code execution and maintaining session state on their own, developers call the Interactions API and let Google’s harness run the job inside what the company describes as an isolated, ephemeral Linux environment. Ephemeral, here, means short-lived: the environment is created for the task, run, then discarded. It is one way to limit what a team has to manage directly.

Then there is the sandboxed harness — a restricted execution environment that contains the agent while it runs code and uses tools. That does not remove the need for security review or approval controls. But it shows where Google thinks the pain point sits: plenty of teams want agent behaviour without also owning every server, runtime and execution policy behind it.

“With a single call, you can now spin up an agent that reasons, uses tools and executes code in an isolated, ephemeral Linux environment.”
— Google, Introducing Managed Agents in the Gemini API

Google is selling orchestration, not just intelligence. An orchestration layer is the glue code that decides when the model should think, when it should call a tool, what context it should carry forward and when it should stop. That layer is often where agent demos become production headaches. Managed agents do not remove the need for engineering judgement. They do move more of the repeated plumbing into Google’s platform.

How the feature works in practice

The developer documentation is clear that Google’s version isn’t meant to be a sealed black box. The sample “Antigravity” agent can be extended with a team’s own instructions, skills and data: a developer can give the agent a narrower job, connect it to approved capabilities and shape the rules it follows when it acts.

“You can extend the Antigravity agent with your own instructions, skills, and data.”
— Google AI for Developers, Building Managed Agents

“Managed” does not mean generic. Teams still have to decide what the agent is allowed to do, which tools it can reach and what information it should use. A startup building internal support tooling will want different skills and guardrails from a bank experimenting with developer automation. The documentation suggests Google wants the hosted runtime flexible enough for both, while keeping the core execution model on Google’s side.

The files split behaviour from infrastructure. AGENTS.md sets the role and operating instructions. SKILL.md lets developers package functions the agent can call more than once. For teams that want repeatable behaviour across projects, that separation is useful: standardise how an agent should act without rebuilding the execution stack for each new workflow.

Why the launch matters beyond Google I/O

Google wants the Gemini API to look more like an application layer and less like raw access to a model. That argument runs through the company’s I/O 2026 developer messaging and its Google Cloud follow-up. The model is still the engine, but the commercial value moves higher up the stack once developers can ship working tools, workflows and assistants without assembling every subsystem themselves.

Google Cloud condensed the pitch to a slogan: “manage the mission, not the machine” in its I/O '26 cloud post. Marketing language, but it captures the product decision. Google is betting developers will pay for fewer operational chores if the hosted runtime can still be customised enough to fit real software projects.

The launch also lines up with the rest of Google’s agent push. The company’s I/O 2026 developer highlights post paired managed agents with Gemini 3.5 Flash, which Google said is four times faster than other frontier models. Speed matters more in agent workflows than in plain chat. An agent may make several model calls inside one task; a faster model reduces the wait on each step, so the total job finishes sooner and the workflow feels less brittle.

For Australian developers and software teams, the launch matters most if it changes build economics. Running an agent system in-house can mean more infrastructure, more monitoring and more failure points, especially once code execution and tool use enter the picture. A managed runtime does not erase those risks. But it can shrink the amount of platform work a team must own before it learns whether an agent-based feature is worth taking to production.

That is why this launch has longer life than a conference headline. Search demand for “gemini api” may spike around Google I/O, but the more durable question is whether Google’s tooling now saves enough engineering time to win developer adoption. Managed agents are one of the clearest signs that Google wants to answer that question with hosted software, not just better models.

What to watch next is the follow-through in the documentation and product updates. If Google keeps adding clearer controls, richer skills and tighter links between the Gemini API and Google Cloud tooling, managed agents could become a meaningful on-ramp for teams that want action-taking AI systems without building every layer alone. If the feature remains easier to demo than to govern, developers may keep treating it as a useful experiment rather than the centre of their stack.