Vous avez cinq agents IA travaillant sur une épique de feature. L'Agent 1 construit la couche API. L'Agent 2 a besoin de cette API pour câbler le frontend. L'Agent 3 écrit des tests d'intégration qui dépendent des deux. Les Agents 4 et 5 gèrent les migrations et la documentation, chacun bloqué par des pièces différentes.

Ca fonctionne pendant une vingtaine de minutes. Puis l'Agent 2 cale parce que l'Agent 1 a rencontré un problème de schéma inattendu. L'Agent 3 est maintenant bloqué par l'Agent 2, qui est bloqué par l'Agent 1. Les Agents 4 et 5 continuent, mais leur travail ne peut pas être fusionné tant que la chaîne n'est pas résolue. Vous ne le découvrez que quand vous vous demandez pourquoi rien n'a été livré depuis une heure et que vous commencez a lancer bd blocked sur chaque ticket.

L'information de dépendance existe. Elle vit dans votre gestionnaire de tickets. Mais quand vous la gérez via un CLI, vous reconstituez le graphe dans votre tête a partir de texte brut. Cette reconstitution échoue exactement au moment ou elle compte le plus : quand le graphe est complexe et que les choses cassent.

Comment beads suit les dépendances

beads est un gestionnaire de tickets adossé a git concu pour la coordination d'agents IA. Il stocke tout dans une base de données Dolt locale dans le répertoire .beads/ de votre dépôt. Pas de service cloud, pas de comptes, pas de conflits de synchronisation.

Les agents déclarent les dépendances avec une seule commande :

bd dep add ISSUE-42 ISSUE-37

Cela enregistre qu'ISSUE-42 dépend d'ISSUE-37. ISSUE-42 ne peut pas avancer tant qu'ISSUE-37 n'est pas fermé. La requête inverse est tout aussi simple :

bd blocked

Ca retourne chaque ticket du workspace actuellement bloqué par une dépendance non résolue. Et pour un ticket spécifique :

bd dep list ISSUE-42

Ca montre de quoi ISSUE-42 dépend et ce qui dépend d'ISSUE-42.

Le modèle de données est propre. Le problème n'est pas d'enregistrer les dépendances. Le problème est de les voir. Quand vous avez 30 tickets actifs sur cinq agents, lancer bd blocked vous donne une liste. Une liste ne vous montre pas qu'ISSUE-12 est un goulot d'étranglement bloquant sept tâches en aval sur trois agents. Une liste ne vous montre pas que l'Agent 3 a créé une chaîne de dépendance circulaire entre ISSUE-18 et ISSUE-22. Vous avez besoin d'une vue spatiale du graphe, pas séquentielle.

Ce que Beadbox vous montre

Beadbox est une application desktop native qui enveloppe le CLI beads avec une interface visuelle. Il lit la même base de données .beads/ dans laquelle vos agents écrivent, et se met a jour en temps réel pendant qu'ils travaillent.

Dans la vue arbre d'épique, chaque ticket qui a des dépendances non résolues affiche un badge bloqué inline. Vous voyez la structure complète de l'arbre de votre épique, avec les tickets bloqués marqués d'un coup d'oeil. Pas de commande a lancer, pas de sortie a analyser.

La chaîne de dépendance est visible spatialement. Si ISSUE-42 dépend d'ISSUE-37, et ISSUE-37 dépend d'ISSUE-15, et ISSUE-15 est assigné a l'Agent 1 qui est bloqué, vous pouvez tracer cette chaîne en scannant l'arbre. Vous voyez la forme du goulot d'étranglement sans le reconstituer a partir de requêtes CLI séparées.

La partie temps réel compte. Quand l'Agent 1 ferme enfin ISSUE-15, l'interface Beadbox le reflète en une seconde. Le badge bloqué sur ISSUE-37 disparaît. Si ISSUE-37 était la seule chose bloquant ISSUE-42, ce badge disparaît aussi. Vous regardez la chaîne de dépendances s'effondrer au fur et a mesure que le travail se termine, sans rafraîchir ni relancer de requête.

