Das hier ist gerade mein Terminal.

tmux-Session mit 13 Agenten

13 Claude Code Agenten, jeder in seinem eigenen tmux-Pane, auf derselben Codebase. Kein Experiment. Kein Flex. So shippe ich jeden Tag Software.

Das Projekt ist Beadbox, ein Echtzeit-Dashboard zur Überwachung von KI-Coding-Agenten. Es wird von genau der Agentenflotte gebaut, die es überwacht. Die Agenten schreiben den Code, testen ihn, reviewen ihn, paketieren ihn und liefern ihn aus. Ich koordiniere.

Wenn du mehr als zwei oder drei Agenten laufen hast und dich fragst, wie du den Überblick behältst: Das hier ist mein Stand nach Monaten der Iteration. Ein Bug wurde um 9 Uhr morgens gemeldet und war um 15 Uhr geshippt, während vier andere Workstreams parallel liefen. Es läuft nicht immer glatt, aber der Durchsatz ist echt.

Das Team

Jeder Agent hat eine CLAUDE.md-Datei, die seine Identität definiert: wofür er zuständig ist, wofür nicht, und wie er mit anderen Agenten kommuniziert. Das sind keine generischen „Mach alles"-Assistenten. Jeder hat einen klar abgegrenzten Job und explizite Grenzen.

Gruppe	Agenten	Zuständigkeit
Koordination	super, pm, owner	Arbeitsverteilung, Produkt-Specs, Business-Prioritäten
Engineering	eng1, eng2, arch	Implementierung, Systemdesign, Test-Suites
Qualität	qa1, qa2	Unabhängige Validierung, Release-Gates
Operations	ops, shipper	Plattform-Tests, Builds, Release-Durchführung
Growth	growth, pmm, pmm2	Analytics, Positionierung, öffentliche Inhalte

Das Schlüsselwort ist Grenzen. eng2 kann keine Issues schließen. qa1 schreibt keinen Code. pmm fasst den App-Quellcode nie an. Super verteilt Arbeit, implementiert aber nicht. Die Grenzen existieren, weil Agenten ohne sie abdriften. Sie „helfen", indem sie Code refactoren, der kein Refactoring brauchte, Issues schließen, die nicht verifiziert waren, oder Architekturentscheidungen treffen, für die sie nicht qualifiziert sind.

Jede CLAUDE.md beginnt mit einem Identitäts-Abschnitt und einer Abgrenzung. Hier eine gekürzte Version von eng2:

## Identity
Engineer for Beadbox. You implement features, fix bugs, and write tests. You own implementation quality: the code you write is correct, tested, and matches the spec.

## Boundary with QA
QA validates your work independently. You provide QA with executable verification steps. If your DONE comment doesn't let QA verify without reading source code, it's incomplete.

Das Pattern skaliert. Als ich mit 3 Agenten angefangen habe, reichte ein einzelner lockerer Prompt. Bei 13 sind explizite Rollen und Protokolle der Unterschied zwischen Koordination und Chaos.

Die Koordinationsebene

Drei Tools halten die Flotte zusammen.

beads ist ein Open-Source, Git-nativer Issue-Tracker, der genau für diesen Workflow gebaut wurde. Jede Aufgabe ist ein „Bead" mit Status, Priorität, Abhängigkeiten und einem Kommentar-Thread. Agenten lesen und schreiben über eine CLI namens bd in dieselbe lokale Datenbank.

bd update bb-viet --claim --actor eng2   # eng2 übernimmt einen Bug
bd show bb-viet                           # vollständige Spec + Kommentare anzeigen
bd comments add bb-viet --author eng2 "PLAN: ..."  # eng2 postet seinen Plan

gn / gp / ga sind tmux-Messaging-Tools. gn schickt eine Nachricht an das Pane eines anderen Agenten. gp schaut in die letzte Ausgabe eines anderen Agenten (ohne ihn zu unterbrechen). ga reiht eine nicht dringende Nachricht in die Queue ein.

gn -c -w eng2 "[from super] You have work: bb-viet. P2."  # Dispatch
gp eng2 -n 40                                               # Fortschritt prüfen
ga -w super "[from eng2] bb-viet complete. Pushed abc123."  # Rückmeldung

CLAUDE.md-Protokolle definieren Eskalationswege, Kommunikationsformat und Abschlusskriterien. Jeder Agent weiß: Bead claimen, Plan kommentieren bevor man codet, Tests laufen lassen vor dem Push, DONE mit Verifikationsschritten kommentieren, für QA markieren, an super zurückmelden.

So sieht das in der Praxis aus. Das hier ist ein echtes Bead von heute: super weist die Aufgabe zu, eng2 kommentiert einen nummerierten Plan, eng2 kommentiert DONE mit QA-Verifikationsschritten und abgehakten Akzeptanzkriterien, super dispatcht an QA.

Ein echter Bead-Kommentar-Thread mit dem vollständigen PLAN/DONE-Workflow

