Du hast sechs Claude Code-Agenten über tmux-Panes gestartet. Jeder hat sich eine Aufgabe geschnappt. Alle produzieren Output, scrollen schneller als du lesen kannst. Einer hat gerade etwas committet. Ein anderer führt Tests aus. Ein dritter ist seit 20 Minuten verdächtig still.

Du hast keine Ahnung, was tatsächlich passiert.

Das ist das zentrale Problem bei parallelen Agent-Workflows. Die Agenten selbst sind produktiv. Claude Code kann Arbeit beanspruchen, Code schreiben, Tests ausführen und Fertigstellung über strukturierte Befehle melden. Aber der Mensch, der sechs oder zehn davon beaufsichtigt, hat keinen aggregierten Überblick. Du wechselst zwischen tmux-Panes, scrollst durch Terminal-History und rekonstruierst den Projektzustand im Kopf.

Das funktioniert bei zwei Agenten. Bei fünf bricht es zusammen.

Wie Agenten Arbeit über beads melden

Die Grundlage ist beads, ein Open-Source, Git-nativer Issue-Tracker, der genau für diesen Workflow gebaut wurde. beads gibt Agenten eine strukturierte Möglichkeit aufzuzeichnen, was sie tun, und dir eine strukturierte Möglichkeit, es abzufragen. Jede Agent-Aktion wird zu einem CLI-Befehl, der in eine lokale Datenbank schreibt.

Wenn ein Agent Arbeit aufnimmt:

bd update bb-f8o --status in_progress --assignee agent-3

Wenn er eine Voraussetzung entdeckt und ein neues Issue anlegt:

BLOCKER=$(bd create \
  --title "Auth middleware needs rate limiting before deploy" \
  --type task --priority 1 --json | jq -r '.id')

bd dep add bb-f8o "$BLOCKER"

Wenn er fertig ist:

bd update bb-f8o --status closed
bd comments add bb-f8o --author agent-3 \
  "DONE: Implemented request throttling. Commit: a1c9e4f"

Jeder dieser Befehle braucht Millisekunden. Jeder schreibt in dieselbe lokale Datenbank. Die Agenten brauchen keine API-Tokens, keine HTTP-Clients und keine Auth-Flows. Sie führen Shell-Befehle aus, genauso wie git commit oder npm test.

Nach ein paar Stunden paralleler Arbeit enthält diese Datenbank das vollständige Bild: Wer arbeitet woran, was ist blockiert, was wurde gerade abgeschlossen und was ist verfügbar. Die Informationen existieren. Das Problem ist, sie zu sehen.

Was `bd list` dir nicht zeigen kann

Du kannst die Datenbank vom Terminal aus abfragen:

bd list --status=in_progress
bd blocked
bd ready

Jeder dieser Befehle liefert nützliche Daten. Aber sie liefern flachen Text, einen Snapshot nach dem anderen. Um den Projektzustand zu verstehen, führst du bd list aus, dann bd show für ein paar Issues, dann bd dep list, um zu sehen was was blockiert, dann bd blocked, um steckende Agenten zu finden. Du setzt das Bild manuell zusammen.

Wenn Agenten schnell arbeiten (drei Issues in 90 Sekunden schließen, die jeweils unterschiedliche Downstream-Arbeit freigeben), kommt die CLI mit der Änderungsrate nicht mit. Bis du bd blocked fertig gelesen hast, haben sich zwei dieser Blocker bereits aufgelöst.

Was Beadbox dir zeigt

Beadbox ist eine native Desktop-App, die dein .beads/-Verzeichnis überwacht und den vollständigen Projektzustand in Echtzeit rendert. Wenn ein Agent bd update in einem Terminal ausführt, fängt Beadbox die Dateisystemänderung auf und pusht sie innerhalb von Millisekunden über WebSocket an die UI. Kein Polling. Kein Refresh-Button. Kein Wechseln zwischen tmux-Panes, um herauszufinden, wer was getan hat.

Das gibt dir konkret:

Epic-Fortschrittsbäume. Dein Top-Level-Feature zeigt 7 von 12 Teilaufgaben als abgeschlossen. Klapp es auf und du siehst, welche Teilaufgaben in Arbeit sind (und welcher Agent jeweils dafür zuständig ist), welche blockiert sind und welche gerade verfügbar wurden. Ein Blick ersetzt ein Dutzend bd show-Befehle.

Abhängigkeits-Badges an jedem Issue. Du siehst sofort, dass bb-q3l auf bb-f8o wartet, ohne einen einzigen Befehl auszuführen. Wenn bb-f8o geschlossen wird, leuchtet bb-q3l als nicht mehr blockiert auf. Die Kaskade ist sichtbar, während sie passiert.

