In dieser Paneldiskussion live vom TechRiders Summit 2026 beleuchten CTOs und Tech-Leads gemeinsam mit Eberhard Wolff, wie Unternehmen die Kosten- und Komplexität in der KI-gestützten Softwareentwicklung wahrnehmen – von dem Versprechen einer „billigen“ Umsetzung bis zu den verborgenen Risiken.

Die Diskussion behandelt zentrale Fragen:

• „Billiger“ vs. „einfacher“: Was steckt hinter diesen Begriffen? „Einfacher“ ist nicht gleichbedeutend mit schneller oder wartungsfreundlich – vielmehr entstehen neue Abhängigkeiten von Drittanbieter-APIs, die die Wartung komplexer machen.
• Versteckte Kosten der KI: Die Illusion einer kostengünstigen KI-Lösung ignoriert oft unsichtbare Aufwände – etwa für Modell-Training, Monitoring, Compliance (z. B. DSGVO), QA und Lizenzabhängigkeit von Anbietern.
• Team & Kompetenzen: KI verändert die Rollen von Architektinnen und Architekten – weg von reiner Code-Optimierung hin zu KI-Management und ethischer Bewertung. Während Junior-Entwicklerinnen und -Entwickler vermeintlich durch KI-Assistenten profitieren, droht der Wissenstransfer zu erodieren, wenn KI „Black Boxes“ für Entscheidungen nutzt.
• Strategische Grenzen: Lohnt sich KI aus architekturhistorischer Sicht? Welche Prinzipien (z. B. Modularität, Observability) bleiben unverändert, um Systeme auch im KI-Zeitalter kontrollierbar und skalierbar zu halten?

Gäste aus dem Speaker Line-up des TechRiders Summit sind Daniel Gebler, Sebastian Kleinschmager und Axel Schulz.

Wer beim Tech Riders Summit dabei sein möchte: mit dem Code ARCH-TECHRIDER-2026 ist die Teilnahme für Endbenutzer sowie Anwenderinnen und Anwender kostenlos.

Livestream am 18. Juni

Die Ausstrahlung findet am Donnerstag, 18. Juni 2026, live ab 14:45 Uhr statt. Die Folge steht im Anschluss als Aufzeichnung bereit. Während des Livestreams können Interessierte Fragen via Twitch-Chat, YouTube-Chat oder anonym über das Formular auf der Videocast-Seite einbringen.

software-architektur.tv ist ein Videocast von Eberhard Wolff, iX-Blogger und bekannter Softwarearchitekt, der als Head of Architecture bei SWAGLab arbeitet. Zum Team gehören außerdem Lisa Maria Schäfer (Socreatory) und Ralf D. Müller (DB Systel). Seit Juni 2020 sind über 250 Folgen entstanden, die unterschiedliche Bereiche der Softwarearchitektur beleuchten – mal mit Gästen, mal Wolff, Schäfer oder Müller solo. Seit mittlerweile mehr als zwei Jahren berichtet iX (heise Developer) über die Episoden.

(map)

Digitale Souveränität ist 2026 vom politischen Schlagwort zum Verkaufsargument geworden. Mitte Januar hat Amazon Web Services die AWS European Sovereign Cloud in Brandenburg in Betrieb genommen, eine eigene, vollständig in der EU betriebene Partition mit getrennter Abrechnung in Euro, eigenem Personal und einer separaten Rechtsperson nach deutschem Recht. Wenige Wochen später zog Microsoft mit „Microsoft 365 Local“ nach und erlaubte seitdem, Dienste wie Exchange und SharePoint auf kundeneigener Hardware zu betreiben, abgekoppelt von der öffentlichen Cloud. Beide Angebote tragen dasselbe Etikett, und es ist ein gewichtiges: souverän.

