Gemini API: Managed Agents erhalten Remote MCP

Google erweitert die Managed Agents in der Gemini API um asynchrone Hintergrundausführung, direkte Remote-MCP-Anbindungen, eigene Funktionsaufrufe und aktualisierbare Zugangsdaten. Damit wird aus einem einzelnen Agentenaufruf eher ein verwalteter Hintergrundprozess als eine lange, fragile HTTP-Anfrage. Der wichtige Vorbehalt: Der Antigravity-Agent und die Interactions API bleiben laut Google im Preview-Status, und komplexe Aufgaben können bereits in einer einzigen Interaktion mehrere Millionen Token verbrauchen.

Google hat die Erweiterungen am 7. Juli 2026 angekündigt. Sie richten sich vor allem an Entwickler und Builder, die Agenten nicht nur demonstrieren, sondern in länger laufende Workflows einbauen wollen. Managed Agents übernehmen dabei Planung, Tool-Nutzung, Code-Ausführung, Dateiverwaltung und Webzugriff in einer von Google betriebenen Linux-Sandbox.

Was Google an den Managed Agents geändert hat

Die Neuerung ist kein neues Gemini-Modell, sondern eine Erweiterung der Agenten-Laufzeit rund um die Gemini API. Google bündelt die Funktionen in der Interactions API. Ein Client startet eine Interaktion über einen einheitlichen Endpunkt; der verwaltete Agent führt anschließend mehrere Schritte aus und liefert Beobachtungen, Statusinformationen und Ergebnisse zurück.

Vier Erweiterungen stehen im Mittelpunkt:

• Background Execution: Lange Aufgaben laufen asynchron auf Googles Servern weiter.
• Remote MCP: Der Agent kann externe Werkzeuge über entfernte Model-Context-Protocol-Server aufrufen.
• Custom Functions: Eigene Funktionen lassen sich neben den eingebauten Sandbox-Werkzeugen verwenden.
• Credential Refresh: Kurzlebige Tokens oder rotierte Schlüssel können für eine bestehende Umgebung erneuert werden.

Diese Kombination adressiert ein reales Architekturproblem. Ein Agent, der Repositories untersucht, Tests ausführt, Informationen recherchiert oder größere Datenmengen verarbeitet, passt schlecht in das klassische Muster „Anfrage senden, Verbindung offen halten, Antwort abwarten“. Netzwerkunterbrechungen, Timeouts und Neustarts des Clients werden sonst schnell zum Betriebsrisiko.

Die offizielle Grafik nennt die beiden sichtbarsten Änderungen: Background Execution und Remote MCP. Technisch relevant ist aber gerade das Zusammenspiel mit eigenen Funktionen und erneuerbaren Zugangsdaten, weil dadurch länger laufende Agenten nicht auf eine rein abgeschlossene Google-Sandbox beschränkt bleiben.

Background Execution löst das Timeout-Problem

Bei der neuen Hintergrundausführung startet der Client eine Interaktion und erhält sofort eine ID. Danach kann die Anwendung den Status abfragen, Fortschritt streamen oder sich später erneut verbinden. Der Agent arbeitet währenddessen auf Googles Infrastruktur weiter.

Das ist mehr als eine Komfortfunktion. Für produktive Agenten-Workflows entstehen daraus drei Vorteile:

1. Der Client muss keine lange HTTP-Verbindung offen halten. Ein Browser-Tab, eine mobile App oder ein Worker kann beendet werden, ohne dass die Aufgabe zwangsläufig abbricht.
2. Fortschritt wird beobachtbar. Anwendungen können Zustände wie „in Bearbeitung“, „abgeschlossen“ oder „Aktion erforderlich“ in einer Oberfläche darstellen.
3. Wiederaufnahme wird einfacher. Die Interaktions-ID dient als Referenz, über die ein Ergebnis später erneut geladen werden kann.

Der Preis dafür ist serverseitige Speicherung. Laut aktueller Google-Dokumentation werden Interaktionen standardmäßig gespeichert. Im Paid Tier beträgt die Aufbewahrungszeit 55 Tage, im Free Tier einen Tag. Bezahlte Projekte können in AI Studio kürzere Fristen von 7, 14, 28 oder 55 Tagen konfigurieren. Interaktionen lassen sich außerdem gezielt löschen.

