Problem01
Agentische Arbeit bleibt ohne Betriebsschicht fragil.
Einzelne Prompts und Tools reichen nicht, wenn wiederkehrende Aufgaben, Kontext, Freigaben und Status über mehrere Sessions hinweg stabil bleiben sollen.
— Flagship-System · Lab
Dynamic Central Orchestrator
Ein gebautes Agentensystem, das Telegram, FastAPI, Claude/Codex und MCP-Tools in einem operativen Workflow verbindet. Telegram bleibt die primäre Eingabe- und Freigabefläche, die Mini App ist die mobile Arbeitskonsole und das Dashboard ist die Desktop-Fläche für Beobachtung, Diagnose und Architekturtransparenz.
DCO — persönliche Orchestrierungsschicht für agentische Workflows.
Für die Rolle: Diese Arbeitsprobe belegt nicht nur einen Bot, sondern Betriebsschicht-Denken — Queue, Freigaben, Telemetrie, Tool-Grenzen und sichtbare Fehlerpfade. Relevant für AI-Automation und Agentic Engineering.
Telegram EntrypointMini App KonsoleDashboard Diagnose/skill Direct-Path/mcp Read-onlyGuardrailsTour-Modus
Privates Repository. Architektur, Betrieb und Oberfläche sind hier öffentlich dokumentiert — der Code bleibt geschlossen, ein Walkthrough ist auf Anfrage möglich.
Dashboard · Diagnosefläche
Die Screenshots stammen aus dem DCO-Tour-Modus. Sie zeigen bewusst Beispieldaten und halten den Public-Surface-Schutz sichtbar.
Aktueller Stand · Juni 2026
Laufende Welle: read-only Ops-Cockpit, kontrollierte MCP-/Skills-Fläche und automatische Hygiene-Checks der Wissensbasis. Schreibende Aktionen bleiben eng geführt.
— Warum gebaut?
Von Agenten-Demo zu Arbeitsmaschine.
Der Ausgangspunkt war nicht ein Kundenauftrag, sondern eine praktische Frage: Wie muss ein System aussehen, das Coding-Agenten, Recherche, Tools, Memory und Freigaben in echte wiederholbare Arbeit bringt?
DCO ist deshalb ein eigenes Experimentierfeld: Telegram als vertrauter Einstieg, ein Orchestrator für Routing und Kontext, MCP-Tools als kontrollierte Fähigkeiten, Dashboard und Mini-App für Betrieb, Status und Freigaben.
Die Seite dokumentiert nicht "so sieht ein fertiges Produkt aus", sondern: welche Bauteile sich bisher bewährt haben, welche Entscheidungen tragen und welche Fragen im Lab-Modus noch offen sind.
— Case Study
DCO in 30 Sekunden.
Eine kompakte Lesart für Menschen, die nicht jedes technische Detail kennen müssen, aber schnell verstehen wollen, was hier gebaut wurde und was es belegt.
System02
DCO verbindet Einstieg, Orchestrierung, Tools und Sichtbarkeit.
Telegram, FastAPI, Mini App, Dashboard, Memory und MCP-Tools bilden einen zusammenhängenden Arbeitsfluss statt einer losen Demo-Sammlung.
Entscheidungen03
Nicht jede Automatisierung bekommt denselben Freiheitsgrad.
Read-only Pfade sind direkter nutzbar, während schreibende oder riskante Aktionen enger geführt werden und Approval-Denken brauchen.
Ergebnis04
Ein laufendes Lab-System mit prüfbaren Artefakten.
Dashboard, Tests, Tool-Grenzen, Skill-Picker, MCP-Explorer und Audit-Logik machen den Fortschritt sichtbar und diskutierbar.
Signal05
DCO zeigt, wie ich offene Systeme strukturiere.
Die Arbeitsprobe verbindet Architektur, Produktdenken, Sicherheitsbewusstsein, Dokumentation und iterative Umsetzung.
Public-safe Fixture - abgeleitet aus realem DCO-Muster - keine Live-Daten
Betriebsstand: Live-System getrennt von Tour-Modus und Fixture; dieser Ablauf ist Fixture, keine Live-Daten.
Erkunde einen Agentenlauf
Eine public-safe Fixture, wie DCO Routing, Tool-Aufrufe, Entscheidungen und Outcomes als nachvollziehbaren Ablauf sichtbar macht.
- Step 1Router00:01
Signal einordnen
Der Orchestrator trennt Ziel, Kontext und Risiko, bevor ein Spezialagent gestartet wird.
Erledigt - Step 2Inspector00:07
Kontext sammeln
Ein Analyseagent liest Repo-Konventionen, aktuelle Dateien und Testsignale.
Erledigt - Step 3Reviewer00:18
Umsetzung freigeben
Die Entscheidung wird mit Teststatus, sichtbarem Outcome und naechstem Schritt dokumentiert.
Laeuft
— Arbeitsprobe
Was DCO im Einsatz sichtbar macht.
Die Arbeitsprobe liegt im gebauten Zusammenhang: Architektur, Tool-Grenzen, Bedienoberflächen und Sicherheitsentscheidungen werden gemeinsam sichtbar.
Systemdenken
DCO verbindet Chat, Backend, Tool-Schicht, Memory, Dashboard und Freigaben zu einem zusammenhängenden Arbeitsfluss.
- Mehrere Oberflächen
- MCP-Tool-Grenzen
- Operations-Sicht
Verantwortung
Nicht jede Aktion wird automatisiert. Schreibende oder riskante Pfade bleiben bewusst enger geführt als read-only Werkzeugnutzung.
- Admin-Gates
- Audit-Logs
- Approval-Denken
Iteration im Betrieb
Die Seite dokumentiert kein fertiges Produkt, sondern ein laufendes Lernsystem mit messbaren Verbesserungen und offenen Fragen.
- Tests
- Telemetry
- Werkstatt-Logik
— Architektur
Welche Bauteile sich bisher bewährt haben.
Ein steuernder Kern, mehrere Oberflächen und eine wachsende Bibliothek aus spezialisierten Agenten, Tools und Wissensquellen.
Interface Layer
- Telegram Bot
- Mini App (WebApp)
- Operations Dashboard
Orchestrator Core
- Routing & Planning
- Memory & Context
- Eval & Telemetry
Tool Layer
- 20 read-only MCP Direct-Tools (Teil der 41 MCP-Tools gesamt, siehe Stack)
- Whitelisted Claude-Code-Skills
- Custom FastAPI Tools
Goldener Pfad: User-Request laeuft durchs Approval-Gate. Read-only MCP-Aufrufe passieren das Gate ohne Halt, schreibende Aktionen brauchen explizite Freigabe.
Cyan-Pfad: Orchestrator-interne Routing-Entscheidung. Direct-Path umgeht den Brain-LLM fuer read-only Tools, schreibende Pfade gehen ueber den vollen Stack.
— Kontrakt · Lab
Was DCO leisten will — und wo bewusst Grenzen sind.
Inputs, Outputs und Grenzen explizit machen, statt sie in die Architektur zu vergraben.
Inputs
Was geht rein.
- Telegram-Nachrichten und Mini-App-Commands
- Skill-Picker-Auswahl mit Argumenten
- MCP-Tool-Aufrufe (read-only Direct-Path)
- Approval-Antworten auf sensible Aktionen
- Skill-Job-Ergebnisse aus Subprocesses
Outputs
Was kommt raus.
- Telegram-Antworten und Mini-App-Konsole-Updates
- Dashboard-Diagnose-Streams (Tour-Modus)
- Skill-Artefakte als Dateien oder Snippets
- MCP-Tool-Responses und Audit-Logs
- Approval-Anfragen mit Begründung
Grenzen
Was DCO nicht macht.
- Kein Auto-Deploy in ProductionSchreibende CI-Pfade brauchen menschliche Freigabe.
- Kein freies Schreiben in fremde ReposRepo-Schreibrechte sind explizit pro Profil whitelisted.
- Kein Brain-LLM-Bypass für schreibende MCP-ToolsDirect-Path bleibt read-only, alles andere geht über Approval-Gate.
- Keine Self-Repair-Loops bei API-OutageLieber sichtbarer Fehler als stille Reparatur ohne Audit.
- Kein eingebettetes Auth ohne Admin-GateMulti-User-Auth ist nicht im Scope, Admin-Gate hält den Kreis klein.
— Neu im System · Juni 2026
Von Werkzeugschicht zu sichtbarem, abgesichertem Betrieb.
Die jüngste Verschiebung geht in Richtung Betrieb und Sichtbarkeit: ein read-only Ops-Cockpit, eine kontrollierte MCP- und Skills-Fläche und automatische Hygiene-Checks für die Wissensbasis — schreibende Aktionen bleiben weiterhin eng geführt.
shipped
Ops-Konsole für den Betrieb
Ein read-only Betriebs-Cockpit für die Bridge-Schicht: Health, Metrics, Eskalations-Mirror und Worker-Heartbeat. Timeout-Guards sorgen dafür, dass langsame Quellen den Server nicht blockieren.
- Health · Metrics · Heartbeat
- Read-only
- Timeout-geschützt
shipped
MCP- & Skills-Steuerfläche
Eine eigene Mini-App-Fläche für Direct-MCP-Tools und whitelisted Skills. Read-only Tools laufen ohne Admin-Gate; schreibende und destruktive Tools bleiben bewusst gesperrt.
- Direct-MCP · Skills
- Read-only ohne Gate
- Schreibend gesperrt
shipped
Notebook-Hygiene als Ops-Check
Ein read-only Hygiene-Lauf für das Wissens-Notebook prüft Duplikate, Beispiel-Quellen und fachliche Relevanz — und meldet einen reinen Vendor-Korpus als Warnfall, auch wenn technisch alles gesund ist.
- Read-only Check
- Duplikat + Relevanz
- Vendor-Warnfall
— Interfaces
Telegram, Mini App & Dashboard.
Drei Ausschnitte desselben Systems: Chat als Einstieg, Mini App als mobile Konsole, Dashboard als Diagnosefläche im Tour-Modus oben.
Telegram
DCO Bot
Tour-Chat
/skill weekly-report --tour
Skill-Job angelegt. Quellen: Wiki, Tasks, Artefakte.
Freigabe für Zusammenfassung.
Ergebnis bereit. Details in Mini App und Dashboard.
Beispielausschnitt ohne private Inhalte
Mini App
SkillsMCPJobs
Skill Picker
Whitelisted Aktionen starten
MCP Explorer
Args-Schema vor Ausführung
Approvals
Freigaben mobil prüfen
Dashboardsiehe oben
Status
Tour
Daten
synthetisch
Voller Dashboard-Showcase im ersten Abschnitt
— UI-Galerie
Die komplette Oberfläche, Seite für Seite.
Jeder Dashboard-Reiter und jede Mini-App-Seite — am 20.06.2026 im Tour-Modus mit synthetischen Beispieldaten erfasst, also ohne private Inhalte. Bild anklicken zum Vergrößern.
Dashboard7 Reiter · Tour-Modus
Command Center — Operator-Überblick
- Live-Status aller Subsysteme (Inbox, Briefing, Loop, Bridge) auf einen Blick
- Gesamtzustand groß (bereit / warn)
- Kennzahlen: Eingang, Queue, Agenten-Verbesserung, Wissen
- Tages-Tokenverbrauch & Budget ($) mit Spark-Trend
Nachrichtenfluss — End-to-End
- Pipeline vom Telegram-Eingang bis zum Worker-Pool
- Live-Event-Feed der durchlaufenden Nachrichten
- Sonderpfade: Voice Notes, URL-Scraping, Admin-Commands
- Signal-Mapping: welche Eingabe welche Funktion auslöst
Agenten / Pipeline — Ideen-Finder & Auto-Queue
- Quellen der Kreativ-Runde (Web, Wiki, Traum, Crazy, UI-Lücken)
- Automatik: Autonomie-Stufe, tägliche Cron-Runde, Uhrzeit
- Ziel der nächsten Runde: Kategorie, Ziel-Repo, Top-K
- Eigene Idee einreichen → landet im Freigabe-Gate
Agent Studio — Orchestrierung
- Workbench zum Starten/Importieren von Agent-Runs
- Übersichten: Rollen, Runs, Skills, Bridge-Jobs, Reviews
- Feature-Explorer aller DCO-Funktionen
- Technische Referenz: Commands, Skills, MCP, REST-API
Wiki / NLM — Wissensgraph
- Vernetzte Wiki-/Vault-Seiten als interaktiver 3D-Graph
- Vault + Startknoten wählen, Tiefe einstellen
- Knoten anklicken → Nachbarn + Aktionen (Capture / NLM / Chain)
- Knoten-/Kanten-Zähler + Konvergenz-Status
Architektur — System & Sicherheit
- Geschichtetes Architektur-Diagramm (Eingang → Daten → Tools)
- Datenbank-Übersicht (Tabellen, Stand, Felder)
- Device-Mesh-Status (Cross-Device)
- Sicherheitskontrollen-Raster (Whitelist, Rate-Limit, Sanitize …)
Trace — Job-Verfolgung
- Trace-ID eingeben → Job lückenlos end-to-end verfolgen
- Liste der letzten Traces, Filter „nur Fehler“
- Permalink-Format zum Teilen eines Traces
- Direktsprung zur Fehlerliste der letzten Jobs
Mini App5 Seiten · Tour-Modus
Center — mobiles Command Center
- Status-Kacheln (Eingang, Aktivität, Agenten, System)
- Chat-Eingabe + Auto-Loop-Schalter
- „Läuft gerade“-Live-Zeile des aktuellen Laufs
- Bridge-Block mit aktiven Jobs & Queue
Eingang — Capture-Inbox
- Captures: Notiz, Link, Sprachnotiz, Dokument
- Such- + Status-/Typ-Filter
- Bulk-Routing → Wiki, → NotebookLM, Löschen
Queue — Arbeit & Freigaben
- Status-Filter (Aktiv / Wartet / Fertig / Fehler)
- Freigaben mobil prüfen (Prüfen & Mergen)
- Chains mit Fortschritt + Qualitäts-Score
- Fehler-Sektion mit Ursache + Retry
Wissen — Ergebnis-Archiv
- Archiv: Briefings, Recherchen, Audio-Overviews, Abläufe
- Typ-Filter (Briefings / Audio / Recherche)
- Pro Karte: Typ-Badge, Quellen, Details-Link
Mehr — Funktions-Hub
- Gruppiertes Verzeichnis aller Sekundär-Funktionen
- Arbeit: Aufgaben, Kalender, Freigaben
- Orchestrierung: Workflows, MCP & Skills, Skill-Konsole
- System: Tagebuch, Briefing & NLM, Nutzung, Reauth
Mini App — Detail-Seiten10 Unterseiten · aus dem „Mehr"-Hub
Aufgaben — Todo-Queue
- Tag-Filter (Projekt, Recherche, Admin, Warten-auf, Bridge)
- Neue Todos anlegen, erledigte ein-/ausblenden
- Offene Aufgaben + Bridge-Backlog getrennt
- Stale-Marker (≥7d / ≥14d)
Kalender — Erinnerungen
- Erinnerung mit Wiederholung (täglich/werktags/wöchentlich …)
- Schnellzeiten (Heute / Morgen / +1h / +1d)
- Geplante Erinnerungen mit Restzeit + Löschen
Freigaben — mobile Approvals
- Offene Freigaben, die auf dein OK warten
- Job-Bezug (ID, Quelle)
- Prüfen / Freigeben / Ablehnen direkt mobil
Wiki / MCP — Wissens-Hub
- Read-only Wiki-Suche über MCP (wiki_search)
- Doku planen (Zielpfad, Modus, Preview)
- Medien einordnen (Quelle, Zielordner, Wiki-Link)
- Wissen + Vault-Kontext durchsuchen
Tagebuch — private Timeline
- Einträge neueste zuerst (read-only, owner-only)
- Pro Eintrag: Datum, Quelle, Mood, Tags
Briefing & NotebookLM
- NotebookLM-Status (angemeldet, Default-Notebook)
- Briefing holen (kompakte Lage)
- Audio-Briefing (Podcast aus Captures)
- Notebook befragen, Quellen ein-/anlagern
Workflows — Kompass & Referenz
- Workflow-Kompass: lose Eingaben → Entscheidungen/Briefings
- Direkt nutzbare Commands (/lage, /briefing, /todo …)
- Profile + Vorlagen & Tools
- System-Referenz (Commands/Intents/Profile)
MCP & Skills — Tool-Fläche
- Read-only MCP-Direct-Tools, nach Kategorie gruppiert
- Tool ausführen mit Args-Eingabe-Sheet
- Schreibende Tools bewusst nicht freigeschaltet (Guardrail)
Skill-Konsole — persistenter Chat
- Skill wählen (yt-report, briefing, wiki-query, code-reviewer …)
- Eigene Konsole pro Skill, Kontext bleibt erhalten
- Langer Modus für ausführliche Antworten
Nutzung — Verbrauch & Latenz
- Zeitraum (24h/7d/30d/90d), Tokens vs. Calls
- Token-Verlauf pro Tag
- Profile-Verbrauch (Tokens/Aufrufe/Erfolgsrate)
- MCP-Tool-Stats (Aufrufe, Latenz, Fehlerrate)
— Aus Fehlern gebaut
Sicherheitsnetze, weil etwas kaputtging.
Die Sicherheitsarchitektur unten ist kein abstraktes Prinzip — sie ist die Antwort auf konkrete Vorfälle. Zweimal ist echter Schaden entstanden; daraus wurden bewusste Guardrails.
Test-DB-Isolation
Vorfall
Zweimal hat die eigene Test-Suite die produktive Datenbank geleert — beide Male trotz vermeintlicher Isolation.
Lehre
Eine Modul-Konstante wie DB_PATH = str(DATA_DIR / 'calls.db') friert den Pfad zur Import-Zeit ein und überlebt keinen Test-Override.
Guardrail
Der DB-Pfad wird über eine lazy Funktion gelesen, die ihn bei jedem Aufruf frisch auflöst — plus ein Poison-Guard, der einen Lauf gegen die echte Daten-DB hart stoppt.
rm -rf-Block-Hook
Vorfall
Ein Agent mit Shell-Zugriff kann jeden Befehl tippen — auch rm -rf oder DROP TABLE.
Lehre
Eine naive Substring-Suche blockt auch den eigenen legitimen Aufruf, wenn rm -rf nur als Text in einem gequoteten Argument steht.
Guardrail
Ein PreToolUse-Hook maskiert zuerst alle gequoteten Spans, prüft dann den Befehlsteil gegen destruktive Muster und schreibt ein sanitisiertes Audit-Log — fail-open, damit der Guard nicht aus Frust abgeschaltet wird.
— Operations & Security
Kontrolle als Designprinzip.
Agenten dürfen vieles — aber nicht alles, und nicht ohne Spuren. DCO behandelt Sicherheit nicht als Feature, sondern als Architekturentscheidung.
- Policy-basierte Guardrails pro Tool und Aktion
- Audit-Log für geroutete Tool Calls
- Approval-Workflows für sensitive Operationen
control planepolicy + approval + audit
Read-only Tools
direkt nutzbar
Write Actions
Approval Gate
Private Daten
nicht im Showcase
Audit Trail
relevante Tool-Spuren
RequestPolicyTrace
Die Abbildung zeigt den Sicherheitsgedanken: Aktionen laufen nicht unsichtbar durch, sondern werden geroutet, klassifiziert, freigegeben oder protokolliert.
Beispielhafte Steuerlogik, keine echten Laufzeitdaten
— Gelernt
Was DCO über Agentensysteme zeigt.
Die wichtigsten Erkenntnisse aus dem laufenden Eigenbetrieb. Nicht als Verkaufsversprechen, sondern als belastbare Arbeitsnotizen.
learning / 01
Chat ist gut für Startsignale, direkte Controls sind besser für Betrieb.
Telegram ist als Einstieg bequem. Sobald Skills, Tools, Status und Historie wichtig werden, braucht das System eine Mini-App mit sichtbaren Aktionen.
learning / 02
Memory ist kein Bonus, sondern Infrastruktur.
Wiederkehrende Arbeit wird erst tragfähig, wenn Sessions, Entscheidungen und Projektkontext über einzelne Agentenläufe hinaus erhalten bleiben.
learning / 03
Security muss vor der Automatisierung mitgedacht werden.
Tool-Zugriffe, Approval-Pfade und Logs lassen sich später nur schwer sauber nachrüsten, wenn die Architektur schon beliebig gewachsen ist.
— Wissensbasis
Ein System mit Gedächtnis.
DCO operiert nicht im Vakuum. Jeder Agent hat Zugriff auf ein strukturiertes Obsidian-Wiki und kuratierte NotebookLM-Quellen — typisierte Relationen zwischen Konzepten, Integrationen, Werkzeugen und Nutzungsweisen. Diese Wissens- und Memory-Schicht ist Teil des Agentic Stack. Das ist das Gegenteil von "Prompt-Engineering auf Zuruf".
- Über 1000 typisierte Wiki-Seiten
- Kuratierte NotebookLM-Notebooks pro Wissensdomäne
- Agenten lesen und schreiben via MCP
Obsidian Wiki · Knowledge Graph
Vereinfachte, öffentliche Sicht auf das Wiki-Netz: Projektseiten, Skills, Memory, MCP, Dokumentation und Laufspuren hängen als Arbeitsgraph zusammen.
— Übertragbare Patterns
Welche Muster tragfähig wirken.
Diese Muster sind die eigentliche Ausbeute: nicht DCO als Kopie, sondern Architekturentscheidungen, die auch in anderen Agenten-Workflows nützlich sein können.
/01
Single Entrypoint
Ein vertrauter Kanal reduziert Reibung. Erst danach lohnt sich komplexe Agentenlogik.
/02
Routing-Logik
Spezialisierte Agenten sind leichter zu testen als ein großer Monolith-Prompt.
/03
MCP-Tooling
Tools müssen versionierbar, auditierbar und wiederverwendbar sein, sonst bleibt es Demo-Code.
/04
Dashboard-Layer
Ohne operative Sichtbarkeit ist ein Agentensystem nur schwer verantwortbar.
/05
Guardrails & Approvals
Sensible Aktionen brauchen explizite Freigaben, nicht nur bessere Systemprompts.
/06
Mini-App Surface
Eine kleine UI-Schicht hilft, wenn Chat für Entscheidungen und Überblick nicht reicht.
— Lernsignal & Sparring
Welche DCO-Frage soll ich als nächstes zeigen?
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.