Vierzehn Laufzeitumgebungen und ein einziger Installationsbefehl — mit dieser Zahl beginnt die Projektbeschreibung von Ouroboros auf GitHub. Sie verrät, worum es dem Entwickler geht: nicht um ein weiteres Assistenten-Fenster, sondern um eine Schicht, die unter allen gängigen KI-Kommandozeilen gleich funktioniert. Der Autor des Repositories, ein Entwickler mit dem Kürzel Q00, nennt das Projekt ein Agent OS für KI-gestütztes Programmieren.
Die Argumentation ist ungewöhnlich bodenständig. Nicht das Modell sei der Engpass, heißt es in der Projektbeschreibung, sondern die Unklarheit des Menschen davor. Wer heute mit Claude Code, Codex CLI oder Gemini CLI arbeitet, kennt das Muster: Der Prompt ist vage, das Modell rät, das Ergebnis wird nachgebessert. Hier setzt Ouroboros an und verweigert sich dem, was sein Autor Prompt Engineering nennt.
Drei Repos, ein Stapel: Shell, Anwendungen und Betriebssystem
Wer ein Betriebssystem baut, kommt an einer Dreiteilung kaum vorbei, und Ouroboros übernimmt sie fast lehrbuchhaft. Der Kernel liegt im Repository Q00/ouroboros und besitzt den Vertrag: Jede Aktion wird an eine Spezifikation gebunden, im Ledger protokolliert und damit wiederholbar gemacht — unabhängig davon, welches Sprachmodell sie ausführt. Darüber liegt die Anwendungsschicht in Ouro-labs/ouroboros-plugins, wo Domänenabläufe wie Pull-Request-Prüfung, Jira-Synchronisation oder Release-Steuerung als installierbare Plugins mit begrenzten Rechten deklariert werden. Ganz oben sitzt mit Ouro-labs/ourocode eine Terminal-Oberfläche, in der sich diese Abläufe über mehrere CLIs hinweg in einer Sitzung bedienen lassen.
Das ist mehr als eine Ordnerstruktur. Es ist der Versuch, KI-Arbeit in etwas zu verwandeln, das sich wie ein System verhält und nicht wie eine Reihe einzelner Zurufe. Wer nur den Kernel nutzt, kann das mit jeder unterstützten CLI tun; wer Plugins dazunimmt, bekommt wiederkehrende Abläufe mit Prüfspur; wer Ourocode installiert, sitzt in einem einzigen Cockpit. Man kann sich das wie eine Baustelle vorstellen, auf der es einen verbindlichen Plan gibt, ein Bautagebuch und eine Abnahme — und auf der der ausführende Handwerker wechseln darf, ohne dass sich der Plan ändert.
Das Interview als Schleuse: Unklarheit bekommt eine Zahl
Bevor irgendetwas gebaut wird, fragt Ouroboros zurück. Der Einstieg ist ein sokratisches Interview, das mit dem Kommando ooo interview beginnt und Annahmen offenlegt, die im ursprünglichen Wunsch schlicht fehlten. Interessant ist dabei weniger die Befragung selbst als ihre Ausgabe: Der Lauf endet mit einem Ambiguitätswert, also einer Zahl dafür, wie unklar die Aufgabenstellung noch ist. In einem der Demonstrationsvideos läuft ein Kart-Rennspiel über einen Discord-Bot und landet bei einem Wert von 0,15.
Das Interview ist damit kein Plausch, sondern eine Schleuse — ein Gate, das den Lauf erst passieren lässt, wenn genug Klarheit hergestellt ist. Die Projektbeschreibung spricht von Interview-gated Evaluation und nennt daneben sogenannte Advisory Lanes, also beratende Nebenläufe, die zusätzliche Fragen aufwerfen. In Claude Code laufen sechs solcher Spuren parallel, bevor die Antworten ins Interview zurückfließen. Nicht allein die Person am Bildschirm entscheidet also, wann es losgeht, sondern eine messbare Schwelle.
Der Seed: Eine Spezifikation, die nach dem Start nicht mehr verhandelt wird
Aus dem Interview entsteht der Seed — eine eingefrorene Spezifikation, die festhält, was gebaut werden soll. Der Entwickler beschreibt ihn als unveränderliche Absicht, die vor der ersten Codezeile feststeht; Änderungen am Plan führen nicht zu einem nachträglichen Umbau, sondern zu einem neuen Lauf. Genau hier liegt der Unterschied zu einem spezifikationsbasierten KI-Agenten ohne Prompt Engineering: Es gibt keinen frei formulierten Zuruf mehr, an dem sich das Modell entlanghangelt, sondern einen Vertrag, gegen den jedes Ergebnis geprüft wird.
Für die Praxis ist das ein spürbarer Bruch mit der Gewohnheit. Statt in mehreren Runden nachzuschärfen, verbringt man Zeit vor dem Bau. Das kann sich zäh anfühlen, besonders bei kleinen Aufgaben. Bei Vorhaben, die über Stunden laufen und an denen später noch jemand anderes arbeiten soll, zahlt sich die Investition dagegen häufig aus, weil die Absicht dokumentiert ist und nicht in einem Chatverlauf verpufft.
Die Prüfung steht nicht im Vertrag: dreistufige Bewertung
Ein Detail der Projektdokumentation ist bemerkenswert — wie alle Angaben hier stammt es aus dem Repository des Entwicklers, unabhängige Messungen liegen nicht vor. Der Prüfbefehl und das erwartete Ergebnis, schreibt der Autor, gelangen nie in den Erfolgsvertrag, den der Agent erhält. Mit anderen Worten: Das Modell weiß nicht, woran es gemessen wird, und kann die Abnahme deshalb nicht gezielt umspielen. Die Auswertung selbst läuft in drei Stufen und automatisiert, was sonst mit einem wohlwollenden „sieht gut aus“ endet. Diese Trennung von Ausführung und Bewertung ist der Kern des Entwurfs.
Man darf das trotzdem nicht mit Sicherheit verwechseln. Eine Prüfung ist nur so gut wie die Bedingungen, die jemand vorher hineingeschrieben hat. Fehlen sie, fällt die Abnahme je nach Glück aus oder eben durch. Wer das System betreibt, verlagert die Verantwortung also nach vorn, in die Formulierung der Kriterien. Das ist unbequemer als das Nachbessern im Chat, aber ehrlicher, weil es die Prüflogik sichtbar macht.
Der budgetierte Evolutionszyklus und das Ledger
Ouroboros läuft, scheitert und wird mit jeder Generation klüger — so fasst es der Autor zusammen. Dieser Kreislauf ist budgetiert, also mit einem Aufwandsrahmen versehen, damit die Selbstverbesserung nicht endlosläuft. Jeder Durchgang wird im Ledger festgehalten, einem Protokoll, in dem jede Aktion als Ereignis mit Bezug zum Seed steht. Daraus entstehen replaybare AI-Workflows: Ein Lauf lässt sich später nachvollziehen, wiederholen und vergleichen, statt sich an ein Ergebnis zu erinnern.
Diese Kombination erklärt den Namen. Die Ouroboros-Schlange, die sich in den eigenen Schwanz beißt, deutet hier nicht auf Selbstzerstörung, sondern auf einen geschlossenen Kreis aus Ausführen, Bewerten und Nachschärfen — im Rahmen eines Budgets und auf einem nachvollziehbaren Protokoll. Ein Budgeted Evolution Loop in der KI-Entwicklung ist damit nichts Esoterisches, sondern eine Kostenbremse mit Gedächtnis. Das unterscheidet den Entwurf von spontaner Agenten-Begeisterung.
Vierzehn Runtimes, ein MCP-Server
Die Breite der Integration ist der praktischste Teil des Projekts. Ein MCP Server für mehrere KI-Runtimes bedeutet, dass dieselben Werkzeuge — Interview, Auto-Modus, Workflow-Steuerung — über das Model Context Protocol in sehr verschiedenen Hosts auftauchen: Claude Code, Codex CLI, GitHub Copilot CLI, OpenCode, Gemini, Kiro, Goose und weitere. Das Setup erkennt die vorhandenen Laufzeiten und schreibt jeweils die Artefakte, die ein Host erwartet — Regeln und Skills für Codex, ein Plugin samt AGENTS.md für OpenCode, Brücken für Pi und GJC. Bei Copilot und Kiro werden die Modellkataloge live abgefragt, statt fest eingebaut zu sein.
Der Zuschnitt auf lokale Arbeit ist auffällig. Ouroboros beschreibt sich als local-first: Der Kernel läuft auf der eigenen Maschine, die Installation erfolgt über einen einzigen Befehl, und die Konfiguration bleibt in Dateien, die man einsehen kann. Ein lokales Agent OS für KI-Coding ist damit kein Cloud-Dienst mit Sitzungsgrenzen, sondern eine Schicht unter der eigenen Werkbank. Die Claude Code Integration ist dabei nur eine von vielen Türen in dasselbe Haus.
Was das konkret bedeutet
Ouroboros ist kein Werkzeug, das man kurz ausprobiert und wieder weglegt. Es verlangt, die eigene Arbeitsweise umzustellen: erst fragen lassen, dann planen, dann bauen, dann prüfen lassen — und jeden Schritt protokollieren. Wer ohnehin mit mehreren KI-Kommandos arbeitet und dabei den Überblick verliert, findet hier eine Lösung. Wer überwiegend kleine, klar umrissene Aufgaben erledigt, wird den Aufwand dagegen selten rechtfertigen können.
Zwei Randnotizen gehören zur Einordnung. Der Autor weist darauf hin, dass das Projekt mit keiner Kryptowährung und keinem Token zu tun hat, obwohl der Name auf manchen Plattformen anderweitig belegt ist. Außerdem existiert ein zweites, unabhängiges Open-Source-Projekt namens Ouroboros, das an der eigenen Architektur schreibt, statt eine Spezifikation einzufrieren — ein anderer Ansatz, kein gemeinsamer Code. Wer von einem sich selbst umbauenden Agenten liest, sollte deshalb prüfen, welches der beiden gemeint ist.
Ob ein Agent OS für KI-Coding-Workflows den Alltag breiter Entwicklerteams verändert, hängt weniger an der Zahl der unterstützten Runtimes als an der Bereitschaft, vor dem Bauen Klarheit herzustellen. Genau das ist die These des Projekts. Man muss sie nicht teilen, aber sie ist präzise genug, um sie zu prüfen.
Quelle: github.com
