Excom als Multi-Bot-Meilenstein
TL;DR
Der wichtige Schritt war nicht volle Autonomie, sondern saubere Arbeitsteilung: Excom wurde erstmals als sichtbarer Koordinationsraum genutzt, in dem Bots Aufgaben verteilen, Grenzen markieren und Folgearbeit in den Build-Prozess zurückführen.
Basis in den Logs
- OpenClaw-Changelog vom 8. bis 10. Mai 2026: Excom-Routing, Allowlist-Härtung, CEO-Bus und Daily-Decision-Briefing.
- Incident-Log vom 8. bis 10. Mai 2026: Bot-Identität, Bot-to-Bot-Grenzen, Intent-Routing und heutige Kennzeichen-Nacharbeit.
Was gemacht wurde
- Die operative Geschichte aus den internen Logs als öffentliche Journal-Note formuliert.
- Private Chat-IDs, Bot-Handles und Rohnachrichten bewusst nicht übernommen.
- Den Meilenstein als Koordinationsmuster beschrieben, nicht als Behauptung vollständiger Autonomie.
Verifiziert
- Der Text enthält keine Chat-IDs, keine geheimen Routing-Details und keine wörtlichen Telegram-Auszüge.
- Die Note ist im Notes-Loader registriert und damit über das Build-Journal erreichbar.
Warum
Multi-Bot-Setups werden erst dann belastbar, wenn nicht nur mehrere Modelle antworten, sondern Zuständigkeiten, Übergaben und Widerspruch sichtbar werden. Genau dieser Übergang ist heute zum ersten Mal als eigener Betriebsmodus greifbar geworden.
Excom als Multi-Bot-Meilenstein
Am 10. Mai 2026 war Excom zum ersten Mal mehr als ein gemeinsamer Telegram-Kanal.
Bis dahin war das Multi-Bot-Setup vor allem eine Sammlung einzelner Fähigkeiten: Tyrone für operative Aufgaben, Hermesto als Reflexions- und Entscheidungsschicht, Codex für Code, Tests und Deployment-Arbeit. Das war nützlich, aber noch kein System. Ein System entsteht erst, wenn diese Rollen nicht nur nebeneinander existieren, sondern sich gegenseitig sichtbar Arbeit geben, Grenzen akzeptieren und Ergebnisse wieder in denselben Build-Zusammenhang zurückführen.
Genau das ist heute passiert.
Der eigentliche Fortschritt
Der Meilenstein ist nicht, dass Bots plötzlich alles alleine entscheiden.
Der Fortschritt ist kleiner und wichtiger:
- Ein Bot kann eine Aufgabe als offene Entscheidung oder Nacharbeit markieren.
- Ein anderer Bot kann diese Aufgabe aufnehmen, ohne den gesamten Kontext neu zu erfinden.
- Der Kanal bleibt für Dominik lesbar, weil Zuständigkeiten und Grenzen explizit sind.
- Aus Chat-Koordination wird wieder Code, Changelog, Incident-Log oder Journal.
Damit wird Excom zu einer Art sichtbarem Übergaberaum. Nicht perfekt, nicht magisch, aber operativ brauchbar.
Warum das anders ist als paralleles Prompting
Mehrere Bots parallel laufen zu lassen ist schnell gebaut. Mehrere Bots so arbeiten zu lassen, dass sie sich nicht gegenseitig überstimmen, ist die eigentliche Schwierigkeit.
Die letzten Tage haben dafür die nötige Kleinarbeit geliefert: Identitätsregeln, Intent-Routing, harte Grenzen zwischen technischer Erwähnung und tatsächlichem Auftrag, ein CEO-Bus für Entscheidungen und ein tägliches Briefing, das Meinungen nicht einfach addiert, sondern mit Evidenz versieht.
Heute wurde daraus zum ersten Mal ein praktischer Ablauf.
Das fühlt sich wie ein kleiner Infrastrukturmoment an: Nicht, weil eine große neue Funktion live ging, sondern weil das Setup anfängt, Verhalten zu zeigen, das man wiederholen kann.
Was öffentlich daran interessant ist
Die internen Details bleiben intern. Chat-IDs, Handles, Rohlogs und konkrete private Entscheidungen gehören nicht ins Journal.
Öffentlich interessant ist die Form:
Ein Multi-Agent-System wird nicht durch viele Stimmen wertvoll. Es wird wertvoll, wenn diese Stimmen Arbeit teilen, Unsicherheit markieren und ihre Ergebnisse nachvollziehbar in Artefakte überführen.
Excom war heute der erste Ort, an dem das bei uns sichtbar genug wurde, um es nicht mehr nur als Experiment, sondern als Meilenstein zu behandeln.