Wer Speicherung deaktiviert, verliert jedoch einen Teil der neuen Funktionalität: Google weist darauf hin, dass der zustandslose Modus nicht mit Background Execution kompatibel ist. Auch eine Fortsetzung über die vorherige Interaktions-ID ist dann nicht möglich. Für sensible Workloads ist das keine Nebensache, sondern eine Architekturentscheidung zwischen Komfort, Nachvollziehbarkeit und Datenminimierung.

Remote MCP verbindet die Sandbox mit externen Werkzeugen

Mit Remote MCP kann ein Managed Agent entfernte MCP-Server als Werkzeuge registrieren. Dadurch kann er beispielsweise auf interne Telemetrie, Datenbanken, Dokumentensysteme oder spezialisierte APIs zugreifen, ohne dass Entwickler für jedes Werkzeug eine eigene Proxy-Schicht in den Agentenloop einbauen müssen.

Der Agent kann Remote-MCP-Werkzeuge mit Googles eingebauten Fähigkeiten kombinieren. Ein Workflow könnte öffentliche Informationen suchen, Daten in der Sandbox analysieren und anschließend einen internen MCP-Endpunkt nach Betriebsmetriken fragen. Die Orchestrierung bleibt innerhalb einer Interaktion sichtbar.

Die Funktion hat allerdings klare Grenzen:

• Laut Google wird für Remote MCP derzeit Streamable HTTP unterstützt, nicht der ältere Server-Sent-Events-Transport.
• Der Name eines MCP-Servers muss laut Dokumentation streng kleingeschrieben und alphanumerisch sein; Großbuchstaben können einen unspezifischen Fehler 400 auslösen.
• Externe Werkzeuge sollten nur mit minimal notwendigen Berechtigungen angebunden werden.
• Ein MCP-Server ist eine zusätzliche Vertrauensgrenze. Seine Antworten können fehlerhaft, manipuliert oder für den Agenten missverständlich sein.

Die direkte MCP-Unterstützung ist strategisch relevant. Google behandelt MCP nicht nur als lokale Entwicklerkonvention, sondern als Schnittstelle für cloudverwaltete Agenten. Das erhöht die Portabilität von Werkzeugen, beseitigt aber nicht die Verantwortung für Authentifizierung, Eingabevalidierung, Netzwerkregeln und Freigaben.

Wer MCP zunächst in einer stärker kontrollierten Browser-Umgebung einsetzen will, findet in unserem Beitrag zum Safari MCP Server von Apple einen anderen Ansatz: Dort steht der browsernahe Werkzeugzugriff im Vordergrund, während Google die Ausführung in eine entfernte Agenten-Sandbox verlagert.

Eigene Funktionen ergänzen die serverseitigen Werkzeuge

Remote MCP ist nicht der einzige Weg zu externen Fähigkeiten. Google erlaubt auch Custom Function Calling neben eingebauten Werkzeugen wie Code-Ausführung oder Google Search.

Der Unterschied liegt im Ausführungsort. Eingebaute Werkzeuge laufen automatisch auf Googles Seite. Bei einer eigenen Funktion wechselt die Interaktion in einen Zustand, der eine Aktion des Clients verlangt. Die Anwendung führt die lokale Geschäftslogik aus und sendet das Ergebnis anschließend an die Interaktion zurück.

Das ist für kontrollierte Schreiboperationen sinnvoll. Ein Agent kann etwa Informationen sammeln und einen Vorschlag vorbereiten, während das eigentliche Ändern eines Datensatzes, Auslösen einer Zahlung oder Versenden einer Nachricht in der Anwendung bleibt. Der Client kann dort Berechtigungen prüfen, Parameter validieren und eine menschliche Freigabe verlangen.

Für robuste Implementierungen ist entscheidend, Funktionsaufrufe nicht blind auszuführen. Entwickler sollten mindestens folgende Schutzschichten vorsehen:

• Eingaben gegen ein enges Schema validieren.
• Schreibende und lesende Funktionen klar trennen.
• Berechtigungen pro Funktion und Nutzerkontext prüfen.
• Idempotenz für wiederholte Aufrufe sicherstellen.
• Kritische Aktionen protokollieren und gegebenenfalls bestätigen lassen.

Der Agent entscheidet, wann er eine Funktion anfordert. Die Anwendung entscheidet weiterhin, ob und wie dieser Aufruf tatsächlich ausgeführt wird. Diese Trennung ist eines der wichtigsten Sicherheitsmerkmale der Architektur.