Super läuft alle 5 bis 10 Minuten eine Kontrollrunde: Ausgabe jedes aktiven Agenten prüfen, Bead-Status checken, sicherstellen, dass die Pipeline nicht stockt. Wie eine Rufbereitschaft in der Produktion, nur dass die Services KI-Agenten sind und die Incidents „eng2 ist seit 20 Minuten verdächtig still" heißen.

Ein echter Tag

Das hier ist tatsächlich an einem Mittwoch Ende Februar 2026 passiert.

9:14 Uhr – Ein GitHub-User namens ericinfins öffnet Issue #2: Er kann Beadbox nicht mit seinem Remote-Dolt-Server verbinden. Die App unterstützt nur lokale Verbindungen. Owner sieht es und leitet es an super weiter.

9:30 Uhr – Super verteilt die Arbeit. Arch entwirft einen Connection-Auth-Flow (TLS-Toggle, Username/Passwort-Felder, Übergabe von Umgebungsvariablen). PM schreibt die Spec mit Akzeptanzkriterien. Eng übernimmt und fängt an zu implementieren.

Gleichzeitig, parallel:

PM meldet zwei Bugs, die beim Release-Testing aufgefallen sind. Einer ist kosmetisch: Das Header-Badge zeigt „v0.10.0-rc.7" statt „v0.10.0" bei finalen Builds. Der andere ist plattformspezifisch: Das Screenshot-Tool liefert einen leeren Streifen auf ARM64-Macs, weil Apple Silicon die Tauri-WebView über Metal Compositing rendert und der Backing Store leer ist.

Ops findet die Root Cause des Screenshot-Bugs. Der Fix ist elegant: Nach dem Capture prüfen, ob die Bildhöhe verdächtig klein ist (unter 50px für ein Fenster, das 800px hoch sein sollte), und auf koordinatenbasierte Bildschirmaufnahme zurückfallen.

Growth zieht PostHog-Daten und macht eine IP-Korrelationsanalyse. Das Ergebnis: Reddit Ads haben 96 Klicks gebracht und null zurechenbare retained User. GitHub-README-Traffic konvertiert mit 15,8%. Dieser Artikel existiert wegen dieser Analyse.

Eng1, entblockt durch archs Activity-Dashboard-Design, fängt an, Cross-Filter-State-Management und Utility-Funktionen zu bauen. 687 Tests grün.

QA1 validiert den Header-Badge-Fix: Testserver hochfahren, per Browser-Automation prüfen, dass das Badge korrekt rendert, verifizieren, dass 665 Unit-Tests durchlaufen, PASS markieren.

14:45 Uhr – Shipper mergt den Release-Candidate-PR, pusht den v0.10.0-Tag und triggert den Promote-Workflow. CI baut Artefakte für alle 5 Plattformen (macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe). Shipper verifiziert jedes Artefakt, aktualisiert die Release Notes auf beiden Repos, deployt die Website neu und aktualisiert den Homebrew-Cask.

15:12 Uhr – Owner antwortet auf GitHub Issue #2:

Gute Nachrichten: v0.10.0 ist gerade mit vollständiger Dolt-Server-Auth-Unterstützung erschienen. Update installieren, dann sollte es laufen.

Bug morgens gemeldet. Fix nachmittags ausgeliefert. Und währenddessen wurde das nächste Feature schon designt, ein anderer Bug untersucht, Analytics ausgewertet, und QA hat unabhängig einen separaten Fix verifiziert.

Das liegt nicht daran, dass 13 Agenten schnell sind. Es liegt daran, dass 13 Agenten parallel sind.

Was schiefgeht

Das ist der Teil, den die meisten „Schaut euch mein KI-Setup an"-Posts weglassen.

Rate Limits bei hoher Parallelität. Wenn 13 Agenten alle auf demselben API-Account laufen, verbrennst du Tokens schnell. An diesem Tag haben super, eng1 und eng2 gleichzeitig das Rate Limit erreicht. Alle stehen still. Du wartest. Das KI-Äquivalent dazu, dass alle im Büro gleichzeitig den Drucker benutzen wollen, nur dass der Drucker pro Seite kostet und ein Seiten-pro-Minute-Limit hat.

QA schickt Arbeit zurück. Das ist gewollt, kostet aber Zyklen. QA hat einen Build abgelehnt, weil der DONE-Kommentar des Engineers keine Verifikationsschritte enthielt. Der Fix hat funktioniert, aber QA konnte ihn nicht bestätigen, ohne den Quellcode zu lesen. Zurück zu eng, Abschlusskommentar umschreiben, zurück zu QA, nochmal verifizieren. Zwanzig Minuten für etwas, das fünf hätte dauern sollen. Das Protokoll erzeugt Reibung, aber die Reibung ist tragend. Jedes Mal, wenn ich QA abgekürzt habe, ist in Produktion etwas kaputtgegangen.