Ich halte dieses Etikett für irreführend. Nicht, weil die technischen und organisatorischen Maßnahmen wertlos wären, im Gegenteil, sie sind beachtlich. Sondern weil sie ausgerechnet die eine Ebene unberührt lassen, auf die es bei Souveränität ankommt. Wer verstehen will, warum eine in Brandenburg betriebene Cloud rechtlich weiterhin in den Vereinigten Staaten hängt, muss zunächst sauber auseinanderhalten, was „souverän“ überhaupt bedeuten kann. Genau diese Unterscheidung trifft in der Debatte kaum jemand, und ohne sie reden die Beteiligten aneinander vorbei.

Was heißt hier souverän?

Souveränität in der Cloud zerfällt in drei Ebenen, die regelmäßig durcheinander geraten. Die erste ist die Datenresidenz, also die Frage, wo Daten physisch liegen. Die zweite ist die operative Autonomie, also die Frage, wer ein System betreibt, wartet und im Zweifel darauf zugreifen kann. Die dritte ist die rechtliche Souveränität, also die Frage, wessen Recht im Konfliktfall greift und wer einem Anbieter Anordnungen erteilen darf, denen dieser folgen muss.

Diese drei Ebenen sind nicht gleichwertig, und das ist der entscheidende Punkt. Datenresidenz und operative Autonomie lassen sich vertraglich und technisch herstellen, und genau das tun die neuen Angebote mit großem Aufwand. Die rechtliche Ebene aber entzieht sich solchen Maßnahmen, denn sie hängt nicht am Standort der Server, sondern an der Jurisdiktion, der das Mutterunternehmen untersteht.

Ein einfaches Gedankenexperiment macht den Unterschied greifbar. Stellen Sie sich vor, sämtliche Daten lägen in einem Rechenzentrum in Brandenburg, betrieben von Personen mit Wohnsitz in der EU, verschlüsselt und vertraglich abgesichert. Solange der Konzern, dem dieser Betrieb gehört, einer fremden Rechtsordnung untersteht, kann diese Rechtsordnung ihn zu einer Handlung zwingen, und kein Server-Standort ändert daran etwas. Datenresidenz ist eine Frage der Geografie, Souveränität eine Frage der Macht.

Dieser Bedeutungskern ist nicht zufällig. Souveränität bedeutet seit jeher die höchste Entscheidungsgewalt, also die Frage, wer am Ende das letzte Wort hat. Übertragen auf die Cloud heißt das: Souverän ist nicht, wessen Daten in der EU liegen, sondern wer im Streitfall bestimmen kann, was mit ihnen geschieht. Alles andere ist Komfort, nicht Kontrolle.

Die neuen Angebote im Jahr 2026

Die AWS European Sovereign Cloud ist technisch beeindruckend, das will ich nicht kleinreden. Sie läuft als eigene Partition mit einer eigenen Region, vollständig getrennt von den übrigen AWS-Regionen, mit eigenem Identitäts- und Abrechnungssystem in Euro und einem ausschließlich von Personen mit Wohnsitz in der EU besetzten Betrieb. Für Zertifizierung und digitale Signaturen hat Amazon sogar eine separate Gesellschaft nach deutschem Recht gegründet. Einen regionenübergreifenden Datenverkehr zu anderen AWS-Partitionen gibt es nicht, selbst Metadaten verbleiben in der EU-Infrastruktur.

Schon im Detail zeigt sich allerdings, wie heikel die Materie ist. Amazon legt das Kriterium des Wohnsitzes in der EU an, das BSI hingegen bevorzugt die Staatsangehörigkeit, und für staatliche Aufträge und kritische Infrastruktur kann dieser Unterschied erheblich sein. Eine scheinbar technische Detailfrage entscheidet darüber, wie weit die Autonomie tatsächlich reicht.

Microsoft verfolgt mit „Microsoft 365 Local“ einen anderen Weg. Statt einer abgeschotteten Cloud-Region verlagert das Angebot die sensibelsten Dienste, etwa Exchange und SharePoint, zurück auf Hardware im Haus der Kundin oder des Kunden, getrennt von der öffentlichen Cloud. Das ist im Kern eine Rückkehr zum Betrieb im eigenen Haus, neu verpackt als Souveränitätslösung.

