Written by AI agents, curated and verified by me.
The Interactions API is GA: convenient, but who owns the loop?
- Agentic Engineering
- Automation
On 22 June, Google moved the Interactions API to general availability. It is no longer one option among others, but, in Google’s words, the primary interface for Gemini models and agents. The core of the announcement is managed agents: a single API call provisions a remote Linux sandbox where an agent reasons, executes code, browses the web, and manages files. That is convenient. But it shifts something fundamental, and that is worth a sober look. Orchestration moves to the vendor.
What is Google announcing?
The Interactions API had been in public beta since December 2025. With GA it becomes the default in Google AI Studio, in the Gemini API, and in the official documentation. Google recommends the path through this interface for new projects; the older generateContent API stays supported. Two building blocks turn it into the actual build path for agents. First, managed agents with their managed Linux sandbox, either with a default Antigravity agent or with custom agents built from instructions, skills, and data sources. Second, background execution: set background=True on any call and the interaction runs asynchronously on the server, even over long stretches.
Managed agents take over orchestration
Until now, the scaffolding around a model was your job: the sandbox where code runs, the browser, the file system, the loop that holds it all together. That loop is exactly where an agent turns reliable or unreliable. Managed agents take this scaffolding off your hands. One call, and the machine is up, with tools Google has already connected: built-in tools like Search and Maps can be mixed with your own functions. The gain in speed is real. The price is that you hand control of what happens between model calls to the vendor.
Background execution sharpens this. A run that works server-side and over long stretches happens outside your field of view. What is convenient, because you do not have to wait, is at the same time the area where an agent drifts off course unnoticed. The question is not whether managed agents work. It is where you can still look in, once the loop is no longer yours.
Who owns the loop?
Already with loop engineering the point was that an agent’s reliability does not sit in the model, but in the loop that prompts, checks, and stops it. Whoever builds that loop themselves controls the points where things get signed off. Managed agents invert this. The loop sits with the vendor, and with it the decision of when the agent uses a tool, when it carries on, and when it stops.
That is the sober side of the convenience. An API that becomes the default path pulls your architecture into itself. Custom agents built from instructions, skills, and data sources are convenient to build and hard to pull back out, because the sandbox, the tool wiring, and the execution live in the platform. This is not an argument against the Interactions API. It is an argument for taking on the dependency deliberately rather than in passing.
Where managed agents earn their place
The progress is practical, and there are good reasons to use it. For a prototype, for a tightly scoped task, for work that already lives in the Google ecosystem, a managed sandbox saves real steps. Keep your own loop where control over the flow matters: for tasks meant to run across vendors, for unattended automation, anywhere you need to set precisely where a human signs off. Define up front what you hand to the platform and what stays with you. The capabilities come from the vendor, the responsibility for the loop stays yours.