Ein selbst gebautes Agentensystem, das Telegram, FastAPI, Claude/ und -Tools zu einem durchgehenden Arbeitsfluss verbindet. Es hat drei Flächen mit klar verteilten Aufgaben:
Für die Rolle: Diese Arbeitsprobe zeigt nicht nur einen Bot, sondern wie ich den Betrieb dahinter denke: mit Warteschlange, Freigaben, Telemetrie, Tool-Grenzen und Fehlerpfaden, die sichtbar bleiben. Das ist für Rollen in KI-Automatisierung und Agenten-Engineering relevant.
Zuletzt aktualisiert: · ein Projekt von Dominic Meiser
Nachrichtenfluss vom Eingang bis zum Ergebnis aus dem DCO-Tour-Modus: synthetische Beispieldaten, der Schutz der öffentlichen Ansicht bleibt sichtbar.
Komplette Oberfläche ansehenEin steuernder Kern, mehrere Oberflächen und eine wachsende Bibliothek aus spezialisierten Agenten, Tools und Wissensquellen.
Stand 01.07.2026Quelle DCO-Repo stack-state.json (gen:stack)
Die Sicherheitsarchitektur unten ist kein abstraktes Prinzip, sondern die Antwort auf konkrete Vorfälle. Zweimal ist echter Schaden entstanden; daraus sind bewusste Sicherheitsnetze geworden.
Zweimal hat die eigene Test-Suite die lokale Arbeitsdatenbank des Systems geleert, beide Male trotz vermeintlicher Isolation.
Eine Modul-Konstante wie DB_PATH = str(DATA_DIR / 'calls.db') friert den Pfad zur Import-Zeit ein und überlebt keinen Test-Override.
Der DB-Pfad wird über eine lazy Funktion gelesen, die ihn bei jedem Aufruf frisch auflöst; dazu ein Poison-Guard, der einen Lauf gegen die echte Daten-DB hart stoppt.
Ein Agent mit Shell-Zugriff kann jeden Befehl tippen, auch rm -rf oder DROP TABLE.
Eine naive Substring-Suche blockt auch den eigenen legitimen Aufruf, wenn rm -rf nur als Text in einem gequoteten Argument steht.
Ein PreToolUse-Hook maskiert zuerst alle gequoteten Spans, prüft dann den Befehlsteil gegen destruktive Muster und schreibt ein sanitisiertes Audit-Log. Erkannte Muster blockt er deterministisch; nur Unklares passiert fail-open mit Log-Eintrag. Die bewusste Abwägung: Ein Guard, der legitime Arbeit falsch blockt, wird abgeschaltet und schützt dann niemanden. Die bekannten Grenzen sind im Log-Post dokumentiert.
Dieses Kapitel erzählt die Projektgeschichte des DCO. Den größeren Rahmen, wie die Werkstatt insgesamt entstanden ist, hält die Chronik der Werkstatt fest.
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.
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.
| Monat | Kernentwicklung | Grenze, die den nächsten Schritt auslöste |
|---|---|---|
| März | Telegram-Zugang mit Warteschlange, Triage und ersten Sicherheitsgrenzen | Direkte Aufrufe reichten nicht mehr, sobald mehrere Aufgaben gleichzeitig eintrafen |
| April | Recherche, Sprache, Mini App, MCP-Werkzeuge und Dashboard | Mit mehr Werkzeugen wurde schwerer nachzuvollziehen, was während eines Auftrags geschah |
| Mai | Codex als zweite Modellperspektive, durchgängige Traces, gemeinsamer Ergebnisvertrag | Ein Auftrag musste über Telegram, Worker, Werkzeuge und Modelle hinweg verfolgbar werden |
| Juni | Der DCO untersucht und verändert seine eigene Oberfläche, kontrolliert und mit Stopps | Ein System, das selbst Findings erzeugt, kann mehr Arbeit produzieren, als es abschließt |
| Juli | Kontrollierter Loop-Stack: Ideen finden, bewerten, zerlegen, bauen, prüfen | Autonomie bleibt an Freigaben, Tests und bewusste Stopps gebunden |
Wer nur diesen Überblick liest, kennt den Weg. Die Zeitleiste dahinter erzählt jeden Schritt ausführlich, jeweils mit dem, was sich bewährt hat, und der Grenze, die sichtbar wurde.
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.
Telegram erreicht über einen Cloudflare Tunnel den DCO auf dem Windows-Rechner; der ruft Claude Code über die Kommandozeile auf, und die Antwort geht denselben Weg zurück nach Telegram.
Damit war der grundlegende Weg hergestellt:
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.
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.
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.
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.
Eine Telegram-Anfrage durchläuft Authentifizierung und Idempotenzprüfung; der Portier beantwortet Einfaches direkt, Komplexes geht über die Worker-Queue an Claude Code und kommt als Antwort oder Artefakt zurück.
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.
Die Warteschlange entkoppelte den Eingang einer Nachricht von ihrer eigentlichen Bearbeitung. Telegram musste damit nicht so lange auf den vollständigen Claude-Lauf warten.
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.
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.
Text und Voice Memos laufen zusammen: Sprache transkribiert Whisper, danach gehen beide Eingabearten über den Portier an Claude Code, das Wiki-MCP, NotebookLM oder Web-Recherche nutzt und die Antwort nach Telegram liefert.
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.
Telegram eignete sich gut für schnelle Eingaben, Voice Memos und kurze Ergebnisse.
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.
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-Chat und Mini App sprechen denselben DCO-Kern an; Inbox, Aufträge, Freigaben und Ergebnisse fließen in die Mini App zurück.
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.
Die mobile Oberfläche trennte Unterhaltung und Betriebszustand voneinander.
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.
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.
Claude Code erreicht über die MCP-Schnittstelle zwei Server: den Wiki-Server (suchen, lesen, ergänzen) und den Skills- und Tool-Server (NotebookLM, Obsidian, Web und PDF, Telegram und Dateien).
Damit wurde aus dem Chat-Assistenten eine operative Schicht über dem eigenen Wissenssystem.
Die Werkzeuge erhielten definierte Schnittstellen. Claude musste nicht für jede Aufgabe wissen, wie eine Datei, ein Wiki oder NotebookLM technisch angesprochen wird.
Mit mehr Werkzeugen wurde es zunehmend schwieriger, nachzuvollziehen, was während eines Auftrags tatsächlich geschah.
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:
Drei Oberflächen um einen Kern: Telegram für schnelle Eingaben und die Mini App für mobile Steuerung schreiben in den DCO-Kern, das Dashboard liest ihn zum Prüfen und Verstehen.
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.
Das Dashboard machte Prozesse sichtbar, die in Telegram nur als wartende Antwort erschienen.
Mit inzwischen mehreren Oberflächen entstanden Dopplungen. Funktionen, Begriffe und Zustände waren nicht überall gleich angeordnet.
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.
Die Konsolidierungskette: Viele neue Funktionen machten die Oberflächen unübersichtlich; Tabs und Begriffe prüfen, Dopplungen entfernen und gemeinsame Abläufe zentralisieren führte zu weniger sichtbarer Komplexität.
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.
Die Konsolidierung verringerte Unterschiede zwischen den Oberflächen und reduzierte doppelte Implementierungen.
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.
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.
Die Cluster-Triage entscheidet je Frage: Ohne erwartbaren Mehrwert antwortet Claude direkt; sonst erstellt Claude eine Position, Codex widerspricht oder ergänzt, und die Zusammenführung zeigt die Differenzen sichtbar in der Antwort.
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.
Die zweite Perspektive wurde nicht pauschal eingeschaltet, sondern abhängig vom Fragetyp.
Mit mehreren Ausführungspfaden wurde die Frage dringender, wie ein einzelner Auftrag über Telegram, Worker, Werkzeuge und Modelle hinweg zusammenhängend verfolgt werden kann.
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 Sequenzablauf einer Anfrage: Der Eingang erzeugt eine Trace-ID, der Portier reiht den Auftrag beim Worker ein, Claude Code ruft Werkzeuge über MCP oder Skills auf, die Antwort geht mit Trace-ID zurück nach Telegram, und die Ablaufspuren landen im Dashboard.
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.
Ein Auftrag wurde erstmals von Anfang bis Ende als zusammenhängender Vorgang sichtbar.
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.
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.
Aus einem Ziel oder Finding wird eine beschriebene Aufgabe und daraus ein Bridge-Job: Ein isolierter Builder erzeugt Code und Tests, der Verifier entscheidet zwischen Review und Merge oder Rückgabe und Eskalation.
Damit begann die Entwicklung vom persönlichen Assistenten zum System, das auch an seiner eigenen Codebasis arbeiten konnte.
Builder und Prüfung wurden voneinander getrennt. Ein Agent konnte eine Änderung umsetzen, ohne damit automatisch die Entscheidung über deren Übernahme zu treffen.
Ein System, das selbstständig Findings erzeugt und anschließend abarbeitet, kann mehr neue Arbeit produzieren, als es tatsächlich abschließt.
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:
Der erweiterte Kreislauf: Codex untersucht die Oberfläche, Findings gehen durch Kuration und Bridge in die Umsetzung, Tests und Browser-Prüfung sichern den Merge, und der Lauf beginnt von vorn.
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.
Die Konvergenz-Rechnung: Etwa 14 neue Findings pro Runde treffen auf etwa drei abgeschlossene pro Welle; wird der Backlog nicht kleiner, wird der Producer pausiert und das Betriebsmodell überarbeitet.
Der bewusste Stopp zeigt eine wichtige Grenze autonomer Systeme: Ein Ablauf kann technisch korrekt sein und trotzdem als Gesamtsystem ungeeignet bleiben.
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:
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 begrenzte Loop: Aus einem festen Finding-Bestand wird pro Runde ausgewählt, umgesetzt, getestet, im Browser geprüft und einzeln committet, bis keine geplante Runde mehr übrig ist.
Der Loop hatte ein klares Ende. Er erzeugte nicht während der Abarbeitung unbegrenzt neue Arbeit.
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:
Die Prüfung in beide Richtungen: Buttons führen über Frontend-Aufrufe zu Backend-Routen und Fähigkeiten; das Backend-Inventar fragt umgekehrt, ob jede Fähigkeit eine UI-Aktion besitzt, sonst wird sie als verwaist 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 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.
Die Ideen-Pipeline: Der Finder bewertet Quellen und offene Probleme, das Owner-Gate lehnt ab, stellt zurück oder gibt frei; freigegebene Aufgaben laufen über Bridge, Builder und Tests zum Verifier, der merged oder zurückgibt.
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:
Drei Bridge-Topologien mit gemeinsamem Pipeline-Journal: Ein Knoten (ein Rechner baut und prüft), klassisch (feste Rollen pro Rechner) und verteilt (Jobs nach Zustand verteilt).
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.
Aus den einzelnen Entwicklungsschritten ist kein einzelner großer Agent entstanden. Der DCO besteht vielmehr aus mehreren klar getrennten Schichten.
Die heutigen Schichten des DCO: Drei Bedienflächen und die Ops-Konsole führen über Authentifizierung, Idempotenz, Portier und Worker-Queue zu Claude Code und Codex; Werkzeuge hängen an MCP, die Autonomie-Kette läuft vom Finder über Owner-Gate, Zerlegung und Bridge zum Verifier, und Trace-System, Audit-Protokoll, Pipeline-Journal und Watchdogs machen alles nachvollziehbar.
Die Oberflächen dienen dabei unterschiedlichen Situationen:
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.
Den Weg vom mobilen Zugang zum kontrollierten Loop-Stack fasst der Überblick am Kapitelanfang in fünf Sätzen zusammen. Hier bleibt die Beobachtung, die diesen Weg trägt: 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.
DCO — meine Steuerzentrale für die Arbeit mit KI-Agenten.
Privates Produktions-Repository. Architektur, Betrieb und Oberfläche sind hier öffentlich dokumentiert; getrennte Referenzimplementierungen sind unter „Zum Nachprüfen“ verlinkt.
Ich mache Inputs, Outputs und Grenzen lieber explizit, statt sie in der Architektur zu vergraben.
Die jüngste Verschiebung geht in Richtung Betrieb und Sichtbarkeit: ein nur lesendes Betriebs-Cockpit, eine kontrollierte MCP- und Skills-Fläche und automatische Hygiene-Checks für die Wissensbasis; schreibende Aktionen bleiben weiterhin eng geführt.
Ein nur lesendes Betriebs-Cockpit für die Bridge-Schicht: Systemzustand, Kennzahlen, Eskalations-Spiegel und der Heartbeat der Worker (ihr regelmäßiges Lebenszeichen). Timeout-Grenzen sorgen dafür, dass langsame Quellen den Server nicht blockieren.
Eine eigene Mini-App-Fläche für Direct-MCP-Tools und freigegebene Skills. Nur lesende Tools laufen ohne Admin-Gate; schreibende Tools brauchen eine ausdrückliche Admin-Freigabe, destruktive bleiben draußen.
Ein nur lesender Hygiene-Lauf für das Wissens-Notebook prüft Duplikate, Beispiel-Quellen und fachliche Relevanz. Einen reinen Vendor-Korpus meldet er als Warnfall, auch wenn technisch alles gesund ist.
Der DCO-Showcase wurde nach dem Website-Audit als konkrete Fix-Kampagne nachgezogen: zehn geprüfte Zielbereiche, 55 kleine Fixes, danach Build, Tests und ein Browser-Nachweis statt reiner Statusmeldung.
Jetzt prüfbar
Der produktive DCO, seine Konfiguration und echte Betriebsdaten bleiben privat. Die öffentlichen Repositories arbeiten mit synthetischen Daten und sind kein Export des Produktivsystems.
Dieses System nimmt bei mir täglich echte Aufträge an, prüft Freigaben und hält den Ablauf fest. Die Seite zeigt deshalb, wie ich Steuerung und Betrieb von Agenten denke.
Die Steuerungsschicht der Werkstatt: Sie bringt Agenten, Tools, Memory, Freigaben und den Betriebsblick in einen wiederholbaren Arbeitsfluss.
Übertragbar sind ein vertrauter Eingang, klare Zuständigkeiten, Freigabewege, ein nur lesender Betriebsblick und mobile Oberflächen für Agentensysteme.
DCO Reference für Queue, Worker, Verifikation und Freigabe-Gate; Orchestrated Bridge für Agenten-Loop und menschliches Review-Gate; dazu UI-Galerie und dokumentierte Sicherheitsvorfälle.
Kein fremdes Kundenprodukt, keine offene Produkt-API und keine Behauptung eines universellen Auto-Agenten.
Sechs kuratierte Flächen erzählen den Weg: vom Überblick über Nachrichtenfluss, Trace, Architektur und Freigaben bis zur Skill-Konsole. Erfasst am 20.06.2026 im Tour-Modus mit synthetischen Beispieldaten; der komplette Katalog liegt dahinter zum Aufklappen.
Agenten dürfen vieles, aber nicht alles und nicht ohne Spuren. DCO behandelt Sicherheit nicht als Feature, sondern als Architekturentscheidung.
Die wichtigsten Erkenntnisse aus dem laufenden Eigenbetrieb und die Muster, die sich daraus auf andere Agenten-Abläufe übertragen lassen. Es sind belastbare Arbeitsnotizen.
Telegram ist als Einstieg bequem. Sobald Skills, Tools, Status und Historie wichtig werden, braucht das System eine Mini-App mit sichtbaren Aktionen.
Wiederkehrende Arbeit wird erst tragfähig, wenn Sessions, Entscheidungen und Projektkontext über einzelne Agentenläufe hinaus erhalten bleiben.
Tool-Zugriffe, Freigabe-Pfade und Logs lassen sich später nur schwer sauber nachrüsten, wenn die Architektur schon beliebig gewachsen ist.
Ein vertrauter Kanal reduziert Reibung. Erst danach lohnt sich komplexe Agentenlogik.
Spezialisierte Agenten sind leichter zu testen als ein großer Monolith-Prompt.
Tools müssen versionierbar, auditierbar und wiederverwendbar sein, sonst bleibt es Demo-Code.
Ohne operative Sichtbarkeit ist ein Agentensystem nur schwer verantwortbar.
Sensible Aktionen brauchen explizite Freigaben, nicht nur bessere Systemprompts.
Eine kleine UI-Schicht hilft, wenn Chat für Entscheidungen und Überblick nicht reicht.
Die Antworten halten fest, was der DCO ist und wo seine bewussten Grenzen liegen.
Ein selbst gebautes Agentensystem, das Telegram, FastAPI, Claude/Codex und MCP-Tools zu einem durchgehenden Arbeitsfluss verbindet — meine Steuerungs- und Beobachtungsschicht für KI-gestützte Arbeitsabläufe.
Nein. Es gibt kein Auto-Deploy — schreibende CI-Pfade brauchen menschliche Freigabe, und schreibende MCP-Tools laufen grundsätzlich über das Freigabe-Gate; der Direct-Path bleibt nur lesend.
Keine automatischen Selbstreparaturen: Lieber ein sichtbarer Fehler als eine stille Reparatur ohne Audit. Fehlerpfade und Freigaben bleiben im System sichtbar.
Nein. Eine Anmeldung für mehrere Nutzer ist bewusst nicht vorgesehen; das Admin-Gate hält den Kreis klein, und Repo-Schreibrechte sind ausdrücklich pro Profil freigegeben.
Wenn dich ein bestimmter Workflow, eine Risikoentscheidung oder eine Bedienoberfläche interessiert, schreib mir direkt. Die Seite bleibt bewusst ein öffentlicher Blick auf ein laufendes Lab-System.