Sous le capot, ca fonctionne via un pipeline simple : un serveur WebSocket surveille le répertoire .beads/ avec fs.watch(). Quand un agent écrit dans la base de données (fermeture d'un ticket, ajout d'une dépendance, mise a jour de statut), l'événement du système de fichiers déclenche une diffusion a tous les clients connectés. L'interface React re-rend avec des données fraîches. Latence sub-seconde de l'action de l'agent a la mise a jour visuelle.

Un scénario concret : repérer un goulot d'étranglement

Cinq agents travaillent sur une épique de feature avec 24 tickets. Vous ouvrez Beadbox et regardez l'arbre d'épique. Douze tickets sont en cours. Six affichent des badges bloqués.

C'est déja de l'information que vous n'aviez pas. bd list vous montrerait 12 tickets en cours, mais vous devriez lancer bd blocked séparément et croiser les références pour comprendre quels tickets en cours sont réellement en panne.

Vous scannez les badges bloqués et remarquez quelque chose : quatre des six tickets bloqués dépendent tous d'ISSUE-19, une migration de schéma de base de données assignée a l'Agent 4. L'Agent 4 y travaille encore, mais ISSUE-19 est devenu un goulot d'étranglement unique. Quatre agents sont effectivement inactifs, attendant une seule tâche.

Sans la vue visuelle, vous pourriez ne pas le remarquer pendant une heure. Avec, vous pouvez intervenir immédiatement. Peut-être réassignez-vous ISSUE-19 a un agent plus rapide. Peut-être le découpez-vous en morceaux plus petits qui peuvent débloquer certains dépendants plus tôt. Peut-être réalisez-vous que deux de ces quatre dépendances étaient sur-déclarées et peuvent être supprimées avec bd dep remove.

Le point n'est pas que l'information était indisponible avant. Elle a toujours été dans la base de données. Le point est que la représentation visuelle fait émerger des patterns que le texte brut masque.

Anti-patterns courants de dépendances

Faire tourner plusieurs agents IA sur un dépôt produit quelques problèmes récurrents de dépendances. Tous sont plus faciles a repérer visuellement que par des requêtes CLI.

Sur-déclaration. Les agents tendent a être conservateurs. En cas de doute, ils déclarent une dépendance. Le résultat est un graphe de dépendances plus dense que nécessaire, avec des tickets bloqués par du travail dont ils n'ont pas réellement besoin. Dans Beadbox, vous repérez ca quand un ticket affiche un badge bloqué mais que le ticket bloqueur est dans une partie complètement non liée du codebase. Un rapide bd dep remove nettoie ca.

Chaînes circulaires. L'Agent A déclare une dépendance sur le travail de l'Agent B. L'Agent B, travaillant indépendamment, déclare une dépendance sur le travail de l'Agent A. Maintenant les deux sont bloqués l'un par l'autre et aucun ne peut avancer. Le CLI beads détecte les dépendances circulaires évidentes a la création, mais les cycles indirects a travers trois tickets ou plus sont plus difficiles a détecter. Dans l'arbre d'épique, vous les remarquez comme des clusters de badges bloqués qui ne se résolvent jamais, même quand d'autre travail se termine autour.

Goulots d'étranglement uniques. Un ticket accumule cinq, six, sept dépendants en aval. Ca arrive naturellement quand des agents travaillant en parallèle ont tous besoin de la même pièce fondamentale. Le scénario ci-dessus illustre le pattern. Dans une vue liste, vous voyez sept tickets bloqués. Dans une vue arbre, vous voyez sept flèches pointant vers le même noeud. Le goulot d'étranglement est évident.

Pour commencer

Beadbox tourne sur macOS, Linux et Windows. Installez-le avec Homebrew :

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

Pointez-le vers n'importe quel dépôt avec un répertoire .beads/. Si vous faites déja tourner beads avec votre flotte d'agents, Beadbox prend la base de données existante et commence a rendre immédiatement. Pas d'étape d'importation, pas de configuration, pas de création 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 données et reflète chaque changement en temps réel. Vous obtenez la couche visuelle sans changer aucun workflow d'agent.

Beadbox est gratuit pendant la bêta.

Si vous coordonnez plusieurs agents IA sur un seul codebase, le graphe de dépendances est ce qui cassera votre workflow en premier. Vous pouvez le gérer a l'aveugle via le CLI, ou vous pouvez le voir. Le voir est plus rapide.