Beide Wege adressieren reale Anforderungen, und für viele Anwendungsfälle reichen sie aus. Datenresidenz, operative Trennung und nachvollziehbare Zugriffskontrolle sind keine Kleinigkeiten. Das Problem beginnt erst dort, wo diese Maßnahmen als vollständige Souveränität verkauft werden, obwohl sie die rechtliche Ebene gar nicht berühren.

Der ungelöste Kern: CLOUD Act und FISA

Der CLOUD Act von 2018 verpflichtet US-Unternehmen, herausverlangte Daten herauszugeben, unabhängig davon, wo auf der Welt diese gespeichert sind. Hinzu kommen FISA Section 702 und die Executive Order 12333, die US-Nachrichtendiensten erlauben, Daten von Nicht-US-Bürgerinnen und -Bürgern im Ausland zu erheben, ohne dass Betroffene in Europa über wirksame Rechtsbehelfe verfügen. Diese Gesetze wirken extraterritorial, und das ist kein Randdetail, sondern der Kern des Problems.

Neu ist dieser Konflikt nicht. Bereits 2020 erklärte der Europäische Gerichtshof im Urteil Schrems II das Datenschutzabkommen Privacy Shield für ungültig, gerade weil die US-Überwachungsgesetze europäischen Betroffenen kein gleichwertiges Schutzniveau bieten. Die aktuelle Welle souveräner Cloud-Angebote ist im Grunde die Antwort der Industrie auf diese seit Jahren ungelöste Spannung, und sie verschiebt das Problem eher, als dass sie es beseitigt.

Eine Tochtergesellschaft nach deutschem Recht ändert daran wenig, solange die US-Muttergesellschaft die Kontrolle behält. Genau diese Konstruktion ist juristisch ungetestet. Was geschieht, wenn eine US-Behörde den Mutterkonzern anweist, seine europäische Tochter zu einer bestimmten Handlung zu veranlassen? Eine belastbare Antwort darauf gibt es bislang nicht, sie müsste vor Gericht erst erstritten werden, und bis dahin bleibt sie eine offene Flanke.

Wie wenig sich das durch Technik auflösen lässt, hat Microsoft selbst eingeräumt. Vor dem französischen Senat konnte das Unternehmen 2025 nicht garantieren, dass europäische Daten niemals an US-Behörden gelangen. Das ist keine Marketingfrage und keine Frage des guten Willens, sondern eine Frage der Jurisdiktion, und sie lässt sich mit noch so vielen Rechenzentren in der EU nicht beantworten.

Es gibt eine ernstzunehmende Gegenposition, und ich will sie nicht übergehen. Der Zugriff sei praktisch selten, heißt es, Vertrauenswürdigkeit schlage Herkunftsland, und für viele Unternehmen reichten rechtlich belastbare vertragliche Zusagen vollkommen aus. Für unkritische Arbeitslasten mag das zutreffen. Für die öffentliche Verwaltung, für kritische Infrastruktur und für besonders schützenswerte Daten überzeugt es mich nicht, denn Souveränität bemisst sich nicht an der Häufigkeit eines Zugriffs, sondern an der Frage, wer ihn im Ernstfall verhindern kann.

Ein Etikett für die falsche Ebene

Damit lässt sich präzise benennen, was an dem Wort „souverän“ stört. Es beschreibt die ersten beiden Ebenen, Datenresidenz und Betrieb, und schweigt über die dritte, die rechtliche Kontrolle. Das Etikett ist nicht gelogen, aber es ist auf eine Weise unvollständig, die das Wesentliche verdeckt, und diese Lücke ist kein Zufall.