Credential Refresh hält lange Workflows am Leben

Kurzlebige Zugriffstokens sind sicherer als dauerhaft gültige Schlüssel, passen aber schlecht zu Agenten, die über längere Zeit oder mehrere Interaktionen hinweg arbeiten. Google erlaubt deshalb, die Netzwerkkonfiguration einer bestehenden Umgebung zu aktualisieren.

Dabei kann eine Anwendung ein vorhandenes Environment weiterverwenden und neue Zugangsdaten übergeben. Das Dateisystem, installierte Pakete und geklonte Repositories bleiben laut Google erhalten, während die Netzwerkregeln beziehungsweise Header-Transformationen ersetzt werden.

Das reduziert den Druck, Agenten mit langlebigen Geheimnissen auszustatten. Gleichzeitig verschiebt es die Verantwortung auf den aufrufenden Dienst: Er muss Tokens rechtzeitig erneuern, sauber auf die erlaubten Domains begrenzen und verhindern, dass Zugangsdaten an unerwartete Ziele gesendet werden.

Google beschreibt dafür eine Egress-Proxy-Logik. Zugangsdaten werden als Header-Transformationen an erlaubte Netzwerkziele gebunden und sollen nicht direkt in der Sandbox sichtbar sein. Trotzdem gilt das Least-Privilege-Prinzip: Ein Agent kann die ihm zugänglichen Berechtigungen nutzen. Ein breit berechtigtes Servicekonto bleibt deshalb ein breites Risiko, auch wenn der Schlüssel technisch verborgen ist.

Was in Googles Managed-Agent-Sandbox läuft

Der allgemeine Antigravity-Agent wird laut Dokumentation von Gemini 3.5 Flash angetrieben und verwendet denselben Agenten-Harness wie die Antigravity-Entwicklungsumgebung. Die Modell-ID in den aktuellen Beispielen trägt weiterhin die Bezeichnung antigravity-preview-05-2026, was den Preview-Charakter unterstreicht.

Eine Interaktion kann eine Linux-Umgebung bereitstellen oder eine vorhandene Umgebung wiederverwenden. Google nennt folgende Fähigkeiten:

• Ausführung von Bash-, Python- und Node.js-Aufgaben
• Installation von Paketen
• Lesen, Schreiben und Verwalten von Dateien
• Google Search und Abruf von Webseiten
• automatische Kontextkomprimierung bei langen Abläufen
• Wiederverwendung einer Umgebung über mehrere Interaktionen

Die Umgebungen basieren laut Google auf Ubuntu und enthalten unter anderem Python 3.12 sowie Node.js 22. Nach sieben Tagen ohne Aktivität werden sie dauerhaft gelöscht. Virtuelle Maschinen können nach kurzer Inaktivität herunterfahren und beim nächsten Zugriff mit dem erhaltenen Zustand wiederhergestellt werden; dabei ist ein Kaltstart möglich.

Wichtig ist ein Sicherheitsdetail: Der ausgehende Netzwerkzugriff ist standardmäßig nicht auf einzelne Domains beschränkt. Google empfiehlt ausdrücklich eine Allowlist. Entwickler sollten diese Empfehlung als Standard und nicht als optionale Härtung behandeln. Ein Agent mit Code-Ausführung, Webzugriff und weitreichenden Zugangsdaten besitzt sonst eine unnötig große Angriffsfläche.

Kosten: Agentenloops können Millionen Token verbrauchen

Managed Agents werden nutzungsbasiert abgerechnet. Maßgeblich sind die Token des zugrunde liegenden Gemini-Modells sowie kostenpflichtige Werkzeuge. Die Rechenleistung der Umgebung, also CPU, Arbeitsspeicher und Sandbox-Ausführung, wird laut Google während der Preview nicht berechnet.

Die Tokenkosten können dennoch deutlich höher sein als bei einer einzelnen Chat-Antwort. Google nennt für typische Aufgaben folgende Größenordnungen:

