Dynamic Central Orchestrator

Wie sich der DCO entwickelt hat

Der Dynamic Central Orchestrator, kurz DCO, entstand nicht nach einem fertigen Gesamtplan. Am Anfang stand ein vergleichsweise kleines Problem: Ich wollte Claude Code und mein eigenes Wissenssystem auch dann erreichen, wenn ich nicht am Rechner saß.

Daraus entstand zunächst ein Telegram-Bot. Danach kamen eine Warteschlange, Recherchewerkzeuge, Spracheingabe und eine mobile Oberfläche hinzu. Mit jeder Erweiterung wurde allerdings auch deutlicher, was dem System noch fehlte. Mehr Automatisierung verlangte nach besseren Sicherheitsgrenzen. Mehr Werkzeuge verlangten nach einer verständlicheren Oberfläche. Mehr selbstständige Arbeit verlangte danach, einzelne Abläufe nachvollziehen und bei Bedarf stoppen zu können.

Die folgende Zeitleiste zeigt deshalb nicht nur neue Funktionen. Sie zeigt auch, welche Grenze jeweils den nächsten Entwicklungsschritt ausgelöst hat.

März 2026: Der erste produktive Chat-Zugang

Das Ausgangsproblem

Mein Wissen lag auf dem lokalen Rechner. Claude Code konnte darauf zugreifen, aber nur während ich direkt an diesem Rechner arbeitete. Von unterwegs fehlte eine einfache Möglichkeit, Fragen zu stellen, Inhalte abzulegen oder einen Arbeitsauftrag anzustoßen.

Die erste Version des DCO verband deshalb Telegram mit einer lokal laufenden FastAPI-Anwendung. Claude Code wurde nicht über eine zusätzliche API angesprochen, sondern über die bereits vorhandene CLI-Subscription als lokaler Prozess.

Damit war der grundlegende Weg hergestellt:

1. Eine Nachricht kommt über Telegram an.
2. Der Cloudflare Tunnel leitet sie an den lokalen Rechner weiter.
3. Der DCO ruft Claude Code als Prozess auf.
4. Die Antwort geht über denselben Weg zurück.

Die erste Projektphase umfasste den produktiven Chat-Ablauf, Profile, eine Job-Tabelle und Telegram-Callbacks. Nach dem dokumentierten Projektstand war diese Stufe mit 79 grünen Tests abgeschlossen.

Was sich bewährte

Die lokale Architektur hielt private Daten und Werkzeuge auf dem eigenen Rechner. Gleichzeitig war der DCO von außen erreichbar, ohne einen Port am Router direkt freizugeben.

Welche Grenze sichtbar wurde

Ein direkter Aufruf funktionierte für einzelne Nachrichten. Sobald mehrere Aufgaben gleichzeitig eintrafen oder ein Auftrag länger dauerte, brauchte das System jedoch eine kontrollierte Verarbeitung.

Ende März 2026: Warteschlange, Triage und Sicherheitsgrenzen

In der zweiten Phase bekam der DCO eine Worker-Queue. Eine Worker-Queue ist eine Warteschlange, aus der begrenzt viele Aufgaben gleichzeitig verarbeitet werden. Im DCO dürfen zwei größere Claude-Aufrufe parallel laufen.

Vor dem eigentlichen Worker ordnet ein Portier die Anfrage ein. Einfache Anfragen können dadurch schneller behandelt werden, während komplexere Aufgaben an den vollständigen Arbeitsweg gehen.

Gleichzeitig kamen Admin-Funktionen, Risikostufen, Captures, Audit-Protokolle und eine WSL-Sandbox hinzu. WSL stellt unter Windows eine getrennte Linux-Umgebung bereit, in der bestimmte Befehle kontrollierter ausgeführt werden können.

Ein Security-Audit vom 31. März führte zu 27 Korrekturen. Dazu gehörten unter anderem Schutz gegen Server-Side Request Forgery, Begrenzungen für Anfragen, Pfadprüfungen und eine robustere Absicherung administrativer Befehle.

Was sich bewährte

Die Warteschlange entkoppelte den Eingang einer Nachricht von ihrer eigentlichen Bearbeitung. Telegram musste damit nicht so lange auf den vollständigen Claude-Lauf warten.