Bemerkenswert ist nämlich, wer das Etikett vergibt: ausgerechnet jene Anbieter, deren Abhängigkeit es auflösen soll. Eine Untersuchung von 17 Anbietern entlang von 31 Kriterien kommt zu dem Schluss, dass sich keiner als klarer Souveränitätssieger bezeichnen lässt. US-Konzerne kaschieren strukturelle Jurisdiktionsrisiken mit EU-Tochtergesellschaften, und auch europäische Anbieter haben Schwächen in Kryptografie und Lieferkette. Branchenverbände wie CISPE haben dafür den Begriff Sovereignty Washing geprägt.

Dieses Muster ist nicht neu, und es lohnt sich, es zu erkennen. Ich habe an anderer Stelle beschrieben, wie Konzerne den Begriff Open Source vereinnahmen und ihn für ihre Zwecke umdeuten. Bei der souveränen Cloud geschieht dasselbe mit einem anderen Begriff: Ein Wort, das ursprünglich Unabhängigkeit bedeutete, wird zum Produktnamen für ein Angebot, das die Abhängigkeit gerade nicht beseitigt. Wer einen Begriff besetzt, kontrolliert die Debatte, und genau darum geht es.

Für die Käuferin und den Käufer hat das konkrete Folgen. Wer ein als souverän etikettiertes Produkt erwirbt, kauft womöglich Datenresidenz und glaubt, Unabhängigkeit erworben zu haben. Die Differenz zwischen beidem fällt erst auf, wenn es zu spät ist, nämlich im Konfliktfall, auf den das Etikett gerade nicht vorbereitet ist.

Die Regulierung erkennt das Problem

Auch die Politik hat verstanden, dass „souverän“ messbar werden muss, statt ein freies Versprechen zu bleiben. Anfang Juni 2026 hat die EU-Kommission den Cloud and AI Development Act vorgeschlagen, das erste EU-Gesetz, das sich gezielt an Cloud-Dienste und Künstliche Intelligenz richtet. Es ist eine Reaktion auf eine schlichte Zahl: Rund zwei Drittel des europäischen Cloud-Markts entfallen auf drei US-Konzerne, und diese Abhängigkeit gilt zunehmend als strategisches Risiko.

Im Kern steht ein Cloud Sovereignty Framework mit mehreren Stufen, an denen sich die öffentliche Hand bei der Beschaffung orientieren soll. Diese Stufen treffen exakt die Unterscheidung, um die es hier geht. Die unterste verlangt nur, dass Daten in der EU verarbeitet werden. Erst die höheren Stufen fordern Unabhängigkeit von Drittstaaten und Transparenz über die Software-Lieferkette, und die oberste verlangt Eigentum und Kontrolle aus der EU heraus, bis hin zur Staatsangehörigkeit des Personals und zur Freiheit von jeder Einflussnahme durch Drittstaaten.

Mit anderen Worten: Erst die oberste Stufe bezeichnet das, was „souverän“ im Wortsinn bedeutet, während die unterste kaum mehr als Datenresidenz verlangt. Eine ähnliche Linie verfolgt das BSI mit einem eigenen Kriterienkatalog dafür, wann eine Cloud wirklich souverän ist. Dass es solcher Kataloge überhaupt bedarf, ist das eigentliche Eingeständnis: Wäre das Etikett verlässlich, müsste niemand erst definieren, woran sich echte Souveränität erkennen lässt.

Der Cloud and AI Development Act steht dabei nicht allein, sondern ist Teil eines größeren Pakets, mit dem die EU ihre digitale Abhängigkeit verringern will. Dazu gehören eigens ausgewiesene Zonen für den beschleunigten Bau von Rechenzentren, mit denen sich die europäische Rechenkapazität in wenigen Jahren vervielfachen soll. Europäische Anbieter halten heute nur rund 15 Prozent des Markts, und gerade über die öffentliche Beschaffung könnten sie an Boden gewinnen, sofern die höheren Souveränitätsstufen dort tatsächlich verlangt werden.

Regulierung allein schafft allerdings keine Alternative, und das ist ihre Grenze. Sie kann beschreiben, was fehlt, sie kann über die Beschaffung Nachfrage lenken und Anbieter zu Transparenz zwingen. Bauen aber muss die Alternative jemand anderes, und genau hier verschiebt sich die Verantwortung von der Politik zurück zu denen, die Software entwerfen und betreiben.

