Vous avez lancé six agents Claude Code dans des panneaux tmux. Chacun a revendiqué une tâche. Ils produisent tous du texte, défilant plus vite que vous ne pouvez lire. L'un vient de faire un commit. Un autre lance des tests. Un troisième est suspicieusement silencieux depuis 20 minutes.

Vous n'avez aucune idée de ce qui se passe vraiment.

C'est le problème central des workflows d'agents en parallèle. Les agents eux-mêmes sont productifs. Claude Code peut revendiquer du travail, écrire du code, lancer des tests et rapporter la complétion par des commandes structurées. Mais l'humain qui supervise six ou dix de ces agents n'a pas de vue agrégée. Vous passez votre temps à alterner entre les panneaux tmux, à parcourir l'historique du terminal et à reconstituer l'état du projet dans votre tête.

Ça fonctionne pour deux agents. Ça s'effondre à cinq.

Comment les agents rapportent leur travail via beads

La base est beads, un gestionnaire de tickets open-source et natif Git conçu exactement pour ce workflow. beads donne aux agents un moyen structuré d'enregistrer ce qu'ils font, et vous donne un moyen structuré de le consulter. Chaque action d'agent devient une commande CLI qui écrit dans une base de données locale.

Quand un agent prend du travail :

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

Quand il découvre un prérequis et crée un nouveau ticket :

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"

Quand il termine :

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

Chacune de ces commandes prend des millisecondes. Chacune écrit dans la même base de données locale. Les agents n'ont pas besoin de tokens API, de clients HTTP ni de flux d'authentification. Ils lancent des commandes shell, de la même façon qu'ils lancent git commit ou npm test.

Après quelques heures de travail parallèle, la base de données contient le tableau complet : qui travaille sur quoi, qu'est-ce qui est bloqué, qu'est-ce qui vient de se terminer et qu'est-ce qui est disponible. L'information existe. Le problème est de la visualiser.

Ce que `bd list` ne peut pas vous montrer

Vous pouvez interroger la base de données depuis le terminal :

bd list --status=in_progress
bd blocked
bd ready

Chacune de ces commandes retourne des données utiles. Mais elles les retournent sous forme de texte brut, un instantané à la fois. Pour comprendre l'état de votre projet, vous lancez bd list, puis bd show sur quelques tickets, puis bd dep list pour voir ce qui bloque quoi, puis bd blocked pour trouver les agents en panne. Vous assemblez le puzzle manuellement.

Quand les agents avancent vite (fermant trois tickets en 90 secondes, chacun débloquant du travail différent en aval), la CLI ne peut pas suivre le rythme des changements. Le temps de finir de lire bd blocked, deux de ces blocages sont déjà résolus.

Ce que Beadbox vous montre

Beadbox est une application desktop native qui surveille votre répertoire .beads/ et affiche l'état complet du projet en temps réel. Quand un agent lance bd update dans un terminal, Beadbox capte le changement sur le système de fichiers et le pousse vers l'interface via WebSocket en quelques millisecondes. Pas de polling. Pas de bouton de rafraîchissement. Plus besoin d'alterner entre les panneaux tmux pour savoir qui a fait quoi.

Voici ce que ça vous apporte concrètement :

Arbres de progression d'épiques. Votre feature de haut niveau montre 7 sous-tâches sur 12 terminées. Dépliez-la pour voir lesquelles sont en cours (et quel agent possède chacune), lesquelles sont bloquées et lesquelles viennent de devenir disponibles. Un seul coup d'oeil remplace une douzaine de commandes bd show.

Badges de dépendance sur chaque ticket. Vous voyez instantanément que bb-q3l attend bb-f8o sans lancer aucune commande. Quand bb-f8o se ferme, bb-q3l s'affiche comme débloqué. La cascade est visible pendant qu'elle se produit.

Mise en évidence des tâches bloquées. Chaque ticket bloqué apparaît avec ses dépendances bloquantes listées inline. Vous ne chassez pas les blocages. Ils sont à l'écran, triés par priorité, dès qu'ils existent.

Changement de workspace multi-projets. Si vous faites tourner des agents sur plusieurs projets, basculez entre les bases de données beads depuis un menu déroulant. Chaque workspace conserve ses propres filtres et son état d'affichage.

Synchronisation en temps réel. Le pipeline de mise à jour est fs.watch sur le répertoire .beads/, poussé via WebSocket vers l'interface React. La propagation en moins d'une seconde signifie que vous voyez l'activité des agents pendant qu'elle se produit, pas sur un intervalle de polling de 30 secondes.

Le workflow de surveillance

Une fois Beadbox ouvert à côté de votre session tmux, la surveillance devient de la reconnaissance de formes plutôt qu'une investigation active. Voici ce qu'il faut guetter :

Tâches in-progress qui stagnent. Un agent qui a revendiqué une tâche il y a deux heures et ne l'a pas mise à jour est soit bloqué soit crashé. Dans un workflow humain, deux heures ne signifient rien. Pour un agent, un silence aussi long est un signal d'alerte. Vérifiez le panneau tmux, relancez l'agent ou réassignez le travail.

Accumulation de tâches bloquées. Si les tâches bloquées commencent à s'accumuler et pointent toutes vers la même dépendance non résolue, cette dépendance est votre chemin critique. Repriorisez-la, assignez votre agent le plus rapide ou résolvez-la vous-même.

Fausses dépendances. Les agents déclarent trop de dépendances pendant la planification. Ils modélisent ce qu'ils pensent avoir besoin d'après leur lecture initiale du codebase. Une fois le travail commencé, beaucoup de ces dépendances s'avèrent inutiles. Quand vous repérez une tâche bloquée dont la dépendance semble erronée, supprimez-la :

bd dep remove bb-q3l bb-f8o

Cette seule commande débloque la tâche instantanément. Dans Beadbox, vous voyez la transition de bloqué à disponible en temps réel.

Travail prêt sans assigné. Après une cascade de déblocages, vous pouvez avoir cinq tâches soudainement disponibles sans agent assigné. C'est votre moment de dispatch. Dirigez les agents inactifs vers le travail prêt de plus haute priorité.

La boucle de triage est simple : cherchez les blocages, résolvez ou réassignez, cherchez le travail prêt, dispatchlez. Beadbox transforme chaque recherche en un coup d'oeil au lieu d'une séquence de commandes CLI.

Pourquoi c'est important à l'échelle

Deux agents, vous supervisez en regardant les terminaux. Trois ou quatre, vous commencez à perdre le fil. À six ou dix, vous avez besoin d'instrumentation.

Les agents ne sont pas le goulot d'étranglement. Claude Code est rapide. Il écrit du code, lance des tests et itère sur les échecs sans vous attendre. Le goulot d'étranglement est la capacité du superviseur à voir le plateau complet : quels agents sont productifs, lesquels sont bloqués, où passe le chemin critique et ce qui vient de s'ouvrir.

Un tableau de bord visuel en temps réel transforme ça d'une investigation (lancez cinq commandes, lisez la sortie, gardez l'état en tête) en un balayage (regardez l'écran). Cette différence se cumule sur une journée entière de coordination d'agents en parallèle.

Pour commencer

Installez Beadbox avec Homebrew :

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

Si vos agents utilisent déjà beads, Beadbox détecte automatiquement les workspaces .beads/ existants. Ouvrez l'application et vos tickets sont là. Pas d'étape d'importation, pas de création de compte, pas de synchronisation cloud. Vos données restent sur votre machine.

Si vous débutez avec beads, installez le CLI (go install github.com/steveyegge/beads/cmd/bd@latest), lancez bd init dans votre projet et commencez à dispatcher du travail à vos agents. Beadbox montre tout ce qu'ils font au moment où ils le font.

Beadbox tourne sur macOS, Linux et Windows. Gratuit pendant la bêta.