Vous avez cinq agents IA qui travaillent sur un epic de fonctionnalite. L'Agent 1 construit la couche API. L'Agent 2 a besoin de cette API pour connecter le frontend. L'Agent 3 ecrit des tests d'integration qui dependent des deux. Les Agents 4 et 5 s'occupent des migrations et de la documentation, chacun bloque par des elements differents.
Ca fonctionne pendant une vingtaine de minutes. Puis l'Agent 2 se bloque parce que l'Agent 1 a rencontre un probleme de schema inattendu. L'Agent 3 est maintenant bloque par l'Agent 2, qui est bloque par l'Agent 1. Les Agents 4 et 5 continuent de produire, mais leur travail ne peut pas etre merge tant que la chaine n'est pas resolue. Vous ne le decouvrez que quand vous vous demandez pourquoi rien n'a ete livre depuis une heure et que vous commencez a lancer bd blocked sur chaque ticket.
L'information de dependance existe. Elle est dans votre gestionnaire de tickets. Mais quand vous la gerez via un CLI, vous reconstituez le graphe dans votre tete a partir de sorties textuelles plates. Cette reconstitution echoue au moment precis ou elle compte le plus : quand le graphe est complexe et que les choses cassent.
Comment beads suit les dependances
beads est un gestionnaire de tickets versionne dans Git, concu pour la coordination d'agents IA. Il stocke tout dans une base de donnees Dolt locale a l'interieur du repertoire .beads/ de votre depot. Pas de service cloud, pas de comptes, pas de conflits de synchronisation.
Les agents declarent les dependances avec une seule commande :
bd dep add ISSUE-42 ISSUE-37
Cela enregistre que ISSUE-42 depend de ISSUE-37. ISSUE-42 ne peut pas avancer tant que ISSUE-37 n'est pas ferme. La requete inverse est tout aussi simple :
bd blocked
Cela renvoie chaque ticket du workspace actuellement bloque par une dependance non resolue. Et pour un ticket specifique :
bd dep list ISSUE-42
Cela montre de quoi depend ISSUE-42 et ce qui depend de ISSUE-42.
Le modele de donnees est propre. Le probleme n'est pas d'enregistrer les dependances. Le probleme est de les voir. Quand vous avez 30 tickets actifs repartis sur cinq agents, lancer bd blocked vous donne une liste. Une liste ne montre pas que ISSUE-12 est un goulot d'etranglement qui bloque sept taches en aval reparties sur trois agents. Une liste ne montre pas que l'Agent 3 a cree une chaine de dependance circulaire entre ISSUE-18 et ISSUE-22. Vous avez besoin d'une vue spatiale du graphe, pas sequentielle.
Ce que Beadbox vous montre
Beadbox est une application desktop native qui enveloppe le CLI beads d'une interface visuelle. Elle lit la meme base de donnees .beads/ dans laquelle vos agents ecrivent et se met a jour en temps reel pendant qu'ils travaillent.
Dans la vue arbre d'epics, chaque ticket avec des dependances non resolues affiche un badge de blocage en ligne. Vous voyez la structure complete de l'arbre de votre epic, avec les tickets bloques marques d'un coup d'oeil. Aucune commande a lancer, aucune sortie a interpreter.
La chaine de dependance est visible spatialement. Si ISSUE-42 depend de ISSUE-37, et ISSUE-37 depend de ISSUE-15, et ISSUE-15 est assigne a l'Agent 1 qui est bloque, vous pouvez tracer cette chaine en parcourant l'arbre. Vous voyez la forme du goulot d'etranglement sans le reconstituer a partir de requetes CLI separees.
La composante temps reel est essentielle. Quand l'Agent 1 ferme enfin ISSUE-15, l'interface de Beadbox le reflete en moins d'une seconde. Le badge de blocage sur ISSUE-37 disparait. Si ISSUE-37 etait la seule chose bloquant ISSUE-42, ce badge disparait aussi. Vous regardez la chaine de dependance se desagreger a mesure que le travail se termine, sans rafraichir ni relancer de requete.
Sous le capot, cela fonctionne via un pipeline simple : un serveur WebSocket surveille le repertoire .beads/ avec fs.watch(). Quand un agent ecrit dans la base de donnees (fermeture d'un ticket, ajout d'une dependance, mise a jour de statut), l'evenement du systeme de fichiers declenche une diffusion a tous les clients connectes. L'interface React se re-rend avec des donnees fraiches. Latence sub-seconde entre l'action de l'agent et la mise a jour visuelle.
Un scenario concret : reperer un goulot d'etranglement
Cinq agents travaillent sur un epic de fonctionnalite avec 24 tickets. Vous ouvrez Beadbox et regardez l'arbre de l'epic. Douze tickets sont en cours. Six affichent des badges de blocage.
C'est deja une information que vous n'aviez pas. bd list vous montrerait 12 tickets en cours, mais il faudrait lancer bd blocked separement et croiser les references pour comprendre quels tickets en cours sont reellement au point mort.
Vous examinez les badges de blocage et remarquez quelque chose : quatre des six tickets bloques dependent tous de ISSUE-19, une migration de schema de base de donnees assignee a l'Agent 4. L'Agent 4 y travaille encore, mais ISSUE-19 est devenu un goulot d'etranglement unique. Quatre agents sont effectivement inactifs, en attente d'une seule tache.
Sans la vue visuelle, vous pourriez ne pas le remarquer pendant encore une heure. Avec elle, vous pouvez intervenir immediatement. Peut-etre reassigner ISSUE-19 a un agent plus rapide. Peut-etre le decouper en morceaux plus petits qui peuvent debloquer certains dependants plus tot. Peut-etre realiser que deux de ces quatre dependances ont ete sur-declarees et peuvent etre supprimees avec bd dep remove.
Le point n'est pas que l'information etait inaccessible avant. Elle a toujours ete dans la base de donnees. Le point est que la representation visuelle revele des motifs que le texte brut masque.
Anti-patterns courants de dependance
Faire tourner plusieurs agents IA sur un meme depot produit quelques problemes recurrents de dependance. Tous sont plus faciles a reperer visuellement que par des requetes CLI.
Sur-declaration. Les agents tendent a etre conservateurs. Dans le doute, ils declarent une dependance. Le resultat est un graphe de dependances plus dense que necessaire, avec des tickets bloques par du travail dont ils n'ont pas reellement besoin. Dans Beadbox, vous le repérez quand un ticket affiche un badge de blocage mais que le ticket bloquant se trouve dans une partie completement non liee du codebase. Un rapide bd dep remove regle le probleme.
Chaines circulaires. L'Agent A declare une dependance sur le travail de l'Agent B. L'Agent B, travaillant independamment, declare une dependance sur le travail de l'Agent A. Maintenant les deux sont bloques mutuellement et aucun ne peut avancer. Le CLI beads detecte les dependances circulaires evidentes au moment de la creation, mais les cycles indirects a travers trois tickets ou plus sont plus difficiles a detecter. Dans l'arbre d'epics, vous les remarquez comme des groupes de badges de blocage qui ne se resolvent jamais, meme pendant que d'autres taches avancent autour.
Goulots d'etranglement uniques. Un ticket accumule cinq, six, sept dependants en aval. Cela arrive naturellement quand des agents travaillant en parallele ont tous besoin du meme element fondamental. Le scenario ci-dessus illustre ce motif. Dans une vue liste, vous voyez sept tickets bloques. Dans une vue arbre, vous voyez sept fleches pointant vers le meme noeud. Le goulot est evident.
Pour commencer
Beadbox fonctionne sur macOS, Linux et Windows. Installez-le avec Homebrew :
brew tap beadbox/cask && brew install --cask beadbox
Pointez-le vers n'importe quel depot avec un repertoire .beads/. Si vous faites deja tourner beads avec votre flotte d'agents, Beadbox prend la base de donnees existante et commence l'affichage immediatement. Pas d'import, pas de configuration, pas de creation de compte.
Vos agents continuent d'utiliser le CLI. Ils lancent bd dep add, bd update, bd close comme d'habitude. Beadbox surveille la base de donnees et reflete chaque changement en temps reel. Vous obtenez la couche visuelle sans modifier aucun workflow d'agent.
Beadbox est gratuit pendant la beta.
Si vous coordonnez plusieurs agents IA sur un meme codebase, le graphe de dependances est la premiere chose qui va casser votre workflow. Vous pouvez le gerer a l'aveugle via le CLI, ou vous pouvez le voir. Le voir est plus rapide.