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

Das ist gerade mein Terminal.

13 Claude Code Agenten, jeder in seinem eigenen tmux-Panel, arbeiten an derselben Codebasis. Nicht als Experiment. Nicht zum Angeben. So liefere ich jeden einzelnen Tag Software.

Das Projekt ist Beadbox, ein Echtzeit-Dashboard zur Ueberwachung von KI-Coding-Agenten. Es wird von genau der Agenten-Flotte gebaut, die es ueberwacht. Die Agenten schreiben den Code, testen ihn, pruefen ihn, paketieren ihn und liefern ihn aus. Ich koordiniere.

Wenn Sie mehr als zwei oder drei Agenten laufen haben und sich fragen, wie Sie den Ueberblick behalten, hier ist das Ergebnis meiner monatelangen Iteration.

Die Mannschaft

Jeder Agent hat eine CLAUDE.md-Datei, die seine Identitaet definiert, wofuer er zustaendig ist, wofuer nicht, und wie er mit anderen Agenten kommuniziert. Das sind keine generischen "mach alles"-Assistenten. Jeder hat eine enge Aufgabe und explizite Grenzen.

Das Schluessewort ist Grenzen. eng2 kann keine Issues schliessen. 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 refaktorieren, der kein Refactoring brauchte, Issues schliessen, die nicht verifiziert waren, oder Architekturentscheidungen treffen, fuer die sie nicht qualifiziert sind.

Jede CLAUDE.md beginnt mit einem Identitaetsabschnitt und einem Grenzabschnitt. Hier eine gekuerzte Version von dem, was eng2 sieht:

## 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.

Dieses Muster skaliert. Als ich mit 3 Agenten anfing, reichte ein einzelner lockerer Prompt. Bei 13 sind explizite Rollen und Protokolle der Unterschied zwischen Koordination und Chaos.

Die Koordinationsschicht

Drei Werkzeuge halten die Flotte zusammen.

beads ist ein Open-Source, Git-nativer Issue-Tracker, der genau fuer diesen Workflow gebaut wurde. Jede Aufgabe ist ein "Bead" mit Status, Prioritaet, Abhaengigkeiten und einem Kommentar-Thread. Agenten lesen und schreiben in dieselbe lokale Datenbank ueber eine CLI namens bd.

bd update bb-viet --claim --actor eng2   # eng2 uebernimmt einen Bug
bd show bb-viet                           # vollstaendige Spec + Kommentare anzeigen
bd comments add bb-viet --author eng2 "PLAN: ..."  # eng2 postet seinen Plan

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

gn -c -w eng2 "[from super] You have work: bb-viet. P2."  # Zuweisung
gp eng2 -n 40                                               # Fortschritt pruefen
ga -w super "[from eng2] bb-viet complete. Pushed abc123."  # Rueckmeldung

CLAUDE.md-Protokolle definieren Eskalationswege, Kommunikationsformat und Abschlusskriterien. Jeder Agent weiss: Bead uebernehmen, Plan kommentieren bevor man codet, Tests laufen lassen vor dem Push, DONE mit Verifikationsschritten kommentieren, fuer QA markieren, an super zurueckmelden.

Super fuehrt alle 5-10 Minuten eine Patrouillenschleife aus: die Ausgabe jedes aktiven Agenten pruefen, Bead-Status kontrollieren, verifizieren, dass die Pipeline nicht gestockt hat. Es ist wie eine Produktions-Rufbereitschaft, nur dass die Services KI-Agenten sind und die Vorfaelle "eng2 ist verdaechtig ruhig seit 20 Minuten" lauten.

Ein echter Tag

Hier ist, was an einem Mittwoch Ende Februar 2026 tatsaechlich passiert ist.

9:14 Uhr - Ein GitHub-Nutzer namens ericinfins oeffnet Issue #2: Er kann Beadbox nicht mit seinem Remote-Dolt-Server verbinden. Die App unterstuetzt nur lokale Verbindungen. Owner sieht es und leitet es an super weiter.