• Recherche und Informationssynthese: etwa 100.000 bis 500.000 Eingabetoken und typische Kosten von 0,30 bis 1,00 US-Dollar
• Dokument- und Inhaltserstellung: etwa 100.000 bis 500.000 Eingabetoken und 0,30 bis 1,30 US-Dollar
• Prozess- und Systemdesign: etwa 100.000 bis 400.000 Eingabetoken und 0,25 bis 0,80 US-Dollar
• Datenverarbeitung und Analyse: etwa 300.000 bis 3 Millionen Eingabetoken und 0,70 bis 3,25 US-Dollar

Google ergänzt, dass komplexe agentische Workflows mit vielen Tool-Aufrufen 3 bis 5 Millionen Token in einer Interaktion ansammeln und bis zu ungefähr 5 US-Dollar kosten können. Außerdem seien typischerweise 50 bis 70 Prozent der Eingabetoken gecacht.

Diese Werte sind Herstellerangaben und nicht unabhängig verifiziert. Sie zeigen aber die zentrale Kostenlogik: Nicht die Laufzeit der virtuellen Maschine, sondern die wiederholten Modellschritte dominieren die Rechnung. Ein Agent, der plant, Werkzeuge aufruft, Ergebnisse erneut einliest und seine Strategie korrigiert, verarbeitet denselben Kontext mehrfach.

Für Entwickler folgt daraus eine praktische Messpflicht. Pro Interaktion sollten mindestens Tokenverbrauch, Zahl der Tool-Aufrufe, Laufzeit, Fehlversuche, Cache-Anteil und Kosten erfasst werden. Ohne diese Telemetrie lässt sich ein erfolgreicher Prototyp nicht seriös auf größere Nutzung hochrechnen.

Preview-Status und aktuelle Einschränkungen

Der Zugang ist breiter als eine geschlossene Partner-Preview: Google beschreibt den Antigravity-Agenten als Preview über die Interactions API in Google AI Studio und der Gemini API. Es gibt damit einen dokumentierten Entwicklerzugang. Produktionsreife im Sinne stabiler Schnittstellen garantiert Google jedoch nicht.

Die aktuelle Dokumentation nennt mehrere Einschränkungen:

• Antigravity-Agent und Interactions API befinden sich in der Preview; Funktionen und Schemas können sich ändern.
• Strukturierte Ausgaben werden vom Antigravity-Agenten nicht unterstützt.
• Konfigurationsparameter wie Temperatur, Top-p, Top-k, Stop-Sequenzen und maximale Ausgabetoken werden nicht unterstützt.
• File Search, Computer Use und Google Maps stehen in diesem Agenten noch nicht zur Verfügung.
• Remote MCP unterstützt derzeit kein SSE.
• Background Execution setzt gespeicherte Interaktionen voraus.

Für Experimente, interne Tools und kontrollierte Agentenaufgaben ist das Angebot bereits konkret nutzbar. Für langfristig stabile Produktionssysteme sollten Entwickler jedoch mit API-Änderungen rechnen, Abstraktionsschichten einziehen und Fehlerpfade für abgebrochene oder wiederholte Interaktionen testen.

Wie sich Googles Ansatz im Agentenmarkt einordnet

Google verschiebt die Grenze zwischen Modell-API und Agentenplattform. Statt nur Tool Calling bereitzustellen, übernimmt der Anbieter auch Sandbox, Zustand, Dateisystem, Hintergrundlauf und Teile der Beobachtbarkeit. Das reduziert Infrastrukturarbeit, erhöht aber die Bindung an Googles Interactions API und deren Lebenszyklus.

Der entscheidende Unterschied zu einem selbst orchestrierten Agenten ist die Verantwortungsverteilung:

• Google betreibt Modellloop, Sandbox und gespeicherten Interaktionszustand.
• Entwickler definieren Werkzeuge, Netzwerkgrenzen und Freigaberegeln.
• Remote MCP standardisiert einen Teil der Tool-Anbindung.
• Eigene Funktionen halten kontrollierte Logik auf der Client-Seite.

Damit positioniert sich die Gemini API zwischen einer klassischen Modell-API und einer vollständig verwalteten Agentenplattform. Für Builder ist der Ansatz attraktiv, wenn schnelle Integration und eine fertige Laufzeit wichtiger sind als vollständige Kontrolle über Umgebung, Speicherung und Modellorchestrierung.

Was Entwickler jetzt testen sollten

Ein sinnvoller Test sollte nicht mit einer geschäftskritischen Schreiboperation beginnen. Besser ist ein begrenzter, reproduzierbarer Workflow, etwa die Analyse eines Test-Repositories oder die Auswertung synthetischer Telemetriedaten.