Hervorhebung blockierter Aufgaben. Jedes blockierte Issue wird mit seinen blockierenden Abhängigkeiten inline angezeigt. Du musst nicht nach Blockern suchen. Sie sind auf dem Bildschirm, nach Priorität sortiert, sobald sie existieren.

Multi-Workspace-Switching. Wenn du Agenten über mehrere Projekte laufen lässt, wechselst du per Dropdown zwischen beads-Datenbanken. Jeder Workspace merkt sich seine eigenen Filter und Ansichtseinstellungen.

Echtzeit-Sync. Die Update-Pipeline besteht aus fs.watch auf dem .beads/-Verzeichnis, per WebSocket an die React-UI gepusht. Sub-Sekunden-Propagierung bedeutet: Du siehst Agent-Aktivität, während sie passiert, nicht in einem 30-Sekunden-Polling-Intervall.

Der Überwachungs-Workflow

Sobald Beadbox neben deiner tmux-Session geöffnet ist, wird Überwachung zur Mustererkennung statt aktiver Recherche. Darauf solltest du achten:

Veraltete In-Progress-Aufgaben. Ein Agent, der vor zwei Stunden eine Aufgabe beansprucht und seitdem nichts aktualisiert hat, hängt entweder fest oder ist abgestürzt. In einem menschlichen Workflow bedeuten zwei Stunden nichts. Für einen Agenten ist so lange Stille ein Warnsignal. Schau in den tmux-Pane, stupse den Agenten an oder weise die Arbeit neu zu.

Blockierte Aufgaben häufen sich. Wenn sich blockierte Aufgaben stapeln und alle auf dieselbe ungelöste Abhängigkeit zeigen, ist diese Abhängigkeit dein kritischer Pfad. Priorisiere sie höher, weise deinen schnellsten Agenten zu oder löse sie selbst.

Falsche Abhängigkeiten. Agenten deklarieren während der Planung zu viele Abhängigkeiten. Sie modellieren, was sie basierend auf ihrer initialen Codebase-Analyse zu brauchen glauben. Sobald die Arbeit losgeht, stellen sich viele dieser Abhängigkeiten als unnötig heraus. Wenn du eine blockierte Aufgabe entdeckst, deren Abhängigkeit falsch aussieht, entferne sie:

bd dep remove bb-q3l bb-f8o

Dieser eine Befehl gibt die Aufgabe sofort frei. In Beadbox siehst du, wie sie in Echtzeit von blockiert auf verfügbar wechselt.

Bereite Arbeit ohne Zuständigen. Nach einer Kaskade von Freigaben können plötzlich fünf Aufgaben verfügbar sein, ohne dass ein Agent zugewiesen ist. Das ist dein Dispatch-Moment. Lenke freie Agenten auf die Arbeit mit höchster Priorität.

Die Triage-Schleife ist einfach: nach Blockaden suchen, lösen oder neu zuweisen, nach bereiter Arbeit suchen, dispatchen. Beadbox macht jeden Scan zu einem Blick statt einer Reihe von CLI-Befehlen.

Warum das im großen Maßstab wichtig ist

Zwei Agenten kannst du per Terminal beaufsichtigen. Bei drei oder vier verlierst du den Überblick. Ab sechs oder zehn brauchst du Instrumentierung.

Die Agenten selbst sind nicht der Engpass. Claude Code ist schnell. Es schreibt Code, führt Tests aus und iteriert bei Fehlern, ohne auf dich zu warten. Der Engpass ist deine Fähigkeit als Supervisor, das gesamte Board zu sehen: welche Agenten produktiv sind, welche feststecken, wo der kritische Pfad verläuft und was gerade frei geworden ist.

Ein visuelles Echtzeit-Dashboard verwandelt das von einer Untersuchung (fünf Befehle ausführen, die Ausgabe lesen, den Zustand im Kopf behalten) in einen Scan (auf den Bildschirm schauen). Dieser Unterschied multipliziert sich über einen ganzen Arbeitstag paralleler Agent-Koordination.

Los geht's

Installiere Beadbox mit Homebrew:

brew tap beadbox/cask && brew install --cask beadbox

Wenn deine Agenten bereits beads nutzen, erkennt Beadbox vorhandene .beads/-Workspaces automatisch. Öffne die App und deine Issues sind da. Kein Import-Schritt, keine Kontoerstellung, keine Cloud-Synchronisation. Deine Daten bleiben auf deinem Rechner.

Wenn du neu bei beads bist, installiere die CLI (go install github.com/steveyegge/beads/cmd/bd@latest), führe bd init in deinem Projekt aus und fang an, Arbeit an deine Agenten zu verteilen. Beadbox zeigt alles, was sie tun, in dem Moment, in dem sie es tun.

Beadbox läuft auf macOS, Linux und Windows. Es ist während der Beta kostenlos.