Google beschreibt Agent Compute Engine (ACE) als Infrastruktur, in der ein separater Harness die Arbeit eines KI-Agenten steuert und eine isolierte microVM dessen Code und Werkzeuge ausführt. Eine microVM ist eine schlanke virtuelle Maschine mit eigener Ausführungsumgebung. Google will damit VM-ähnliche Isolation mit der Geschwindigkeit und Dichte von Containern verbinden.
ACE trennt Steuerung und Ausführung
Der Harness ruft das Modell auf, wählt die nächsten Schritte und schickt Befehle an die Sandbox. Dort laufen der Code, Kommandos und Browseraktionen des Agenten. Google zufolge erhält jede Agentensitzung eine eigene, persistente microVM.
Die Trennung teilt die Aufgaben klar auf: Der Harness entscheidet, was der Agent als Nächstes tun soll; die Sandbox führt diese Arbeit aus und gibt Ergebnisse zurück. Google entwickelte ACE nach eigener Darstellung zunächst für interne Agenten-Workloads. Dazu zählt das Unternehmen Anwendungen für Gemini und Antigravity sowie interne Bewertungs- und Reinforcement-Learning-Prozesse.
Identität, Gateway und inaktive Sitzungen
Google beschreibt ein Identitätsmodell, bei dem dauerhafte Zugangsdaten außerhalb der Sandbox bleiben. Der Sandbox-Gast soll weder Nutzerpasswörter und API-Schlüssel noch OAuth-Refresh-Tokens oder Dienstkontoschlüssel dauerhaft im Arbeitsspeicher oder auf dem Datenträger speichern. Auch auf den Instanz-Metadatenserver soll er nicht zugreifen können.
Für den Netzwerkverkehr erhält die Sandbox eine kurzlebige, auf SPIFFE basierende Agent Workload Identity. Ein externer Agent Gateway prüft laut Google die delegierte Berechtigung, die Identität des Agenten und des Knotens sowie die Richtlinien für ausgehenden Verkehr. Erst danach vermittelt das Gateway die Backend-Zugangsdaten während der Übertragung. Der Netzwerkverkehr läuft über vermittelte Verbindungen, nicht über eine gewöhnliche virtuelle Netzwerkschnittstelle oder direkten VPC-Zugriff.
Google unterscheidet vier Identitäten: die des Nutzers, die delegierte Identität des Agenten im Auftrag des Nutzers, die Agent Workload Identity und die Agent Workforce Identity. Für den Verkehr aus der Sandbox ist die kurzlebige Workload Identity maßgeblich; die delegierte Berechtigung bleibt in einem zentralen Autorisierungsdienst.
Wenn ein Agent einen Werkzeugaufruf beendet und auf den nächsten Schritt wartet, soll die Laufzeitumgebung den Zustand sichern. Der Host erstellt einen Checkpoint und gibt aktive Ressourcen frei, während die Sitzung zur späteren Fortsetzung erhalten bleibt. Google beschreibt diesen Zustand als Verbrauch von null aktiven Host-Ressourcen im Leerlauf.
Speicher und Sitzungszustand
Google teilt Agentendaten in drei Kategorien ein. Hyperdisk dient laut Unternehmen standardmäßig als Speicher, sofern nichts anderes angegeben ist; Google beschreibt die Daten als im Ruhezustand und bei der Übertragung verschlüsselt.
| Datenkategorie | Inhalt und Zweck | Speicherverhalten |
| Flüchtige Arbeitsdaten | Temporäre Scratch-Daten für laufende Aufgaben | Kurzlebig |
| Gemeinsam genutzte, schreibgeschützte Daten | Images, Toolchains und Paket-Caches | Gemeinsam nutzbar, nicht veränderbar |
| Persistente Arbeitsbereiche | Dauerhafte Nutzer-Arbeitsbereiche | Bleiben für spätere Sitzungen erhalten |
Für schnellere Starts beschreibt Google außerdem vorgewärmte Images, Direct Access (DAX) und Copy-on-Write-Klone. Unveränderte Speicherseiten aus Images, Laufzeitumgebungen, Bibliotheken und Binärdateien können demnach auf einem Host gemeinsam genutzt werden. Veränderte Seiten bleiben privat.
Gemeinsame Hardware für unterschiedliche Agentenaufgaben
Google beschreibt ACE als gemeinsam genutzten Hardware-Pool mit Richtlinien für die Verteilung der Aufgaben. Interaktive Anfragen sollen Vorrang erhalten; zeitlich flexible Auswertungs-, Forschungs- und Stapelaufgaben können freie Kapazitätsphasen nutzen und bei Bedarf zurücktreten.
Google ordnet vier Arten von Aufgaben der Plattform zu:
- Interaktive Agenten für Verbraucher und Unternehmen
- Dauerhafte Arbeitsbereiche für Softwareentwicklung
- Umfangreiche Auswertungen und Reinforcement Learning
- Sandbox-Backends für Google-Dienste
Die Vorstellung, traditionelle Rechenumgebungen seien für Hunderte Millionen Agenten im erforderlichen Kosten- und Latenzrahmen nicht ausgelegt, nennt Google als Motivation für ACE. Sie ist keine Kapazitätsangabe für ACE.
Managed Service oder Kubernetes-Laufzeit?
Ein Bericht von The New Stack unterscheidet ACE als verwalteten Google-Cloud-Dienst von Agent Substrate, einer Open-Source-Laufzeit für GKE und Kubernetes, die auf Agent Sandbox aufbaut. Agent Substrate kann dem Bericht zufolge microVMs oder gVisor zur Isolation einsetzen.
Für Teams liegt der praktische Unterschied im Betriebsmodell: Bei ACE betreibt Google die zugrunde liegende Infrastruktur. Bei Agent Substrate geht es um eine Kubernetes-orientierte Laufzeit. Die beschriebenen Optionen und Betriebsmodelle gehören zu Agent Substrate und nicht zu ACE.
Googles Ziel für die Cloud-Vorschau
Am 22. Oktober 2026 erklärte Google, eine Vorschau von ACE in Google Cloud sei für die kommenden Monate vorgesehen.