9:30 Uhr - Super verteilt die Arbeit. Arch entwirft einen Verbindungs-Authentifizierungsablauf (TLS-Toggle, Benutzername/Passwort-Felder, Umgebungsvariablen-Uebergabe). PM schreibt die Spec mit Akzeptanzkriterien. Eng uebernimmt und beginnt mit der Implementierung.

In der Zwischenzeit, parallel:

PM erfasst zwei Bugs, die beim Release-Testen entdeckt wurden. 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-Automatisierungstool liefert einen leeren Streifen auf ARM64-Macs, weil Apple Silicon Tauris WebView ueber Metal-Compositing rendert und der Backing Store leer ist.

Ops findet die Ursache des Screenshot-Bugs. Die Loesung ist elegant: Nach der Aufnahme pruefen, ob die Bildhoehe verdaechtig klein ist (unter 50px fuer ein Fenster, das 800px hoch sein sollte), und auf koordinatenbasierte Bildschirmaufnahme zurueckfallen.

Growth zieht PostHog-Daten und fuehrt eine IP-Korrelationsanalyse durch. Das Ergebnis: Reddit-Ads haben 96 Klicks generiert und null zurechenbare gehaltene Nutzer. Der GitHub-README-Traffic konvertiert mit 15,8%. Dieser Artikel existiert wegen dieser Analyse.

Eng1, durch archs Activity-Dashboard-Design entblockt, beginnt mit dem Aufbau von Cross-Filter-State-Management und Utility-Funktionen. 687 Tests bestanden.

QA1 validiert den Header-Badge-Fix: startet einen Testserver, nutzt Browser-Automatisierung um zu verifizieren, dass das Badge korrekt rendert, prueft dass 665 Unit-Tests bestehen, markiert PASS.

14:45 Uhr - Shipper merged den Release-Candidate-PR, pusht den v0.10.0-Tag und loest den Promote-Workflow aus. CI baut Artefakte fuer 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 vollstaendiger Dolt-Server-Auth-Unterstuetzung erschienen. Aktualisieren Sie, und Sie sollten entblockt sein.

Bug am Morgen gemeldet. Fix am Nachmittag ausgeliefert. Und waehrend das passierte, wurde das naechste Feature bereits designt, ein anderer Bug untersucht, Analytics analysiert und QA hat unabhaengig 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 treffen bei hoher Gleichzeitigkeit. Wenn 13 Agenten alle auf demselben API-Account laufen, verbrennt man Tokens schnell. An diesem bestimmten Tag haben super, eng1 und eng2 gleichzeitig die Rate-Limit-Obergrenze erreicht. Alle halten an. Man wartet. Es ist das KI-Aequivalent davon, dass alle im Buero gleichzeitig den Drucker benutzen wollen, nur dass der Drucker pro Seite kostet und es ein Seiten-pro-Minute-Limit gibt.

QA schickt Arbeit zurueck. Das ist gewollt, fuegt aber Zyklen hinzu. QA hat einen Build abgelehnt, weil der "DONE"-Kommentar des Entwicklers keine Verifikationsschritte enthielt. Der Fix funktionierte, aber QA konnte ihn nicht bestaetigen, ohne den Quellcode zu lesen. Zurueck zu eng, Abschlusskommentar umschreiben, zurueck zu QA, erneut verifizieren. Zwanzig Minuten fuer etwas, das fuenf haette dauern sollen. Das Protokoll erzeugt Reibung, aber die Reibung ist tragend. Jedes Mal, wenn ich QA abgekuerzt habe, ist etwas in Produktion kaputtgegangen.

Kontextfenster fuellen sich. Agenten akkumulieren Kontext ueber eine Sitzung. Super hat ein Protokoll, um bei 65% Kontextauslastung eine "Arbeit sichern"-Anweisung zu senden. Wenn man das Zeitfenster verpasst, verliert der Agent den Faden.

Agenten bleiben haengen. Manchmal geraet ein Agent in eine Fehlerschleife und wiederholt denselben fehlschlagenden Befehl. Supers Patrouillenschleife erkennt das, aber nur wenn man haeufig genug prueft. Ich habe 30 Minuten an einen Agenten verloren, der hoeflich im Stillen versagte.