Context Windows füllen sich. Agenten akkumulieren Kontext über eine Session. Super hat ein Protokoll, das bei 65% Kontextauslastung eine „Arbeit sichern"-Anweisung schickt. Wenn du das Fenster verpasst, verliert der Agent den Faden.

Agenten hängen fest. Manchmal gerät ein Agent in eine Fehlerschleife und wiederholt denselben fehlschlagenden Befehl. Supers Kontrollrunde fängt das auf, aber nur wenn du häufig genug reinschaust. Ich habe mal 30 Minuten an einen Agenten verloren, der höflich im Stillen gescheitert ist.

Der Koordinations-Overhead ist real. CLAUDE.md-Dateien, Dispatch-Protokolle, Kontrollrunden, Bead-Kommentare, Abschlussberichte. Für ein Zwei-Agenten-Setup ist das Overkill. Für 13 Agenten ist es die minimal funktionsfähige Struktur. Es gibt einen Kipppunkt bei ungefähr 5 Agenten, ab dem informelle Koordination nicht mehr funktioniert und du explizite Protokolle brauchst, sonst verlierst du den Überblick.

Was ich gelernt habe

Spezialisierung schlägt Generalisierung. 13 fokussierte Agenten übertreffen 3 „Full-Stack"-Agenten. Wenn qa1 nur validiert und nie Code schreibt, findet es jedes Mal Dinge, die eng übersehen hat. Wenn arch nur designt und nie implementiert, sind die Designs sauberer, weil es keine Versuchung gibt, die Spec abzukürzen, um die Implementierung einfacher zu machen.

Unabhängige QA ist nicht verhandelbar. QA hat seinen eigenen Repo-Klon. Es testet den gepushten Code, nicht den Working Tree. Es vertraut dem Selbstbericht des Engineers nicht. Das klingt langsam. Es findet bei jedem Release Bugs.

Ohne Sichtbarkeit driftet die Flotte. Bei 5+ Agenten kannst du den Zustand nicht tracken, indem du zwischen tmux-Panes wechselst und bd list im Kopf machst. Du brauchst ein Dashboard, das dir den Dependency Tree zeigt, welche Agenten woran arbeiten und welche Beads blockiert sind. Das ist das Problem, für das ich Beadbox gebaut habe.

Die rekursive Schleife zählt. Die Agenten bauen Beadbox. Beadbox überwacht die Agenten. Wenn die Agenten einen Bug in Beadbox produzieren, fängt die Flotte ihn durch denselben QA-Prozess, der jeden anderen Bug gefangen hat. Das Tool verbessert sich, weil das Team, das es am meisten nutzt, auch das Team ist, das es baut. Mir ist bewusst, dass das entweder brillant ist oder die aufwändigste Rube-Goldberg-Maschine aller Zeiten. Die ausgelieferten Features sprechen für Ersteres. Meine Token-Rechnung für Letzteres.

Der Stack

Wenn du das selbst ausprobieren willst, brauchst du Folgendes:

beads: Open-Source, Git-nativer Issue-Tracker. Das Rückgrat der Koordination. Jeder Agent liest und schreibt darauf.
Claude Code: Die Agenten-Runtime. Jeder Agent ist eine Claude Code Session in einem tmux-Pane mit eigener CLAUDE.md-Identitätsdatei.
tmux + gn/gp/ga: Terminal-Multiplexer, um Agenten nebeneinander laufen zu lassen. Die Messaging-Tools ermöglichen Kommunikation ohne Shared Memory.
Beadbox: Visuelles Echtzeit-Dashboard, das zeigt, was die Flotte gerade tut. Das ist es, worüber du hier liest.

Du brauchst nicht alle 13 Agenten zum Start. Zwei Engineers und ein QA-Agent, koordiniert über beads, werden deine Vorstellung davon verändern, was ein einzelner Entwickler shippen kann.

Was als Nächstes kommt

Die größte Lücke im aktuellen Setup: drei Fragen auf einen Blick beantworten. Welche Agenten sind aktiv, idle oder hängen fest? Wo staut sich Arbeit in der Pipeline? Und was ist gerade passiert, gefiltert nach dem Agenten oder der Pipeline-Stufe, die mich interessiert?

Im Moment braucht das eine Kontrollrunde und viele gp-Befehle. Deshalb bauen wir ein Koordinations-Dashboard direkt in Beadbox: einen Agenten-Statusstreifen oben, eine Pipeline-Ansicht, die zeigt, wo sich Beads aufstauen, und einen Cross-Filter-Event-Feed, bei dem ein Klick auf einen Agenten oder eine Pipeline-Stufe alles andere entsprechend filtert. Alle drei Ebenen teilen sich dieselbe Echtzeit-Datenquelle. Alle drei aktualisieren live.

Activity Dashboard Vorschau

Die 13 Agenten bauen es gerade. Ich schreibe darüber, wenn es live geht.

Ich shippe Software mit 13 KI-Agenten. So sieht das wirklich aus