Sie haben sechs Claude Code-Agenten ueber tmux-Panes gestartet. Jeder hat eine Aufgabe beansprucht. Alle produzieren Output, scrollen schneller als Sie lesen koennen. Einer hat gerade etwas committet. Ein anderer fuehrt Tests aus. Ein dritter ist seit 20 Minuten verdaechtig still.

Sie haben keine Ahnung, was tatsaechlich passiert.

Das ist das zentrale Problem bei parallelen Agent-Workflows. Die Agenten selbst sind produktiv. Claude Code kann Arbeit beanspruchen, Code schreiben, Tests ausfuehren und Fertigstellung ueber strukturierte Befehle melden. Aber der Mensch, der sechs oder zehn dieser Agenten beaufsichtigt, hat keine aggregierte Ansicht. Sie wechseln zwischen tmux-Panes, scrollen durch Terminal-Verlauf und rekonstruieren den Projektzustand in Ihrem Kopf.

Das funktioniert bei zwei Agenten. Bei fuenf bricht es zusammen.

Wie Agenten Arbeit ueber beads melden

Die Grundlage ist beads, ein Open-Source, Git-nativer Issue-Tracker, der genau fuer diesen Workflow gebaut wurde. beads gibt Agenten eine strukturierte Moeglichkeit aufzuzeichnen, was sie tun, und gibt Ihnen eine strukturierte Moeglichkeit, 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 erstellt:

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 dauert Millisekunden. Jeder schreibt in dieselbe lokale Datenbank. Die Agenten brauchen keine API-Tokens, keine HTTP-Clients und keine Authentifizierungs-Flows. Sie fuehren Shell-Befehle aus, genauso wie sie git commit oder npm test ausfuehren.

Nach ein paar Stunden paralleler Arbeit enthaelt diese Datenbank das vollstaendige Bild: Wer arbeitet woran, was ist blockiert, was wurde gerade abgeschlossen und was ist verfuegbar. Die Informationen existieren. Das Problem ist, sie zu sehen.

Was `bd list` Ihnen nicht zeigen kann

Sie koennen die Datenbank vom Terminal aus abfragen:

bd list --status=in_progress
bd blocked
bd ready

Jeder dieser Befehle liefert nuetzliche Daten. Aber sie liefern sie als flachen Text, einen Snapshot nach dem anderen. Um den Zustand Ihres Projekts zu verstehen, fuehren Sie bd list aus, dann bd show fuer einige Issues, dann bd dep list, um zu sehen, was was blockiert, dann bd blocked, um festsitzende Agenten zu finden. Sie setzen das Bild manuell zusammen.

Wenn Agenten schnell arbeiten (drei Issues in 90 Sekunden schliessen, die jeweils unterschiedliche nachgelagerte Arbeit freigeben), kann die CLI nicht mit der Aenderungsrate mithalten. Bis Sie bd blocked fertig gelesen haben, haben sich zwei dieser Blocker bereits aufgeloest.

Was Beadbox Ihnen zeigt

Beadbox ist eine native Desktop-App, die Ihr .beads/-Verzeichnis ueberwacht und den vollstaendigen Projektzustand in Echtzeit rendert. Wenn ein Agent bd update in einem Terminal ausfuehrt, erkennt Beadbox die Dateisystemaenderung und pusht sie innerhalb von Millisekunden ueber WebSocket an die UI. Kein Polling. Kein Refresh-Button. Kein Wechseln zwischen tmux-Panes, um herauszufinden, wer was getan hat.

Das bietet Ihnen konkret:

Epic-Fortschrittsbaeume. Ihr Top-Level-Feature zeigt 7 von 12 Teilaufgaben als abgeschlossen. Klappen Sie es auf und sehen Sie, welche Teilaufgaben in Arbeit sind (und welcher Agent jeweils dafuer zustaendig ist), welche blockiert sind und welche gerade verfuegbar wurden. Ein Blick ersetzt ein Dutzend bd show-Befehle.

Abhaengigkeits-Badges an jedem Issue. Sie sehen sofort, dass bb-q3l auf bb-f8o wartet, ohne einen einzigen Befehl auszufuehren. Wenn bb-f8o geschlossen wird, leuchtet bb-q3l als nicht mehr blockiert auf. Die Kaskade ist sichtbar, waehrend sie passiert.

Hervorhebung blockierter Aufgaben. Jedes blockierte Issue wird mit seinen blockierenden Abhaengigkeiten inline angezeigt. Sie suchen nicht nach Blockern. Sie sind auf dem Bildschirm, nach Prioritaet sortiert, sobald sie existieren.

Multi-Workspace-Umschaltung. Wenn Sie Agenten ueber mehrere Projekte hinweg ausfuehren, wechseln Sie ueber ein Dropdown zwischen beads-Datenbanken. Jeder Workspace merkt sich seine eigenen Filter und Ansichtseinstellungen.