Kontrolle über den Stack

Wer Souveränität ernst meint, sollte sie als das behandeln, was sie ist: keine Eigenschaft, die man kauft, sondern ein Maß an Kontrolle, das man sich erarbeitet. Die entscheidende Frage lautet nicht, wo die Server stehen, sondern wer im Ernstfall den Betrieb übernehmen kann und wer den Stack tatsächlich beherrscht, von der Hardware über die Plattform bis zu den Daten.

Diese Kontrolle hat mehrere Voraussetzungen, und keine davon ist allein hinreichend. Offene Standards und Open-Source-Software sind eine notwendige Grundlage, weil nur quelloffene Systeme prüfbar und übernehmbar sind. Hinreichend sind sie nicht, denn auch quelloffene Stacks hängen an Lieferketten, an Betrieb und an Finanzierung. Hinzu kommen Datenhoheit und die Fähigkeit, Dienste im Zweifel selbst zu betreiben, sowie eine Architektur, in der der konkrete Anbieter ein austauschbares Detail bleibt und kein Fundament, das sich nicht mehr herausziehen lässt.

Dabei ist Souveränität kein Alles-oder-nichts, sondern ein Spektrum, und welcher Grad nötig ist, ist eine fachliche Entscheidung. Nicht jede Arbeitslast braucht die höchste Stufe, denn ein öffentliches Marketingportal stellt andere Anforderungen als ein Fachverfahren mit Sozialdaten. Der Fehler liegt nicht darin, einen Hyperscaler zu nutzen, sondern darin, diese Wahl gar nicht erst zu treffen und alles unbesehen dorthin zu verlagern. Wer hingegen pro System bewusst entscheidet, welcher Grad an Kontrolle angemessen ist, betreibt Souveränität als Entwurfsdisziplin statt als Einkauf.

Selbst dort, wo volle Souveränität nicht erreichbar ist, gibt es eine Rückfalllinie, nämlich Resilienz: kundenseitig kontrollierte Verschlüsselung, Datenportabilität und technische Umkehrbarkeit als Schutz gegen extraterritorialen Zugriff. Das sind genau die Forderungen, die europäische Anbieter erheben, und sie sind pragmatischer als die Maximalforderung nach vollständiger Unabhängigkeit. Sie verlegen den Schwerpunkt von der Herkunft des Anbieters auf die tatsächliche Verfügungsgewalt über die eigenen Daten.

Diese Haltung ist im Kern nichts Neues, sondern ein altes Prinzip guten Entwurfs. Die Bindung an einen Anbieter ist Kopplung, und gute Architektur hält die Kopplung bewusst gering. Der Unterschied ist nur, dass die Kopplung an einen Hyperscaler selten als Entwurfsentscheidung wahrgenommen wird. Sie wird geerbt statt gewählt, und genau darin liegt das eigentliche Souveränitätsproblem, lange bevor ein Gesetz oder ein Etikett ins Spiel kommen.

Europa beginnt diese Lehre zu ziehen. Initiativen wie der EuroStack zielen auf eine offene, gemeinsame Infrastruktur, und in der öffentlichen Verwaltung laufen reale Migrationen weg von proprietären Plattformen, von Schleswig-Holstein bis Frankreich. Ob daraus eine tragfähige Alternative erwächst, ist offen, und ehrlicherweise ist dieser Weg mühsamer und teurer als das Anklicken eines als souverän etikettierten Angebots.

Genau deshalb ist die Begriffsklärung mehr als Wortklauberei. Solange „souverän“ ein Etikett bleibt, das die rechtliche Ebene ausspart, kauft man Datenresidenz und nennt sie Unabhängigkeit. Souveränität entsteht nicht durch ein Wort auf einem Datenblatt, sondern durch die Kontrolle über den eigenen Stack, und diese Kontrolle muss man wollen, bevor man sie haben kann.

(rme)

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)