kagent 1.0: Warum KI-Agenten nicht dauerhaft eigene Kubernetes-Pods brauchen

Was mit kagent 1.0 tatsächlich allgemein verfügbar wird

Solo.io hat am 10. November 2026 die Version 1.0 von kagent und die Enterprise-Ausgaben von Agent Substrate für allgemein verfügbar erklärt. Das Unternehmen positioniert die Kombination als Infrastruktur für zustandsbehaftete KI-Agenten und isolierte Werkzeugausführung auf Kubernetes einschließlich OpenShift. Anders als bei einer reinen Chatbot-Plattform geht es um Laufzeit, Identität, Ressourcen, Sitzungshistorie, Richtlinien und kontrollierten Zugriff auf externe Systeme.

Die Open-Source-Projekte kagent und Agent Substrate gehören zum CNCF-Umfeld. Eine Aufnahme als CNCF-Sandbox-Projekt ist allerdings keine unabhängige Produktions- oder Sicherheitszertifizierung. Solos GA-Aussage bezieht sich auf die angebotenen Versionen und den herstellerseitig definierten Reifegrad.

Das Pod-pro-Agent-Problem: reservierte Rechenleistung für wartende Sitzungen

Eine gewöhnliche Kubernetes-Anwendung läuft als Pod mit laufenden Replikaten. Für einen Agenten ist das oft ineffizient: Er wartet auf ein Sprachmodell, ein Tool-Ergebnis oder die Freigabe durch einen Menschen, möchte aber seine Dateien und den Gesprächszustand behalten. Würde jede Sitzung permanent ihren eigenen Pod belegen, könnten CPU, Speicher, IP-Adressen und Scheduling-Kapazität ungenutzt gebunden bleiben.

Daraus folgt nicht, dass jedes bestehende Pod-Design falsch ist. Kleine, stateless Agenten oder vorhersehbare Jobs können mit gewöhnlichen Deployments gut funktionieren. Das kagent-Modell zielt insbesondere auf dynamische, interaktive Sessions mit langen Ruhephasen, vielen Mandanten und eigenen Arbeitsverzeichnissen.

Agent Substrate: Actor-Zustand bleibt, Worker-Kapazität wird frei

Agent Substrate verwendet Actor-Sitzungen, die auf einem Pool vorgewärmter Worker-Pods ausgeführt werden. Geht ein Actor in den Leerlauf, kann die Plattform Arbeitsverzeichnis und optionalen Speicherzustand als Snapshot sichern und den Worker freigeben. Bei einer neuen Anfrage wird die Sitzung auf einem passenden freien Worker wiederhergestellt. Dadurch müssen eine aktive Sitzung und ein dauernd reservierter Worker nicht länger identisch sein.

Das ist ein echter architektonischer Unterschied zu Pod-pro-Agent. Ob daraus eine große Kostenersparnis entsteht, hängt aber von Leerlaufanteil, Snapshots, Speicherbedarf, Wiederanlaufzeit und Clusterbetrieb ab. Für kleine Teams kann der zusätzliche Systembetrieb mehr Aufwand erzeugen als eingesparte Ressourcen.

Sandbox und Identity: Warum ein Agent mehr als eine ServiceAccount braucht

Nach Solos Architektur läuft jeder Actor in einer isolierten gVisor- oder MicroVM-Umgebung. Agent Substrate nutzt pro Actor eine auf SPIFFE basierende Identität, die beim Wechsel zwischen Workern erhalten bleibt. Eingehende Requests passieren Authentifizierung und Richtlinienprüfung. Ausgehende Anfragen werden über agentgateway mit EgressPolicy kontrolliert. API-Schlüssel sollen dabei erst am Gateway hinzugefügt werden, statt dauerhaft im Agenten-Workspace zu liegen.

Diese Architektur reduziert Angriffsflächen, ersetzt jedoch weder sichere Richtlinienkonfiguration noch unabhängige Penetrationstests. Besonders heikel bleiben ein falsch erlaubter Egress, zu weitreichende Rollen und die Frage, wer Policy-Änderungen freigibt. Ein isolierter Prozess kann trotz Sandbox eine autorisierte, aber geschäftlich falsche Aktion auslösen.

Was kagent über die Laufzeit hinaus ergänzt

