Die Agent-Kontrollebene: Omnigent auf Kubernetes

Infrastructure-Engineers orchestrieren Dienste schon seit Jahren. Load Balancer vor Application Servern. Sidecars für Telemetrie. Policy-Enforcement am Ingress. Das Muster ist so vertraut, dass es fast langweilig wirkt.

Jetzt stellt sich dieselbe Frage auf der Agent-Ebene.

Databricks hat kürzlich Omnigent als Open Source veröffentlicht und nennt es einen “Meta-Harness”: eine Schicht, die individuelle AI-Agent-Harnesses, darunter Claude Code, Codex und eigene Implementierungen, hinter einer gemeinsamen API vereint. Sessions, Policies und Skills bleiben erhalten, unabhängig davon, welches Modell oder welcher Harness gerade darunter läuft. Es ist eine Abstraktion über die Realität, mehrere Agent-Tools gleichzeitig zu verwalten und Kontext manuell zwischen ihnen zu kopieren.

Das Konzept ist nicht neu, wenn man schon einmal einen AI-Agent selbst gehostet hat. Als ich einen selbst gehosteten Research-Agent auf EKS aufgesetzt habe, tauchten dieselben Fragen auf: Wo lebt der State? Wer kontrolliert die Netzwerkgrenzen? Wie exponiert man den Agent nach außen, ohne die gesamte Maschine freizugeben? Omnigent formalisiert diese Fragen in ein kohärentes Produkt.

Was der Meta-Harness eigentlich ist

Drei Komponenten sind wichtig, bevor man über das Deployment nachdenkt.

Der Runner umhüllt einen zugrundeliegenden Agent in einer Sandbox-Session. Er fängt Netzwerkanfragen ab, wendet Policies an und vermittelt den Zugriff des Agents auf die Außenwelt. Hier findet die eigentliche Security-Arbeit statt.

Der Server verwaltet Sessions, Policies und Sharing. Er ermöglicht es, Regeln wie “vor jedem Git-Push nach einem Package-Download eine manuelle Genehmigung verlangen” zu definieren, ohne den Agent selbst zu patchen. Policies sind hier stateful und kontextabhängig, keine simplen Allow/Deny-Listen.

Die Datenbank persistiert Session-State, Audit-Logs und Policy-Konfigurationen. Sie muss einzelne Runner-Prozesse oder Pods überleben.

Wer schon einmal einen zustandsbehafteten Webdienst auf Kubernetes betrieben hat, hat dieses Problem in einem anderen Bereich bereits gelöst. Die Topologie ist dieselbe.

Die Kubernetes-Form des Problems

Omnigent auf einem Cluster zu betreiben ist kein neuartiges Infrastructure-Problem. Es hat dieselbe Form wie Dienste, die man wahrscheinlich schon deployt hat: eine Server-Komponente, die horizontal skalierbar sein soll und deshalb zustandslos sein muss; eine Runner-Komponente, die einen Subprocess umhüllt und von Natur aus single-session ist; und eine gemeinsame Datenbank, die beide erreichen können.

Die Deployment-Manifeste, Service-Definitionen und Ingress-Regeln sind nicht der interessante Teil. Die Frage, die echtes Nachdenken verdient, ist die Netzwerk-Intercept-Grenze. Der Runner muss zwischen dem Agent und ausgehendem Traffic sitzen, um Policies durchzusetzen. Wo das in der bestehenden Cluster-Topologie landet und wie es mit bestehenden Network Policies und Egress-Controls interagiert, ist die Frage, die man skizzieren sollte, bevor man YAML schreibt.

Die Datenbankkonfiguration ist die erste echte Weggabelung:

# Einzelinstanz für lokale Tests oder Demos
DATABASE_URL=sqlite:////data/artifacts/chat.db

# Produktion: jede verwaltete Postgres-Instanz funktioniert
DATABASE_URL=postgresql://user:pass@postgres-host:5432/omnigent

