Managed Agents in der Gemini API. Was das Juli-Update ändert und was noch Vorschau ist

Ein Managed Agent ist ein Agent, den Google selbst betreibt. Ein einziger Aufruf der Interactions API startet eine abgeschottete Linux-Umgebung, lässt darin den Agenten arbeiten und liefert das Ergebnis zurück. Der Agent kann Code ausführen, Dateien anlegen, im Web suchen und Seiten lesen. Grundlage ist der Antigravity-Agent von Google, zum Start auf Basis von Gemini 3.5 Flash. Eigene Anweisungen und Fähigkeiten gibt man ihm über Dateien mit, etwa eine AGENTS.md.

Das Update vom 7. Juli 2026 brachte laut Google-Blog vier Dinge:

• Hintergrundläufe. Ein Agent kann Minuten arbeiten, ohne dass eine Verbindung offen bleiben muss. Man bekommt eine ID und fragt den Stand später ab.
• Anbindung an entfernte MCP-Server. Der Agent spricht damit auch mit eigenen Datenbanken und internen Schnittstellen.
• Eigene Funktionen. Werkzeuge, die nicht bei Google, sondern beim Aufrufer laufen. Der Agent hält an und wartet auf deren Ergebnis.
• Zugangsdaten erneuern. Ein abgelaufener Token lässt sich tauschen, ohne dass die Umgebung mit ihren Dateien verloren geht.

Managed Agents starteten im Mai 2026 als Vorschau. Auch die vier Erweiterungen aus dem Juli sind im Google-Blog ausdrücklich als Vorschau markiert. Die Dokumentation schreibt noch mit Stand 17. September 2026, dass sich Funktionen und Schemas ändern können. Allgemein verfügbar ist die Interactions API selbst, nicht die Managed Agents darauf.

Die Dokumentation nennt außerdem Grenzen, die man kennen sollte. Es gibt keine Versionierung der Agents, sie lassen sich nicht ineinander verschachteln, und bei einem gespeicherten Agent kann man das Modell beim Aufruf nicht wechseln.

Bisher hat man einen Agenten selbst zusammengesetzt. Ein Modell, ein paar Werkzeuge, eine Umgebung zum Ausführen, eine Schleife drumherum. Google nimmt davon den Teil ab, der am meisten Aufwand macht, nämlich die Umgebung. Das lohnt sich für Aufgaben, die offen sind und bei denen der Weg vorher nicht feststeht. Eine Recherche über mehrere Quellen, ein Bericht aus einer Tabelle, eine Datei, die erst umgebaut werden muss.

Für die meisten Prozesse im Unternehmen ist der Weg aber bekannt. Eine Anfrage kommt rein, wird geprüft, landet im CRM, jemand bekommt Bescheid. Dafür braucht es keinen Agenten, der jedes Mal neu überlegt. Ein fester Workflow ist dort billiger, schneller und leichter zu prüfen. Wir bauen solche Abläufe mit n8n und setzen ein Modell nur an die Stelle, an der wirklich etwas gelesen, eingeordnet oder formuliert werden muss.

1. 1

   Schnittstellen sauber schneiden

   Ein MCP-Server für Ihr CRM sollte nur das anbieten, was der Agent braucht. Lesen ja, Löschen nein. Dieselbe Regel gilt für Workflows in n8n.

2. 2

   Zugänge eng halten

   Eigene, eingeschränkte Zugänge für den Agenten, keine persönlichen Tokens. Die Erneuerung von Zugangsdaten hilft beim Betrieb, ersetzt aber keine Rechteplanung.

3. 3

   Datenfluss klären

   Der Agent läuft in einer Umgebung bei Google. Klären Sie vorher, welche Daten dort landen dürfen und unter welchen Bedingungen. Das ist keine Rechtsberatung, aber eine Frage, die vor dem Bau beantwortet sein muss.

4. 4

   Nicht auf Vorschau bauen

   Testen ja. Den Kernprozess daran hängen erst, wenn die Funktion allgemein verfügbar ist und Sie wissen, was sie kostet.

Der Rat aus der ersten Fassung bleibt trotzdem richtig. Wer seine Systeme heute über klar geschnittene Schnittstellen anbindet, kann später wählen, ob ein Workflow oder ein Agent darauf zugreift. Welcher Prozess sich überhaupt für den Anfang eignet, beschreibt dieser Beitrag.