Welche Grenze sichtbar wurde

Der DCO konnte nun zuverlässig Aufgaben bearbeiten. Er hatte aber noch keinen breiten Zugang zum eigenen Wissensbestand und war für längere Inhalte oder Spracheingaben wenig geeignet.

Anfang April 2026: Recherche, NotebookLM und Sprache

Am 1. April wurde der DCO um ein Rechercheprofil, URL-Auswertung, NotebookLM und Spracheingabe erweitert.

NotebookLM wurde dabei als zusätzliche Recherche- und RAG-Schicht eingebunden. RAG bedeutet, dass ein Modell vor seiner Antwort gezielt Informationen aus einer vorhandenen Wissensbasis abruft. Für Spracheingaben kam Whisper hinzu, das Audiodateien lokal in Text umwandelt.

Damit wurde der DCO erstmals zu einer mobilen Zugangsschicht für mehrere Wissensquellen. Eine Telegram-Nachricht konnte nun nicht nur beantwortet werden, sondern eine Recherche, ein Briefing oder eine Suche im eigenen Wiki auslösen.

Was sich bewährte

Telegram eignete sich gut für schnelle Eingaben, Voice Memos und kurze Ergebnisse.

Welche Grenze sichtbar wurde

Je mehr Funktionen hinzukamen, desto ungeeigneter wurde ein reiner Chat als einzige Bedienoberfläche. Status, offene Freigaben, Ergebnisse und laufende Jobs ließen sich in einer Nachrichtenfolge nur schwer überblicken.

4. April 2026: Die Mini App wird zur mobilen Arbeitsfläche

Die nächste Entwicklungsstufe war eine Telegram Mini App. Sie ergänzte den Chat um eine strukturierte mobile Oberfläche für Inbox, laufende Aufträge, Freigaben und Ergebnisse.

Dabei blieb Telegram der schnelle Eingang. Die Mini App übernahm dagegen Aufgaben, bei denen man mehrere Zustände gleichzeitig sehen oder eine bewusste Auswahl treffen muss.

Telegram bleibt der schnelle Eingang. In der Mini App sehe ich dagegen, welche Aufträge warten, welche Entscheidung noch fehlt und welche Ergebnisse bereits vorliegen. Die beiden Oberflächen zeigen denselben Arbeitsweg aus unterschiedlichen Blickwinkeln.

Was sich bewährte

Die mobile Oberfläche trennte Unterhaltung und Betriebszustand voneinander.

Welche Grenze sichtbar wurde

Die Mini App löste mobile Aufgaben gut. Für Diagnose, Architektur und länger laufende Prozesse fehlte jedoch weiterhin eine größere Oberfläche.

Mitte April 2026: MCP verbindet den DCO mit seinen Werkzeugen

Am 15. April entstanden zwei MCP-Server. MCP ist die Schnittstelle, über die Claude Code definierte Werkzeuge ansprechen kann.

Der Wiki-Server stellte Funktionen zum Suchen, Lesen, Schreiben und Auflisten bereit. Ein zweiter Server bündelte weitere Werkzeuge, darunter NotebookLM, Obsidian, Web-Auswertung, PDF-Erzeugung und Telegram-Funktionen.

Damit wurde aus dem Chat-Assistenten eine operative Schicht über dem eigenen Wissenssystem.

Was sich bewährte

Die Werkzeuge erhielten definierte Schnittstellen. Claude musste nicht für jede Aufgabe wissen, wie eine Datei, ein Wiki oder NotebookLM technisch angesprochen wird.

Welche Grenze sichtbar wurde

Mit mehr Werkzeugen wurde es zunehmend schwieriger, nachzuvollziehen, was während eines Auftrags tatsächlich geschah.

17. bis 22. April 2026: Dashboard und visuelle Systemsicht

Am 17. April kam ein Live-Dashboard hinzu. Es zeigte laufende Prozesse, Ereignisse und den Zustand des Systems. Wenige Tage später folgte ein größeres visuelles Redesign mit Live-Flussdiagramm und einer einheitlicheren Oberfläche.