Agent Substrate steuert Actor, Worker, Snapshots und Sicherheitsgrenzen. kagent fügt die höhere Anwendungsebene hinzu: Benutzer und Eigentümer, Gespräche, Agentendefinitionen, Versionen, Freigaben, gemeinsame Nutzung und Beobachtbarkeit. Agenten können über verschiedene Modelle und Frameworks eingebunden werden; MCP und A2A dienen der Kommunikation über definierte Schnittstellen.

Wichtig ist die Wiederaufnahme nach einer menschlichen Entscheidung. Die Sitzung kann an einem Freigabepunkt pausieren und später mit dem gespeicherten Kontext fortsetzen. Versionierte Rollouts sollen laufende Konversationen von Konfigurationswechseln entkoppeln. Für nachvollziehbare Agentenarbeit ist das wertvoller als eine bloße Liste unterstützter Modelle.

Open Source, Enterprise GA und Umstieg von 0.x sind zu trennen

Solo.io beschreibt neben den offenen Projekten auch allgemein verfügbare Enterprise-Releases mit zusätzlichen Zugriffs-, Tracing-, Evaluierungs-, Kapazitäts- und Air-Gap-Funktionen. Aus der Ankündigung lässt sich keine pauschale Freigabe sämtlicher Enterprise-Funktionen ohne Vertrag, Infrastruktur oder Konfiguration ableiten. Für die Installation werden Kubernetes, Helm und ein Modellanbieter-Zugang benötigt; Modellgebühren bleiben gesondert relevant.

Wer kagent 0.x einsetzt, sollte die Versionsumstellung besonders sorgfältig planen. Solo.io bezeichnet 1.0 als neue API auf einer neuen Laufzeit und empfiehlt für bisherige 0.x-Umgebungen eine frische Installation. Das ist kein harmloses automatisches Patch-Upgrade.

AgentenCode-Kostencheck: Welche Rechnung vor der Einführung nötig ist

Das Einsparversprechen von pausierten Sessions ist plausibel, aber ohne reale Lastprofile nicht quantifizierbar. Ein sauberer Vergleich misst mindestens: gleichzeitige aktive statt nur registrierte Sitzungen, CPU- und Speicherbelegung über 24 Stunden, Snapshot-Größe, Aufwachlatenz, fehlgeschlagene Wiederaufnahmen, Storage-Kosten sowie Modell- und Toolgebühren. Erst aus diesen Größen lässt sich ein belastbarer Gesamtbetriebskostenvergleich ableiten.

Ein Pilot sollte nicht mit 10.000 simulierten Sessions werben und die tatsächlich rechenintensiven Schritte ignorieren. Für einen fairen Benchmark zählt dieselbe Aufgabe mit identischer Modellkonfiguration, vergleichbaren Sicherheitsrichtlinien und gemessener End-to-End-Latenz. Ein Anbieterrechner ersetzt keine Messung im eigenen Cluster.

Unsere Entscheidungsmatrix: Wann ist der neue Agenten-Stack sinnvoll?

Für einen einzelnen internen Recherchebot ist ein eigener Kubernetes-Agenten-Stack meist schwer zu rechtfertigen. Für viele interaktive Sessions mit eigenen Arbeitsverzeichnissen, mehreren Mandanten, langen Wartephasen und streng kontrollierten Werkzeugzugriffen kann das Actor/Worker-Modell hingegen sinnvoll sein. Besonders bei regulierten Prozessen sollten Audit-Trails, Freigaben, Recovery-Tests und Secrets-Handling vor Produktivsetzung nachgewiesen werden.

AgentenCode empfiehlt zunächst einen abgegrenzten Read-only-Pilot: 50 bis 100 parallele Sessions mit definierten Wartezeiten, kontrollierten Ressourcengrenzen und mehreren absichtlich verweigerten Tool-Aktionen. Danach können Schreibzugriffe mit Freigaben folgen. Solo.io nennt mit OutSystems und Swissquote Anwender, doch die berichteten Erfolge sind Hersteller- und Partnerangaben und kein unabhängiger universeller Wirksamkeitsnachweis.

Als konkrete Anwender nennt Solo.io OutSystems und Swissquote. Der erste Fall steht für viele mandantenbezogene Agentensitzungen; Swissquote beschreibt Finanzkriminalitätsanalysen in einer kontrollierten Infrastruktur. Beides macht den praktischen Nutzen plausibel, liefert aber keine unabhängig reproduzierte Benchmarkkurve. Vor einer Beschaffung sollten Betreiber verbindlich klären, welche Telemetriedaten exportierbar sind, wie Snapshots verschlüsselt werden und wer bei nicht wiederherstellbaren Sitzungen haftet.