Meta-Harness für KI-Agenten: Databricks veröffentlicht Omnigent als Open Source

Databricks hat mit Omnigent ein neues Open-Source-Werkzeug vorgestellt, das als sogenannter Meta-Harness über bestehenden KI-Agenten wie Claude Code, Codex oder eigenen, in YAML-definierten Agenten sitzt. Das unter der Apache-2.0-Lizenz veröffentlichte Projekt soll eine einheitliche Schicht für Komposition, Governance und Zusammenarbeit bei Multi-Agenten-Workflows bereitstellen. Omnigent richtet sich damit an Engineering-Teams, die heterogene Agenten-Set-ups zentral steuern wollen, statt für jeden Provider eigene Integrations- und Sicherheitslösungen zu pflegen.

Wie das Unternehmen in seinem Blogbeitrag zur Vorstellung von Omnigent erläutert, stammt die Motivation aus der eigenen praktischen Arbeit mit Agenten in einem rund 5000-köpfigen Engineering-Team sowie aus tausenden Agentenprojekten für Kunden. Die Erkenntnis: Der entscheidende Fortschritt beim Agent-Engineering verschiebt sich vom einzelnen Modell hin zu Teams aus spezialisierten Agenten. Anthropic etwa setze für sein Research-Produkt auf einen Lead-Agenten mit parallelen Sub-Agenten. Die auf KI für die Rechtsbranche zugeschnittene Anwendung Harvey kombiniere ein Open-Source-Worker-Modell mit einem Frontier-Advisor und sei so in der Lage, ein einzelnes Frontier-Modell in puncto Qualität und Kosten zu schlagen. Databricks selbst lässt sein Produkt Genie unterschiedliche LLMs für Planung, Suche und Codegenerierung nutzen.

Architektur: Runner, Server und einheitliche API