Damit entstanden drei unterschiedliche Zugänge zum selben Kern:

Telegram nimmt den Auftrag an, die Mini App ordnet mobile Entscheidungen und das Dashboard zeigt Diagnose und Architektur. Die drei Oberflächen konkurrieren nicht miteinander, sondern übernehmen verschiedene Teile desselben Ablaufs.

Was sich bewährte

Das Dashboard machte Prozesse sichtbar, die in Telegram nur als wartende Antwort erschienen.

Welche Grenze sichtbar wurde

Mit inzwischen mehreren Oberflächen entstanden Dopplungen. Funktionen, Begriffe und Zustände waren nicht überall gleich angeordnet.

Ende April 2026: Konsolidieren statt weiter anbauen

Am 27. und 28. April wurde die Mini App von neun auf fünf Hauptbereiche reduziert. Das Dashboard wurde von sechs auf vier Bereiche verdichtet. Anschließend folgte am 29. April ein größerer Konsolidierungssprint.

Dieser Abschnitt ist für die Entwicklungsgeschichte wichtig, weil er zeigt, dass Fortschritt nicht nur aus neuen Funktionen bestand.

Unter anderem wurde die Capture-Pipeline zentralisiert. Telegram und Mini App verwendeten danach denselben Verarbeitungspfad, statt ähnliche Logik getrennt zu pflegen.

Der dokumentierte Stand dieser Phase lag bei 925 grünen Tests.

Was sich bewährte

Die Konsolidierung verringerte Unterschiede zwischen den Oberflächen und reduzierte doppelte Implementierungen.

Welche Grenze sichtbar wurde

Mit Claude als einzigem Modell blieb eine andere Schwäche bestehen: Eine Antwort konnte plausibel klingen, ohne ausreichend widersprochen oder aus einer zweiten Perspektive geprüft zu werden.

8. bis 11. Mai 2026: Codex wird zur zweiten Perspektive

Am 8. Mai wurde Codex als zweites Brain eingebunden. Der DCO konnte Aufgaben damit nicht nur an Claude, sondern bei Bedarf auch an Codex weitergeben.

Wenige Tage später entstand daraus das dream-team. Dabei bearbeitet nicht einfach ein zweites Modell dieselbe Frage. Eine vorgeschaltete Triage entscheidet zunächst, ob eine zweite Meinung für den jeweiligen Fragetyp überhaupt sinnvoll ist.

Ein dokumentierter Lauf mit 50 Fragen zeigte zugleich, dass die zweite Meinung nicht in allen Bereichen gleich nützlich war. Für Architektur- und Arbeitsablauffragen entstand häufiger ein echter Widerspruch. Für mehrere andere Cluster brachte der zusätzliche Lauf keinen erkennbaren Mehrwert und wurde anschließend blockiert.

Was sich bewährte

Die zweite Perspektive wurde nicht pauschal eingeschaltet, sondern abhängig vom Fragetyp.

Welche Grenze sichtbar wurde

Mit mehreren Ausführungspfaden wurde die Frage dringender, wie ein einzelner Auftrag über Telegram, Worker, Werkzeuge und Modelle hinweg zusammenhängend verfolgt werden kann.

16. Mai 2026: Durchgängige Traces und ein gemeinsamer Ergebnisvertrag

Der Skill-Envelope-Sprint führte einen gemeinsamen Datenvertrag für Eingaben, Ergebnisse und Ablaufspuren ein.

Ein Trace ist dabei eine zusammenhängende Spur durch das System. Jeder Auftrag erhält eine Kennung, die vom Eingang über Worker, Claude, Skills und MCP-Aufrufe bis zur Antwort mitgeführt wird.

Der Trace beantwortet eine praktische Frage:

Was ist mit meinem Auftrag oder Voice Memo tatsächlich passiert?

Vorher musste diese Information aus mehreren Datenbanken und Protokollen zusammengesucht werden. Danach ließ sie sich über eine zusammenhängende Timeline im Dashboard öffnen.

Der Sprint umfasste 13 Phasen, 30 Commits und 16 neue Testdateien. Der spätere, am 28. Mai dokumentierte Teststand lag bei 1495 bestandenen Tests.