Der Koordinationsaufwand ist real. CLAUDE.md-Dateien, Verteilungsprotokolle, Patrouillenschleifen, Bead-Kommentare, Abschlussberichte. Fuer ein Zwei-Agenten-Setup ist das uebertrieben. Fuer 13 Agenten ist es die minimal funktionsfaehige Struktur. Es gibt einen Kipppunkt um 5 Agenten, ab dem informelle Koordination nicht mehr funktioniert und man explizite Protokolle braucht, sonst verliert man den Ueberblick.

Was ich gelernt habe

Spezialisierung schlaegt Generalisierung. 13 fokussierte Agenten uebertreffen 3 "Full-Stack"-Agenten. Wenn qa1 nur validiert und nie Code schreibt, findet es jedes Mal Dinge, die eng uebersehen hat. Wenn arch nur designt und nie implementiert, sind die Designs sauberer, weil keine Versuchung besteht, die Spec abzukuerzen um die Implementierung einfacher zu machen.

Unabhaengige QA ist nicht verhandelbar. QA hat seinen eigenen Repo-Klon. Es testet den gepushten Code, nicht den Arbeitsbaum. Es vertraut nicht dem Selbstbericht des Entwicklers. Das klingt langsam. Es findet bei jeder Release Bugs.

Man braucht Sichtbarkeit, sonst driftet die Flotte. Bei 5+ Agenten kann man den Zustand nicht verfolgen, indem man zwischen tmux-Panels wechselt und bd list im Kopf macht. Man braucht ein Dashboard, das den Abhaengigkeitsbaum zeigt, welche Agenten woran arbeiten und welche Beads blockiert sind. Das ist das Problem, fuer das ich Beadbox gebaut habe.

Die rekursive Schleife zaehlt. Die Agenten bauen Beadbox. Beadbox ueberwacht die Agenten. Wenn die Agenten einen Bug in Beadbox produzieren, faengt 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, das Team ist, das es baut. Mir ist bewusst, dass das entweder brillant ist oder die aufwaendigste Rube-Goldberg-Maschine, die je gebaut wurde. Die ausgelieferten Features sprechen fuer Ersteres. Meine Token-Rechnung fuer Letzteres.

Der Stack

Wenn Sie das selbst ausprobieren wollen, brauchen Sie Folgendes:

• beads: Open-Source Git-nativer Issue-Tracker. Das ist das Rueckgrat der Koordination. Jeder Agent liest und schreibt darin.
• Claude Code: Die Agenten-Laufzeitumgebung. Jeder Agent ist eine Claude Code Sitzung in einem tmux-Panel mit seiner eigenen CLAUDE.md-Identitaetsdatei.
• tmux + gn/gp/ga: Terminal-Multiplexer, um Agenten nebeneinander laufen zu lassen. Die Messaging-Tools lassen Agenten ohne gemeinsamen Speicher kommunizieren.
• Beadbox: Visuelles Echtzeit-Dashboard, das zeigt, was die Flotte tut. Das ist es, worueber Sie gerade lesen.

Sie brauchen nicht alle 13 Agenten zum Start. Zwei Entwickler und ein QA-Agent, koordiniert ueber beads, werden Ihre Vorstellung davon aendern, was ein einzelner Entwickler ausliefern kann.

Was kommt als Naechstes

Die groesste Luecke im aktuellen Setup ist die Beantwortung von drei Fragen auf einen Blick: Welche Agenten sind aktiv, idle oder stecken 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 Patrol-Schleife und viele gp-Befehle. Deshalb bauen wir ein Koordinations-Dashboard direkt in Beadbox: einen Agenten-Statusstreifen am oberen Rand, eine Pipeline-Ansicht die zeigt wo sich beads ansammeln, und einen kreuzgefilterten 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 sich live.

Die 13 Agenten bauen es gerade. Ich schreibe darueber, wenn es ausgeliefert wird.