Echtzeit-Synchronisation. Die Update-Pipeline besteht aus fs.watch auf dem .beads/-Verzeichnis, per WebSocket an die React-UI gepusht. Propagierung unter einer Sekunde bedeutet, dass Sie Agent-Aktivitaet sehen, waehrend sie passiert, nicht in einem 30-Sekunden-Polling-Intervall.

Der Ueberwachungs-Workflow

Sobald Beadbox neben Ihrer tmux-Session geoeffnet ist, wird Ueberwachung zur Mustererkennung statt aktiver Nachforschung. Darauf sollten Sie achten:

Veraltete In-Progress-Aufgaben. Ein Agent, der vor zwei Stunden eine Aufgabe beansprucht und seitdem nicht aktualisiert hat, haengt entweder fest oder ist abgestuerzt. In einem menschlichen Workflow bedeuten zwei Stunden nichts. Fuer einen Agenten ist so lange Stille ein Warnsignal. Pruefen Sie den tmux-Pane, stupsen Sie den Agenten an oder weisen Sie die Arbeit neu zu.

Anhaeufen blockierter Aufgaben. Wenn sich blockierte Aufgaben anhaeufen und alle auf dieselbe ungeloeste Abhaengigkeit zeigen, ist diese Abhaengigkeit Ihr kritischer Pfad. Priorisieren Sie sie hoeher, weisen Sie Ihren schnellsten Agenten zu oder loesen Sie sie selbst.

Falsche Abhaengigkeiten. Agenten deklarieren waehrend der Planung zu viele Abhaengigkeiten. Sie modellieren, was sie basierend auf ihrer anfaenglichen Codebase-Analyse zu brauchen glauben. Sobald die Arbeit beginnt, stellen sich viele dieser Abhaengigkeiten als unnoetig heraus. Wenn Sie eine blockierte Aufgabe entdecken, deren Abhaengigkeit falsch aussieht, entfernen Sie sie:

bd dep remove bb-q3l bb-f8o

Dieser eine Befehl gibt die Aufgabe sofort frei. In Beadbox sehen Sie, wie sie in Echtzeit von blockiert auf verfuegbar wechselt.

Freie Arbeit ohne Zustaendigen. Nach einer Kaskade von Freigaben koennten fuenf Aufgaben ploetzlich verfuegbar sein, ohne dass ein Agent zugewiesen ist. Das ist Ihr Moment zur Verteilung. Lenken Sie freie Agenten auf die Arbeit mit hoechster Prioritaet.

Die Triage-Schleife ist einfach: nach Blockaden suchen, loesen oder neu zuweisen, nach freier Arbeit suchen, verteilen. Beadbox macht jeden Scan zu einem Blick statt zu einer Reihe von CLI-Befehlen.

Warum das im grossen Massstab wichtig ist

Bei zwei Agenten koennen Sie durch Beobachtung der Terminals ueberwachen. Bei drei oder vier verlieren Sie den Ueberblick. Ab sechs oder zehn brauchen Sie Instrumentierung.

Die Agenten selbst sind nicht der Engpass. Claude Code ist schnell. Es schreibt Code, fuehrt Tests aus und iteriert bei Fehlern, ohne auf Sie zu warten. Der Engpass ist die Faehigkeit des Supervisors, das gesamte Brett zu sehen: welche Agenten produktiv sind, welche feststecken, wo der kritische Pfad verlaeuft und was gerade frei geworden ist.

Ein visuelles Echtzeit-Dashboard verwandelt das von einer Untersuchung (fuenf Befehle ausfuehren, die Ausgabe lesen, den Zustand im Kopf behalten) in einen Scan (auf den Bildschirm schauen). Dieser Unterschied vervielfacht sich ueber einen ganzen Arbeitstag paralleler Agent-Koordination.

Erste Schritte

Installieren Sie Beadbox mit Homebrew:

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

Wenn Ihre Agenten bereits beads verwenden, erkennt Beadbox vorhandene .beads/-Workspaces automatisch. Oeffnen Sie die App und Ihre Issues sind da. Kein Import-Schritt, keine Kontoerstellung, keine Cloud-Synchronisation. Ihre Daten bleiben auf Ihrem Rechner.

Wenn Sie neu bei beads sind, installieren Sie die CLI (go install github.com/steveyegge/beads/cmd/bd@latest), fuehren Sie bd init in Ihrem Projekt aus und beginnen Sie, Arbeit an Ihre Agenten zu verteilen. Beadbox zeigt alles, was sie tun, in dem Moment, in dem sie es tun.

Beadbox laeuft auf macOS, Linux und Windows. Es ist waehrend der Beta kostenlos.