Dabei sollten Entwickler systematisch prüfen:

1. Unterbrechung und Wiederaufnahme: Läuft eine Hintergrundaufgabe weiter, wenn der Client neu startet?
2. MCP-Fehler: Wie reagiert der Agent auf Timeouts, ungültige Antworten oder fehlende Berechtigungen eines Remote-Servers?
3. Funktionsfreigaben: Bleiben schreibende Aktionen zuverlässig im kontrollierten Client-Pfad?
4. Tokenbudget: Wie stark steigen Kosten mit zusätzlichen Werkzeugschritten und Korrekturschleifen?
5. Datenhaltung: Welche Interaktionen werden gespeichert, wann gelöscht und welche Inhalte gehören nicht in diesen Zustand?
6. Netzwerkgrenzen: Funktioniert der Workflow mit einer engen Domain-Allowlist statt offenem Internetzugriff?

Wer bereits mit Googles Entwicklerwerkzeugen arbeitet, kann die neue Agentenebene außerdem neben der Gemini CLI betrachten. Die CLI ist eine interaktive Oberfläche für Entwicklungsaufgaben; Managed Agents zielen dagegen auf programmatisch gestartete, serverseitig weiterlaufende Workflows.

Fazit: Mehr Laufzeit, aber auch mehr Verantwortung

Die Erweiterung macht die Managed Agents in der Gemini API technisch deutlich vollständiger. Background Execution beseitigt die Abhängigkeit von langen Client-Verbindungen, Remote MCP öffnet die Sandbox für standardisierte externe Werkzeuge, Custom Functions halten sensible Logik im eigenen System, und Credential Refresh unterstützt kurzlebige Zugangsdaten.

Der Nutzen ist real, aber die Grenzen sind ebenso konkret: Preview-Schnittstellen, verpflichtende Speicherung für Hintergrundläufe, mehrere nicht unterstützte Werkzeuge und potenziell millionenfache Tokenverarbeitung pro Aufgabe. Managed bedeutet nicht automatisch sicher, günstig oder wartungsfrei.

Für Entwickler lohnt sich jetzt ein kontrollierter Test mit klaren Netzwerkregeln, begrenzten Berechtigungen und vollständiger Kostenmessung. Wer die Agenten nur als größere Chat-Anfrage behandelt, wird die eigentlichen Betriebsrisiken übersehen.

Häufige Fragen zu Managed Agents in der Gemini API

Was sind Managed Agents in der Gemini API?

Managed Agents sind von Google betriebene Agenten, die planen, Code ausführen, Dateien verwalten und Webinformationen abrufen können. Sie laufen in einer isolierten Linux-Sandbox und werden über die Gemini Interactions API gestartet.

Sind Googles Managed Agents öffentlich verfügbar?

Google bietet den Antigravity-Agenten als Preview über Google AI Studio und die Gemini API an. Der Zugang ist damit dokumentiert und nicht nur ausgewählten Partnern vorbehalten, die Schnittstellen und Funktionen können sich während der Preview aber ändern.

Was bringt Background Execution?

Background Execution lässt lange Agentenaufgaben serverseitig weiterlaufen, ohne eine HTTP-Verbindung dauerhaft offen zu halten. Anwendungen erhalten eine Interaktions-ID und können Status oder Ergebnis später abrufen.

Welche Einschränkungen hat Remote MCP bei Google?

Remote MCP unterstützt laut Google derzeit Streamable HTTP, aber keinen SSE-Transport. Außerdem gelten strenge Namensregeln für registrierte Server, und Entwickler müssen Berechtigungen sowie Netzwerkzugriff selbst absichern.

Wie teuer sind Managed Agents in der Gemini API?

Google rechnet Modelltoken und kostenpflichtige Werkzeuge ab; Sandbox-Rechenleistung ist während der Preview kostenlos. Laut Google liegen typische Aufgaben oft unter wenigen US-Dollar, komplexe Interaktionen mit 3 bis 5 Millionen Token können jedoch ungefähr 5 US-Dollar erreichen; diese Werte sind Herstellerangaben.

Primärquellen: Google-Ankündigung, Managed-Agents-Dokumentation, Antigravity-Agent-Dokumentation und Interactions-API-Dokumentation.