Was sich bewährte

Ein Auftrag wurde erstmals von Anfang bis Ende als zusammenhängender Vorgang sichtbar.

Welche Grenze sichtbar wurde

Der DCO konnte Abläufe nun besser nachvollziehen. Der nächste Schritt bestand darin, nicht nur einzelne Anfragen zu bearbeiten, sondern größere Entwicklungsaufträge selbstständig zu zerlegen, zu bauen und zu prüfen.

Ende Mai und Anfang Juni 2026: Von Aufträgen zu Agentenläufen

Am 30. Mai entstand ein größerer Agent-Run-Sprint. Wenige Tage später wurde die Bridge angebunden.

Die Bridge verbindet einen geplanten Auftrag mit einem getrennten Builder. Sie nimmt einen klar beschriebenen Job entgegen, führt ihn in einem kontrollierten Arbeitsbereich aus und liefert Ergebnis, Tests und Status zurück.

Damit begann die Entwicklung vom persönlichen Assistenten zum System, das auch an seiner eigenen Codebasis arbeiten konnte.

Was sich bewährte

Builder und Prüfung wurden voneinander getrennt. Ein Agent konnte eine Änderung umsetzen, ohne damit automatisch die Entscheidung über deren Übernahme zu treffen.

Welche Grenze sichtbar wurde

Ein System, das selbstständig Findings erzeugt und anschließend abarbeitet, kann mehr neue Arbeit produzieren, als es tatsächlich abschließt.

18. bis 24. Juni 2026: Codex findet UI-Probleme und der Loop wird gestoppt

Ab dem 18. Juni untersuchte Codex die DCO-Oberflächen mit Computer Use. Dabei entstanden datierte Findings zu Frontend, Backend und durchgehenden Abläufen.

Zwei Berichte wurden zusammengeführt und anschließend in isolierten Arbeitsbäumen abgearbeitet. Rund 34 Findings wurden in zwei Wellen umgesetzt. Der Browser-Smoke-Test endete ohne JavaScript-Fehler.

Danach wurde der Ablauf erweitert:

Technisch funktionierte der Ablauf. Als dauerhaft laufender Prozess konvergierte er jedoch nicht.

Der Producer fand ungefähr 14 neue Punkte pro Runde, während eine Abarbeitungswelle ungefähr drei Punkte abschloss. Der Backlog konnte dadurch trotz funktionierender Einzeljobs weiter wachsen.

Am 24. Juni wurde der Producer deshalb bewusst angehalten.

Der bewusste Stopp zeigt eine wichtige Grenze autonomer Systeme: Ein Ablauf kann technisch korrekt sein und trotzdem als Gesamtsystem ungeeignet bleiben.

25. Juni 2026: 28 UI-Runden im laufenden System

Nach dem Stopp des offenen Finding-Producers folgte ein klar begrenzter UI-Bau-Loop. In 28 Runden wurden vorhandene Findings gelesen, umgesetzt, geprüft und einzeln committet.

Die dokumentierte Bilanz:

• 28 Runden,
• ungefähr 90 umgesetzte Findings,
• 28 Commits,
• keine roten Tests,
• keine Überschreibung der produktiven Datenbank,
• ungefähr zwölf bewusst zurückgestellte Punkte.

Zwei Korrekturen betrafen unmittelbar die Sicherheit. Ein lokaler Windows-Pfad wurde aus der Oberfläche entfernt. Außerdem wurde der Dashboard-Token nicht mehr über eine URL, sondern über einen POST-Request übertragen.

Der Unterschied zum vorherigen Loop lag in der Begrenzung:

Der Loop hatte ein klares Ende. Er erzeugte nicht während der Abarbeitung unbegrenzt neue Arbeit.

26. Juni 2026: Ladezeit und vollständige Button-Abdeckung

Am folgenden Tag wurde die Oberfläche nicht weiter optisch erweitert, sondern systematisch vermessen.

Ein Audit zeigte, dass die Ladeprobleme nicht primär aus den einzelnen Dateien entstanden. Die eigentliche Ursache lag im Ausliefern: fehlende Komprimierung, fehlende Cache-Regeln und zahlreiche seriell geladene Skripte.

