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.
Telegram EntrypointMini App KonsoleDashboard Diagnose/skill Direct-Path/mcp Read-onlyGuardrailsTour-Modus
Dashboard · Diagnosefläche
Die Screenshots stammen aus dem DCO-Tour-Modus. Sie zeigen bewusst Beispieldaten und halten den Public-Surface-Schutz sichtbar.
— 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.
Erkunde einen Agentenlauf
Ein public-safe Beispiel, 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
- 19 read-only MCP Direct-Tools
- 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 · Mai 2026
Von Werkzeugschicht zu planendem, abgesichertem Betrieb.
Die jüngste Verschiebung: DCO plant mehrstufige Abläufe in Varianten, holt bei Bedarf eine unabhängige zweite Meinung ein und überwacht sich sicherheitsseitig selbst — bei weiterhin enger Führung schreibender Aktionen.
shipped
/plan Multi-Variant-Planner
Ein Ziel erzeugt drei validierte Ablauf-Varianten (knapp, gründlich, umfassend) als Vorschlag. Erst die Auswahl per Button materialisiert den echten Plan mit Start, Ändern und Abbruch.
- Drei Varianten
- Vorschlag vor Start
- Inline-Auswahl
shipped
Zweites Brain als Subagent
Neben dem primären Modell ist ein zweiter, unabhängiger Modell-Provider als Subagent verfügbar — für Code-Analyse, Review und zweite Meinung. Read-only Sandbox, das primäre Modell bleibt Default.
- Ask · Review · Security
- Read-only Sandbox
- Opt-in pro Profil
shipped
Security-Whistleblower
Ein täglicher Audit-Lauf meldet ausschließlich neue Befunde hoher Schwere — restart-sicher über Fingerprints, damit Bekanntes nicht erneut alarmiert. Sicherheit als laufender Hintergrundprozess.
- Täglicher Lauf
- Nur neue Findings
- Restart-sicher
— 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
— 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.