Agent Substrate: Akteure auf Worker statt Pods auf Knoten

Agent Substrate: Akteure auf Worker statt Pods auf Knoten

Agent Substrate beschreibt sich als Kernsystem eines Vorhabens, das auf Kubernetes aufsetzt und agentenähnliche Arbeitslasten verwaltet, um größeren Umfang und höheren Wirkungsgrad zu erreichen, als Kubernetes allein bietet, bei geringerer Latenz. Das Repository ist in Go geschrieben, lizenziert unter Apache-2.0, der Standardzweig heißt main, und eine eigene Projektseite ist nicht angegeben. Der letzte erfasste Stand datiert vom 19. Mai 2026, und als einzige Ausgabe ist v0.0.0 mit der Bezeichnung initial commit verzeichnet.

Die Grundidee steht in einem Satz. Das System bildet eine größere Menge von Akteuren, womit Anwendungen wie Agenten gemeint sind, auf eine kleinere Menge bereiter Worker ab. Möglich wird das, weil agentenähnliche Anwendungen den größten Teil der Zeit untätig sind. Wer jedem Agenten dauerhaft eigene Ressourcen zuweist, bezahlt für Leerlauf.

Aus dieser Idee folgt die Zuständigkeit. Agent Substrate verwaltet den Lebenszyklus eines Akteurs, ordnet Akteure in Echtzeit den Workern zu und leitet eingehenden Verkehr an sie weiter. Es versteht sich ausdrücklich als meinungsarm: Die verwalteten Arbeitslasten müssen keine Agenten im engen Sinn sein, sie sind nur das beste Beispiel für die gedachte Anwendung.

Anhalten, Teleportieren und der Zustand im Schnappschuss

Die Steuerungsebene bietet vollständige Lebenszyklusverwaltung für Sandboxes: anlegen, zerstören, anhalten und fortsetzen. Das README nennt Untersekundenzeiten für das Anhalten und Fortsetzen, und genau diese Größenordnung macht das Multiplexing praktisch brauchbar. Ein Akteur, der in weniger als einer Sekunde eingefroren und an anderer Stelle wieder erweckt werden kann, belegt seinen Worker nicht dauerhaft.

Der Zustand bleibt dabei erhalten. Über Vollzustandsaufnahmen werden flüchtiger Speicher und Dateisystemstand über Ruhezyklen hinweg bewahrt; das Projekt spricht vom dauerhaften Arbeitsgedächtnis. Für einen Agenten heißt das, dass er nach dem Aufwachen dort weitermacht, wo er aufgehört hat, ohne dass die Anwendung selbst etwas dafür tun muss.

Als Demonstration dient ein Video, in dem ein Verbund nach README-Angabe rund 250 zustandsbehaftete Akteure auf acht physische Pods verteilt, was einer Überbuchung von mehr als dem Dreißigfachen entspricht. Diese Zahlen sind eine Darstellung des Projekts, keine unabhängige Messung, und das README nennt keine Messmethode.

Wo Kubernetes aufhört und die ate-Steuerungsebene anfängt

Agent Substrate nutzt Kubernetes für die Bereitstellung der Infrastruktur und die Verwaltung der Worker, greift also auf Pods und die Pod-Autoskalierung zurück. Darüber legt es eine eigene Schicht mit agentenspezifischer Planung und Steuerung, die die Latenz senken soll. Diese Arbeitsteilung ist der Kern der Konstruktion: Kubernetes bleibt für die Infrastruktur zuständig, die Zuordnung der Akteure übernimmt die eigene Steuerungsebene.

Nach der Projektdokumentation besteht diese Ebene aus mehreren Teilen, die unter cmd/ liegen. ateapi ist der API-Server mit gRPC-Endpunkten. atelet läuft als DaemonSet auf jedem Knoten, überwacht die Worker-Pods und koordiniert die Aufnahmen. atecontroller gleicht die benutzerdefinierten Ressourcen WorkerPool und ActorTemplate ab. atenet übernimmt das Netzwerk mit DNS und Envoy-Weiterleitung. Für den Sandbox-Betrieb kommen zwei Helfer im Pod hinzu, ateom-gvisor für Prüfpunkt und Wiederherstellung über runsc sowie ateom-microvm für Akteure als cloud-hypervisor-VMs. Die Einzelheiten liegen in docs/architecture.md.

Der Unterschied zu reinem Kubernetes liegt damit nicht in der Infrastruktur, sondern im Lebenszyklus. Ein Pod lässt sich nicht anhalten und an anderer Stelle mit erhaltenem Speicherinhalt wieder starten. Genau in diese Lücke stößt Agent Substrate.

Schnellstart mit hack/create-kind-cluster.sh und kubectl ate

Der Schnellstart für die Entwicklung ist skriptbasiert. Vorausgesetzt werden Go, kubectl und docker, weitere Abhängigkeiten wie kind verwalten die Skripte selbst. Der Ablauf beginnt mit hack/create-kind-cluster.sh, das einen kind-Cluster und eine lokale Registry anlegt; mit IP_FAMILY=dual oder ipv6 weicht man von der Voreinstellung IPv4 ab.

Danach folgen hack/install-ate-kind.sh --deploy-ate-system, das laut Kommentar ate, PostgreSQL und rustfs installiert, sowie hack/install-ate-kind.sh --deploy-demo-counter für die Zähler-Demo. Die Befehlszeile entsteht mit go install ./cmd/kubectl-ate. Erst danach lassen sich Objekte anlegen: kubectl ate create atespace demo und anschließend kubectl ate create actor my-counter-1 -a demo --template=ate-demo-counter/counter. Der Netzwerkrouter wird danach über eine Port-Weiterleitung erreichbar gemacht.

