COOS.eu Pilotprojekt: Rekursives Projektmanagement-Tool mit Clawdbot‑Agenten: Grenzen, Potenzial und Risiken (31.1.2026)

In den letzten Tagen habe ich ein internes Pilotprojekt gestartet: COOS.eu als bewusst schlankes, rekursives Projektmanagement-System (Tree statt Over‑UI) – und Clawdbot als Agenten‑Layer, der Aufgaben nicht nur „verwaltet“, sondern sie abarbeitet, verifiziert, dokumentiert und Artefakte direkt am Task ablegt.

Das Spannende daran: Es ist kein „Chatbot nebenbei“, sondern ein Workflow, der aus Projektarbeit heraus Ergebnisse, Produkte und wiederverwendbare Tools entstehen lässt – inklusive Dokumentation.

---

Warum „rekursiv“?

COOS ist nicht primär Kanban, sondern ein Tree aus Nodes: Projekte → Teilprojekte → Aufgaben → Subtasks → → → . Der Agent arbeitet praktisch „von unten nach oben“: Er löst Leaves, erzeugt Ergebnisse, und verdichtet diese wieder im Parent. So wird das System mit wachsender Komplexität strukturierter – nicht chaotischer.

Was die Clawdbot‑Agenten in der Praxis tun (und warum das mehr ist als „Text schreiben“)

Der entscheidende Unterschied zu klassischen ChatGPT‑Workflows: Der Worker ist nicht nur „Co‑Pilot“, sondern macht 99% der Arbeit - bedient das System aktiv und als Werkzeugkasten:

• arbeiten, testen, verifizieren (nicht nur Vorschläge machen)
• Dateien erzeugen (Reports, Fixtures, PDFs, XMLs, Screenshots, CSVs) und als Attachments an Tasks hängen
• Tools installieren, skripten und nutzen (Validatoren, CLI‑Checks, kleine Helper)
• Dokumentation direkt am Task (kurz, verlinkt, nachvollziehbar)
• aus Projektarbeit heraus sogar Tools entwickeln, die später in anderen Projekten wiederverwendet werden können

Wichtig: Ergebnisse landen nicht „irgendwo im Chat“, sondern als:

• kurzer Update‑Text im Node (Status + Ergebnis)
• Attachments/Links (Artefakte), die später wieder auffindbar sind

Warum das mit ChatGPT/Codex so stark wird

Wir nutzen das Modell‑Setup mit ChatGPT/Codex, das sich weniger wie „Chat“ anfühlt und mehr wie ein Engineering‑Worker: Analyse + Implementierung + iterative Verifikation.

Das bringt in der Praxis:

• starke Analysefähigkeit (Specs verstehen, Fehlerbilder erkennen)
• starke Programmierfähigkeit (Scripts, Fixes, Tests, Glue‑Code)
• schnelle Schleifen: Hypothese → Implementierung → Run → Ergebnis dokumentieren

Potenzial: Was dadurch realistisch möglich wird

Wenn es sauber aufgesetzt ist, entsteht eine „Task‑to‑Artifact Pipeline“:

• weniger Kontextwechsel („wo war das nochmal?“)
• mehr Abschluss („Done heißt verifiziert“)
• schnellere Exploration (PoCs, Validator‑Runs, Testdaten)
• Wiederverwendbarkeit: einmal gebaute Tools tauchen später als Bausteine in anderen Projekten wieder auf

Grenzen

1) Fehlender Domain‑Kontext

Wenn Informationen nicht im Repo/Tree/Attachments liegen (z.B. „wo entsteht das Basis‑PDF in Prod?“), kann der Agent nur suchen und fragen. Dafür braucht es klare Delegationsregeln: eine präzise Frage, dann Stop.

2) „Noise“ durch zu viele Subtasks / Logs

Ohne Verdichtung entstehen tiefe Trees und viel Text. Das ist lösbar – aber nicht automatisch.

Risiken: Wenn Modelle besser werden, kann es für Menschen unlesbarer werden

Ein Punkt zeichnet sich ab: Modelle schreiben oft eine sehr abstrakte, techniklastige Projektdokumentation. Für Maschinen/Engineers extrem nützlich – aber nicht immer für Menschen, die den Business‑Faden halten wollen.

Mit stärker werdenden Modellen wächst das Risiko, dass:

• Updates in „Systemsprache“ kippen
• Notizen wie interne Engineering‑Logs wirken
• Menschen irgendwann nur noch Bahnhof verstehen
• Projektschritte schwerer nachvollziehbar werden (zu viele implizite Annahmen)

Mögliche Gegenmaßnahmen:

• harte Regeln für Executive Summaries pro Parent‑Node (3–6 bullets, kein Logspam)
• Trennung: Engineering‑Notes vs. Ergebnis‑Summary
• automatische Verdichtung (Children done → Summary im Parent, Details weg/archiviert)

Fazit

Der große Hebel ist nicht „ein guter Prompt“. Der Hebel ist ein System, in dem Agenten:

• kontrollierte Freiheit haben
• verifizieren müssen
• Ergebnisse als Artefakte ablegen
• und am Ende Noise wieder verdichtet wird

PPS: Das ganze habe ich in 5 Tagen als MVP mit ClawdBot (aktuell openclaw.ai) und Codex gebaut, ist in ersten Live-Umgebungen aktiv und produziert Resultate- man darf sich gar nicht vorstellen, welche Möglichkeiten OpenAI, Anthropic und Microsoft haben.

So wird aus „Projektmanagement“ ein rekursives Projektmanagement‑Tool mit Clawdbot‑Agenten, das Projekte nicht nur verwaltet, sondern messbar voranbringt und Ergebnisse produziert.