SQLite funktioniert für ein einzelnes lokales Setup, aber es speichert Daten auf dem lokalen Disk des Pods. Auf Kubernetes bedeutet das, dass Daten mit dem Pod sterben, wenn kein Persistent Storage explizit eingebunden wurde. SQLite sollte man nur wählen, wenn man genau versteht, worauf man dabei verzichtet.

Postgres ist die richtige Wahl, sobald Persistenz wichtig ist oder mehr als ein Server-Replikat laufen soll. Jede verwaltete Postgres-Instanz, ob im Cluster oder extern, funktioniert. Die entscheidende Anforderung ist Netzwerkerreichbarkeit aus dem Pod-CIDR. Die initiale Migration auf einer neuen Postgres-Instanz dauert etwa eine Minute; der Startup-Probe braucht genug Zeit, sonst scheitert das erste Deployment an einem Healthcheck, den es eigentlich bestehen sollte.

Die restlichen Kubernetes-Fragen sind dieselben wie bei jedem zustandsbehafteten Dienst: Wo leben die Secrets? Wie bekommt der Runner die Credentials für die Agents, die er umhüllt? Wer kann den Server von außerhalb des Clusters erreichen?

Schnellstarts ohne Operations-Aufwand

Wer verstehen will, wie sich Omnigent verhält, bevor man eine Infrastructure-Entscheidung trifft, findet in einem HuggingFace Docker Space den schnellsten Weg zur UI. In wenigen Minuten läuft sie. Das Wichtigste dabei: HuggingFace Spaces nutzen standardmäßig ephemeren Disk-Speicher. Wer SQLite konfiguriert, verliert Session-History und Policies beim nächsten Container-Neustart. Es eignet sich als Explorationsumgebung, nicht für alles, was erhalten bleiben soll.

Für Teams, die bereits auf der Databricks-Plattform arbeiten, ist verwaltetes Omnigent auf Databricks das andere Ende des Spektrums. Man bekommt den Meta-Harness, ohne ihn selbst betreiben zu müssen, mit dem Databricks-Sicherheits- und Governance-Modell bereits integriert. Wenn die Agents und Daten einer Organisation bereits in diesem Ökosystem leben, ist das der naheliegende Ausgangspunkt.

Der interessante Raum liegt dazwischen: selbst gehostet auf eigener Infrastruktur, mit Policies, die auf das tatsächliche Risikoprofil des Teams zugeschnitten sind, nicht auf Vendor-Defaults.

Der Teil, der wirklich zählt

Die Deployment-Frage hat eine lösbare Antwort. Die Policy-Frage ist schwieriger und interessanter.

Das Policy-System von Omnigent ist stateful. Eine Regel kann sagen: Nachdem dieser Agent ein Package heruntergeladen hat, muss vor einem Push in ein Remote-Repository eine manuelle Genehmigung eingeholt werden. Das ist keine statische Allow/Deny-Liste; es ist eine State Machine, die über den Aktionen des Agents liegt. Die Policies kodieren das Bedrohungsmodell einer Organisation für Agent-Verhalten.

Wie würden die eigenen aussehen? Kostenlimits, die einen Agent vor einem teuren API-Call pausieren. Approval-Gates, bevor ein Write eine geteilte Umgebung berührt. Audit-Trails, die Model-Wechsel überspannen, damit man bei einem Incident weiß, welches Modell welche Entscheidung getroffen hat.

Kubernetes Operators verwalten zustandsbehaftete Systeme seit Jahren deklarativ. Der Instinkt ist hier derselbe: definieren, wie korrektes Agent-Verhalten aussieht, und das System durchsetzen lassen, anstatt jede Session manuell zu überwachen.

Die Agent-Ebene bekommt die Infrastructure-Behandlung, die sie schon immer gebraucht hat. Die einzige Frage ist, ob man selbst definiert, wie das für das eigene Team aussieht, oder ob man das jemand anderen entscheiden lässt.

Ich hatte bisher keine Gelegenheit, Omnigent selbst in einem echten Cluster zu betreiben; andere Projekte haben meine Aufmerksamkeit beansprucht. Es steht bereits auf meiner Liste und ich werde einen Follow-up-Beitrag veröffentlichen, sobald ich Zeit für ein echtes Deployment hatte.