Von KI-Agenten geschrieben, von mir kuratiert und geprüft.
Die Interactions API ist GA: bequem, aber wem gehört der Loop?
- Agentic Engineering
- Automation
Am 22. Juni hat Google die Interactions API in die allgemeine Verfügbarkeit überführt. Sie ist damit nicht mehr eine Option neben anderen, sondern laut Google die primäre Schnittstelle für Gemini-Modelle und -Agenten. Der Kern der Ankündigung sind Managed Agents: Ein einziger API-Aufruf stellt eine entfernte Linux-Sandbox bereit, in der ein Agent schlussfolgert, Code ausführt, im Web browst und Dateien verwaltet. Das ist bequem. Es verschiebt aber etwas Grundlegendes, und das lohnt einen nüchternen Blick. Die Orchestrierung wandert zum Anbieter.
Was kündigt Google an?
Die Interactions API war seit Dezember 2025 in der öffentlichen Beta. Mit der GA wird sie zum Standard in Google AI Studio, in der Gemini API und in der offiziellen Dokumentation. Für neue Projekte empfiehlt Google den Weg über diese Schnittstelle, die ältere generateContent-API bleibt unterstützt. Zwei Bausteine machen daraus den eigentlichen Build-Pfad für Agenten. Erstens die Managed Agents mit ihrer verwalteten Linux-Sandbox, wahlweise mit einem voreingestellten Antigravity-Agenten oder mit eigenen Agenten aus Instruktionen, Skills und Datenquellen. Zweitens die Hintergrundausführung: Wer auf einem Aufruf background=True setzt, lässt die Interaktion serverseitig asynchron laufen, auch über lange Strecken.
Managed Agents nehmen die Orchestrierung ab
Bisher war das Gerüst um ein Modell herum Ihre Aufgabe: die Sandbox, in der Code läuft, der Browser, das Dateisystem, die Schleife, die das alles zusammenhält. Genau diese Schleife ist der Ort, an dem ein Agent verlässlich oder unzuverlässig wird. Managed Agents nehmen Ihnen dieses Gerüst ab. Ein Aufruf, und die Maschine steht, mit Werkzeugen, die Google bereits verbunden hat: eingebaute Tools wie Suche und Maps lassen sich mit eigenen Funktionen mischen. Der Gewinn an Tempo ist real. Der Preis ist, dass Sie die Steuerung dessen, was zwischen den Modellaufrufen passiert, an den Anbieter abgeben.
Mit der Hintergrundausführung verschärft sich das. Ein Lauf, der serverseitig und über lange Strecken arbeitet, geschieht außerhalb Ihres Blickfelds. Was bequem ist, weil Sie nicht warten müssen, ist zugleich der Bereich, in dem ein Agent unbemerkt vom Kurs abkommt. Die Frage ist nicht, ob Managed Agents funktionieren. Sie ist, wo Sie noch hineinsehen, wenn die Schleife Ihnen nicht mehr gehört.
Wem gehört der Loop?
Schon bei Loop Engineering war der Punkt, dass die Verlässlichkeit eines Agenten nicht im Modell steckt, sondern in der Schleife, die ihn prompten, prüfen und stoppen lässt. Wer diese Schleife selbst baut, kontrolliert die Stellen, an denen gegengezeichnet wird. Managed Agents drehen das um. Die Schleife liegt beim Anbieter, und mit ihr die Entscheidung, wann der Agent ein Werkzeug nutzt, wann er weiterläuft und wann er hält.
Das ist die nüchterne Seite des Komforts. Eine API, die zum Standardpfad wird, zieht Ihre Architektur an sich. Eigene Agenten aus Instruktionen, Skills und Datenquellen sind bequem zu bauen und schwer wieder herauszulösen, weil die Sandbox, die Werkzeuganbindung und die Ausführung in der Plattform stecken. Das ist kein Argument gegen die Interactions API. Es ist ein Argument dafür, die Abhängigkeit bewusst einzugehen statt nebenbei.
Wo Managed Agents ihren Platz verdienen
Der Fortschritt ist praktisch, und es gibt gute Gründe, ihn zu nutzen. Für einen Prototyp, für eine eng umrissene Aufgabe, für Arbeit, die ohnehin im Google-Ökosystem lebt, spart eine verwaltete Sandbox echte Handgriffe. Behalten Sie die eigene Schleife dort, wo die Kontrolle über den Ablauf zählt: bei Aufgaben, die über Anbieter hinweg laufen sollen, bei unbeaufsichtigter Automatisierung, überall dort, wo Sie genau festlegen müssen, an welcher Stelle ein Mensch gegenzeichnet. Definieren Sie vorab, was Sie an die Plattform abgeben und was bei Ihnen bleibt. Die Fähigkeiten kommen vom Anbieter, die Verantwortung für den Loop bleibt Ihre.