Daraufhin kamen GZip-Komprimierung, Cache-Control und verzögertes Laden der Skripte hinzu.

Parallel wurde die Verbindung zwischen Frontend und Backend in beide Richtungen geprüft:

Nach dem dokumentierten Audit gab es über ungefähr 221 geprüfte Aufrufstellen keine toten Buttons. Gleichzeitig wurden sieben Backend-Fähigkeiten gefunden, die keine sichtbare Oberfläche besaßen.

Damit wurde nicht nur geprüft, ob ein Button technisch reagiert. Es wurde auch in der Gegenrichtung untersucht, ob vorhandene Funktionen für den Nutzer überhaupt erreichbar sind.

Anfang Juli 2026: Der DCO wird zu einem kontrollierten Loop-Stack

Anfang Juli wurden mehrere zuvor getrennte Entwicklungsstränge zusammengeführt.

Der DCO besitzt nun eine Ideen-Pipeline, die Quellen auswertet, Vorschläge bewertet und sie nach einem Owner-Gate in ausführbare Aufgaben zerlegen kann. Danach übernimmt die Bridge den Build. Tests und Review entscheiden, ob das Ergebnis übernommen wird.

Gleichzeitig entstanden neue Betriebsfragen. Welcher Rechner baut? Welcher Rechner prüft? Ist ein Knoten erreichbar? Darf der Auftrag in einem anderen Repository ausgeführt werden?

Ein Topologie-Umschalter bildet dafür drei Betriebsarten ab:

Produktiv läuft derzeit im Wesentlichen der Ein-Knoten-Betrieb. Der vollständige Zwei-Knoten-Ablauf ist im Atlas noch nicht durchgehend als produktiver Standard belegt.

Der heutige Zusammenhang

Aus den einzelnen Entwicklungsschritten ist kein einzelner großer Agent entstanden. Der DCO besteht vielmehr aus mehreren klar getrennten Schichten.

Die Oberflächen dienen dabei unterschiedlichen Situationen:

• Telegram nimmt schnelle Eingaben, Voice Memos und kurze Entscheidungen entgegen.
• Die Mini App bündelt mobile Aufgaben, Freigaben und Ergebnisse.
• Das Dashboard zeigt Abläufe, Traces, Systemzustand und Architektur.
• Die Ops-Konsole verändert wenige betriebliche Schalter, die andere Oberflächen nur anzeigen.

Darunter bleibt der eigentliche Arbeitsweg gemeinsam. Anfragen werden geprüft, eingeordnet und in einer begrenzten Warteschlange verarbeitet. Claude Code ist das primäre Modell. Codex ergänzt den Ablauf als zweite Perspektive, Builder oder Reviewer.

Werkzeuge werden über MCP und direkte Runner angebunden. Das Trace-System protokolliert einzelne Anfragen. Das Pipeline-Journal hält autonome Entwicklungsabläufe zusammen. Watchdogs überwachen bestimmte Fehler- und Ausfallmuster.

Was sich durch die Entwicklung verändert hat

Im März war der DCO im Wesentlichen ein mobiler Zugang zu Claude Code.

Im April wurde er zu einer Oberfläche über meinem Wissens- und Werkzeugsystem.

Im Mai bekam er eine zweite Modellperspektive und durchgängige Ablaufspuren.

Im Juni begann er, seine eigene Oberfläche und Codebasis systematisch zu untersuchen und kontrolliert zu verändern.

Anfang Juli wurde daraus eine zusammenhängende Pipeline, die Ideen finden, bewerten, zerlegen, bauen und prüfen kann. Diese Autonomie bleibt jedoch an Freigaben, Tests, nachvollziehbare Zustände und bewusste Stopps gebunden.

Gerade die gestoppten oder zurückgebauten Abläufe gehören für mich zur Entwicklung dazu. Der DCO wurde nicht dadurch belastbarer, dass jede Automatisierung dauerhaft eingeschaltet blieb. Belastbarer wurde er dort, wo ich erkennen konnte, wann ein Ablauf nicht mehr sinnvoll arbeitete.