Omnigent kapselt beliebige Agenten – ob terminalbasierte Coding-Harnesses wie Claude Code, Codex, Pi und Cursor oder SDK-basierte wie OpenAI Agents und Claude SDK – in einem sogenannten Runner mit Sandbox-Session und einheitlicher API. Der Datenaustausch folgt einem simplen Prinzip: Nachrichten und Dateien fließen hinein, Textstreams und Tool-Calls heraus. Ein zentraler Server stellt darüber hinaus Policies, das Session-Management und Sharing-Funktionen bereit. Sessions lassen sich über das Terminal, lokale Web-UI (standardmäßig unter http://localhost:6767), eine macOS-Desktop-App, mobile Browser und APIs parallel nutzen.

Der Vorteil gegenüber etablierten Orchestrierungstools liegt Databricks zufolge in der strikten Trennung von Geschäftslogik und Governance. Klassische Agentenplattformen koppeln Sicherheitslogik meist eng an Prompts oder den Code eines spezifischen Frameworks. Omnigent verlagert Policies auf die Meta-Ebene – sie gelten konsistent über alle angebundenen Harnesses und Modelle hinweg, unabhängig davon, ob ein Team gerade Claude Code, Codex oder einen eigenen Runtime-Agenten nutzt. Agenten werden deklarativ in YAML-Dateien definiert, ein Harness- oder Modellwechsel ist mit einer einzigen Zeilenänderung möglich. Das Omnigent-GitHub-Repository enthält neben dem Quellcode auch Beispielagenten für typische Coding-Workflows.

Feingranulare Policies für regulierte Umgebungen

Besonders ausführlich dokumentiert Databricks die Built-in-Policies für Sicherheit und Kostenkontrolle. Anders als einfache Allow/Deny-Mechanismen verfolgen diese dynamisch den Sitzungszustand und treffen kontextabhängige Entscheidungen. So kann eine Policy beispielsweise erzwingen, dass ein Agent nach dem Download eines neuen npm-Pakets vor einem git push eine Bestätigung durch einen Menschen einholen muss.

Für den Einsatz in regulierten Branchen sind die Policies granular konfigurierbar: Die Richtlinie enforce_sandbox erlaubt es, für Entwicklungs-, Test- und Produktionsumgebungen unterschiedliche Sandbox-Konfigurationen mit spezifischen Dateipfaden, Netzwerkregeln und Schreibrechten durchzusetzen. Dedizierte Policies für GitHub, Google Drive, Gmail und Google Calendar definieren im Detail, welche Repositories, Branches, Dateien oder E-Mail-Operationen ein Agent nutzen darf – etwa nur Lesezugriff in Prod-Repos oder E-Mail-Entwürfe ohne Sendeerlaubnis. Die Policy deny_pii_in_llm_request scannt ausgehende Nachrichten auf personenbezogene Daten und blockiert oder setzt ein Flag vor dem LLM-Aufruf – ein Baustein für DSGVO-konforme Setups. Hinzu kommen Risikoscores, die anhand von Tool-Aufrufen und Sensitivitätslabels einen kumulierten Wert aufbauen und ab einem konfigurierbaren Schwellenwert die Freigabe durch einen Menschen verpflichtend machen.

Kostenkontrolle und Anbieterunabhängigkeit

Auf der Dokumentationsseite zu den Cost-Control-Policies finden sich Mechanismen, die kumulative LLM-Kosten pro Session oder pro Nutzer über alle Sessions hinweg verfolgen. Bei einem als weich definierten Schwellenwert fragt die Policy cost_budget nach und blockiert teure Modelle aber beim Überschreiten eines harten Limits. So lässt sich beispielsweise ein Agent nach jeweils 100 US-Dollar angefallenen LLM-Kosten anhalten. Die Richtlinie deny_trivial_to_expensive_model stuft Anfragen automatisch in trivial versus komplex ein und routet einfache Tasks weg von teuren Modellen.

Dieser Routing-Mechanismus unterstützt zugleich eine Multi-Provider-Strategie. Omnigent bringt keine eigenen LLMs mit, sondern arbeitet mit vorhandenen Credentials – von direkten API-Keys über Cloud-Gateways bis hin zu On-Premises-Clustern. In der Dokumentation zu den Custom Agents zeigt sich, dass ein Modellwechsel in der YAML-Konfiguration nur eine einzige Zeile betrifft. Für Unternehmen, die derzeit stark von einem einzelnen LLM-Provider abhängig sind, reduziert das den Lock-in: Sessions, Policies und Skills sind an die Meta-Harness-Schicht gebunden, nicht an ein bestimmtes Modell. Investitionen in Governance und Sicherheitsrichtlinien bleiben bei einem Providerwechsel erhalten.

Vom einzelnen Entwickler bis zum Konzern

Die Installationswege reichen vom Shell-Skript und pip install 'omnigent' über Homebrew bis zur Git-Installation. Vorausgesetzt werden Python 3.12 oder neuer, Node.js 22 LTS, git und tmux; unter Linux zusätzlich bubblewrap für das OS-Sandboxing, macOS nutzt seatbelt. Für kleine Teams genügt laut Databricks eine lokale Installation mit eigenen API-Keys und einer optionalen Cloud-Sandbox über Modal oder Daytona. Mittelgroße Engineering-Teams können einen zentral bereitgestellten Omnigent-Server auf Fly.io oder Railway betreiben, angebunden an SSO und interne LLM-Gateways, mit differenzierten Richtlinien je nach Projekt und Umgebung.

Für größere Enterprise-Set-ups mit potenziell hunderten Agenten sieht die Architektur mandantenfähige Serverinstanzen vor. Standardisierte YAML-Agent-Definitionen lassen sich versioniert über Git ausrollen, während zentrale Security-Teams Policies wie PII-Filter, Sandbox-Erzwingung und Risikoscores vorgeben. Die Kollaborationsfunktionen – Live-Sessions per URL teilen, gemeinsamer Dateisystem-Workspace, Echtzeit-Kommentare – sind dabei von Anfang an integriert, statt sie nachträglich aufzusetzen. Konkrete Referenz-Deployments in dieser Größenordnung dokumentiert Databricks allerdings bislang nicht.

Omnigent befindet sich in einem frühen Stadium. Unternehmen sollten den Einsatz zunächst in weniger kritischen Umgebungen erproben und eigene Code-Audits sowie die Integration in bestehendes Monitoring einplanen.

(map)