Die Reihenfolge ist verbindlich, ohne einen Atespace lässt sich kein Akteur anlegen, und das README weist ausdrücklich darauf hin. Für die Google Kubernetes Engine gibt es einen eigenen Weg über tools/setup-gcp. Eine Beschreibung der Zähler-Demo liegt in demos/counter/README.md.

Sandbox-Technologien: gVisor, MicroVMs und OCI-Container

Bei den Sandboxes hält sich das System mehrere Wege offen. Unterstützt werden Mikro-VMs und gVisor, und die Lebenszyklusoperationen sollen für alle Sandbox-Arten gleichartig ablaufen. Weil handelsübliche OCI-Container auf Kernelebene verwaltet werden, lässt sich nach README-Angabe praktisch jeder Stapel betreiben. Das Projekt nennt das Unabhängigkeit vom Rahmenwerk.

Genannt werden vier Beispiele. Für das Agent Development Kit gibt es Unterstützung für Akteur-Identität und dauerhaftes Arbeitsgedächtnis. LangChain-Agenten sollen langlaufend und zustandsbehaftet ausgeführt werden, mit Sandbox für Werkzeugaufrufe. Claude Code und CodeX werden als dichte, zustandsbehaftete Entwicklungsumgebungen geführt, die Terminal- und Dateisystemstand über Sitzungen hinweg bewahren. Und MCP-Server lassen sich als Akteure bereitstellen, um Werkzeuge dauerhaft verfügbar zu machen.

Als Beispiel für ein darauf aufbauendes System nennt das README den Agent Executor unter github.com/google/ax, eine verteilte Agentenlaufzeit. Das ist keine Alternative, sondern eine Schicht darüber: Sie zeigt, wie ein Agenten-Harness auf Substrate aufsetzen kann.

Stand v0.0.0: keine Kompatibilität und kein Google-Support

Der Stand ist die wichtigste Information in diesem Text. Das README sagt klar, dass sich Agent Substrate in früher Entwicklung befindet, nicht für den Produktionseinsatz bereit ist und dass sich die Schnittstellen mit an Sicherheit grenzender Wahrscheinlichkeit ändern werden. Zusagen zur Rückwärtskompatibilität gibt es nicht, alles darf sich ändern. Als einzige Ausgabe ist v0.0.0 verzeichnet, ein Umstand, der diese Aussage unterstreicht.

Zwei weitere Punkte gehören dazu. Die Unterstützung von Kubernetes beschränkt sich auf die jeweils neueste stabile Fassung und die vorherige Nebenversion. Wer eine ältere Umgebung betreibt, fällt heraus, und ein Upgrade-Zwang folgt daraus unmittelbar. Und obwohl im Umfeld Google-Produkte auftauchen, steht am Anfang des README der Hinweis, dass es sich nicht um ein offiziell unterstütztes Google-Produkt handelt und dass das Projekt für das Google-Programm zur Vergütung von Sicherheitsfunden nicht in Frage kommt.

Sicherheitszusagen macht das README nicht. Es verweist auf ein Dokument zum Bedrohungsmodell, das Vertrauensgrenzen und bekannte Risiken beschreibt. Wer Substrate auch nur evaluiert, sollte dieses Dokument vor dem ersten Cluster lesen.

Gemeinschaft, Beiträge und was Apache-2.0 hier bedeutet

Für den Austausch nennt das Projekt eine Google-Gruppe namens ate-dev und ein wöchentliches Treffen, donnerstags von 10 bis 11 Uhr Pazifikzeit, samt Videoverbindung, Telefoneinwahl und veröffentlichten Notizen. Im Slack der CNCF gibt es zwei Kanäle: #substrate-users für den Einsatz und #substrate-dev für die Entwicklung.

Beiträge sind willkommen, werden aber mit einer Einschränkung versehen, die man selten so deutlich liest. Das Projekt bezeichnet sich als sehr jung, konzentriert sich auf Kernsystem und Demos und behält sich vor, Beiträge außerhalb dieser Ziele in naher Zukunft weder zu prüfen noch zu übernehmen. Wer eine Erweiterung einreichen will, sollte das vorher im Kanal klären, statt Zeit in einen zurückgewiesenen Vorschlag zu stecken.

Lizenziert ist das Ganze unter Apache-2.0, was unter anderem eine Patentklausel und die Pflicht zur Kenntlichmachung von Änderungen mit sich bringt; eine rechtliche Bewertung gehört nicht hierher. Für die Bewertung des Projekts heißt das etwas anderes: Die Offenheit des Quelltextes ersetzt keine Reife, und die Versionsnummer v0.0.0 sagt mehr als jede Zusage im README.

Redaktionelles Fazit

Agent Substrate passt zu Infrastrukturteams, die große Mengen zustandsbehafteter Agenten betreiben wollen und dafür eine Steuerungsebene auf Kubernetes akzeptieren, die Akteure anhält, verschiebt und wieder aufweckt. Weniger passt es für alle, die heute eine tragfähige Grundlage brauchen, denn v0.0.0 ist die einzige Ausgabe, Schnittstellen werden sich ändern, Rückwärtskompatibilität wird ausdrücklich ausgeschlossen, und die Kubernetes-Unterstützung reicht nur zwei Nebenversionen weit. Wer den Ansatz prüfen will, beginnt mit hack/create-kind-cluster.sh und der Zähler-Demo in einem kind-Cluster und liest dazu das Dokument zum Bedrohungsmodell.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes