Vous avez lance six agents Claude Code dans des panneaux tmux. Chacun a revendique une tache. Ils produisent tous de la sortie, defilant plus vite que vous ne pouvez lire. L'un vient de commiter quelque chose. Un autre lance des tests. Un troisieme est suspicieusement silencieux depuis 20 minutes.

Vous n'avez aucune idee de ce qui se passe reellement.

C'est le probleme central des workflows d'agents en parallele. Les agents eux-memes sont productifs. Claude Code peut revendiquer du travail, ecrire du code, lancer des tests et signaler l'achevement via des commandes structurees. Mais l'humain qui supervise six ou dix de ces agents n'a pas de vue agregee. Vous alternez entre les panneaux tmux, faites defiler l'historique du terminal et reconstituez l'etat du projet dans votre tete.

Ca fonctionne pour deux agents. Ca s'effondre a cinq.

Comment les agents signalent leur travail via beads

La fondation est beads, un gestionnaire de tickets open-source et Git-natif concu exactement pour ce workflow. beads donne aux agents un moyen structure d'enregistrer ce qu'ils font, et vous donne un moyen structure de l'interroger. Chaque action d'agent devient une commande CLI qui ecrit dans une base de donnees locale.

Quand un agent prend du travail :

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

Quand il decouvre un prerequis et cree 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 quelques millisecondes. Chacune ecrit dans la meme base de donnees locale. Les agents n'ont pas besoin de tokens API, de clients HTTP ou de flux d'authentification. Ils executent des commandes shell, de la meme maniere qu'ils executent git commit ou npm test.

Apres quelques heures de travail parallele, cette base de donnees contient le tableau complet : qui travaille sur quoi, ce qui est bloque, ce qui vient d'etre termine et ce qui est disponible. L'information existe. Le probleme, c'est de la voir.

Ce que `bd list` ne peut pas vous montrer

Vous pouvez interroger la base de donnees depuis le terminal :

bd list --status=in_progress
bd blocked
bd ready

Chacune de ces commandes renvoie des donnees utiles. Mais elles les renvoient sous forme de texte brut, un instantane a la fois. Pour comprendre l'etat 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 reconstituez le tableau manuellement.

Quand les agents avancent vite (fermant trois tickets en 90 secondes, chacun debloquant du travail en aval), la CLI ne suit pas le rythme des changements. Le temps que vous finissiez de lire bd blocked, deux de ces blocages sont deja resolus.

Ce que Beadbox vous montre

Beadbox est une application desktop native qui surveille votre repertoire .beads/ et affiche l'etat complet du projet en temps reel. Quand un agent lance bd update dans un terminal, Beadbox detecte le changement sur le systeme de fichiers et le pousse vers l'interface via WebSocket en quelques millisecondes. Pas de polling. Pas de bouton de rafraichissement. Plus besoin d'alterner entre les panneaux tmux pour savoir qui a fait quoi.

Voici ce que ca vous apporte concretement :

Arbres de progression d'epics. Votre fonctionnalite principale montre 7 sous-taches sur 12 terminees. Depliez-la et vous voyez quelles sous-taches sont en cours (et quel agent possede chacune), lesquelles sont bloquees et lesquelles viennent de devenir disponibles. Un coup d'oeil remplace une douzaine de commandes bd show.

Badges de dependance sur chaque ticket. Vous voyez instantanement que bb-q3l attend bb-f8o sans lancer aucune commande. Quand bb-f8o se ferme, bb-q3l s'affiche comme debloque. La cascade est visible en direct.

Mise en evidence des taches bloquees. Chaque ticket bloque apparait avec ses dependances bloquantes listees en ligne. Vous ne cherchez pas les blocages. Ils sont a l'ecran, tries par priorite, des qu'ils existent.

Basculement multi-workspace. Si vous faites tourner des agents sur plusieurs projets, basculez entre les bases de donnees beads depuis un menu deroulant. Chaque workspace conserve ses propres filtres et son etat d'affichage.

Synchronisation en temps reel. Le pipeline de mise a jour est fs.watch sur le repertoire .beads/, pousse via WebSocket vers l'interface React. La propagation sub-seconde signifie que vous voyez l'activite des agents en direct, pas a intervalles de polling de 30 secondes.

Le workflow de surveillance

Une fois Beadbox ouvert a cote de votre session tmux, la surveillance devient de la reconnaissance de motifs plutot qu'une investigation active. Voici quoi surveiller :

Taches in-progress stagnantes. Un agent qui a revendique une tache il y a deux heures et ne l'a pas mise a jour est soit bloque, soit plante. Dans un workflow humain, deux heures ne signifient rien. Pour un agent, un silence aussi long est un signal d'alerte. Verifiez le panneau tmux, relancez l'agent ou reassignez le travail.

Accumulation de taches bloquees. Si les taches bloquees s'accumulent et pointent toutes vers la meme dependance non resolue, cette dependance est votre chemin critique. Repriorisez-la, assignez votre agent le plus rapide ou resolvez-la vous-meme.

Fausses dependances. Les agents sur-declarent les dependances pendant la planification. Ils modelisent ce qu'ils pensent avoir besoin en se basant sur leur lecture initiale du codebase. Une fois le travail commence, beaucoup de ces dependances s'averent inutiles. Quand vous repérez une tache bloquee dont la dependance semble incorrecte, supprimez-la :

bd dep remove bb-q3l bb-f8o

Cette seule commande debloque la tache instantanement. Dans Beadbox, vous la voyez passer de bloquee a disponible en temps reel.

Travail pret sans responsable. Apres une cascade de deblocages, vous pouvez avoir cinq taches soudainement disponibles sans agent assigne. C'est le moment de dispatcher. Dirigez les agents inactifs vers le travail pret de plus haute priorite.

La boucle de triage est simple : chercher les blocages, resoudre ou reassigner, chercher le travail pret, dispatcher. Beadbox transforme chaque scan en un coup d'oeil au lieu d'une sequence de commandes CLI.

Pourquoi c'est important a grande echelle

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

Les agents eux-memes ne sont pas le goulot d'etranglement. Claude Code est rapide. Il ecrit du code, lance des tests et itere sur les echecs sans vous attendre. Le goulot d'etranglement, c'est la capacite du superviseur a voir l'ensemble du plateau : quels agents sont productifs, lesquels sont bloques, ou passe le chemin critique et ce qui vient de se liberer.

Un tableau de bord visuel en temps reel transforme cela d'une investigation (lancer cinq commandes, lire la sortie, garder l'etat en tete) en un scan (regarder l'ecran). Cette difference s'accumule sur une journee entiere de coordination d'agents en parallele.

Pour commencer

Installez Beadbox avec Homebrew :

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

Si vos agents utilisent deja beads, Beadbox detecte automatiquement les workspaces .beads/ existants. Ouvrez l'application et vos tickets sont la. Pas d'import, pas de creation de compte, pas de synchronisation cloud. Vos donnees restent sur votre machine.

Si vous decouvrez beads, installez le CLI (go install github.com/steveyegge/beads/cmd/bd@latest), lancez bd init dans votre projet et commencez a dispatcher du travail a vos agents. Beadbox affiche tout ce qu'ils font au moment ou ils le font.

Beadbox fonctionne sur macOS, Linux et Windows. Gratuit pendant la beta.