Tienes cinco agentes de IA trabajando en un epic de funcionalidad. Agent 1 esta construyendo la capa de API. Agent 2 necesita esa API para conectar el frontend. Agent 3 esta escribiendo tests de integracion que dependen de ambos. Agents 4 y 5 estan manejando migraciones y documentacion, cada uno bloqueado por piezas diferentes.
Esto funciona por unos veinte minutos. Luego Agent 2 se detiene porque Agent 1 encontro un problema inesperado con el esquema. Agent 3 ahora esta bloqueado por Agent 2, que esta bloqueado por Agent 1. Agents 4 y 5 siguen avanzando, pero su trabajo no puede hacer merge hasta que la cadena se resuelva. No te enteras hasta que te preguntas por que nada ha salido en una hora y empiezas a ejecutar bd blocked en cada issue.
La informacion de dependencias existe. Vive en tu issue tracker. Pero cuando la gestionas a traves de un CLI, estas reconstruyendo el grafo en tu cabeza a partir de texto plano. Esa reconstruccion falla exactamente en el momento que mas importa: cuando el grafo es complejo y las cosas se estan rompiendo.
Como beads rastrea dependencias
beads es un issue tracker respaldado por git construido para la coordinacion de agentes de IA. Almacena todo en una base de datos Dolt local dentro del directorio .beads/ de tu repositorio. Sin servicio en la nube, sin cuentas, sin conflictos de sincronizacion.
Los agentes declaran dependencias con un solo comando:
bd dep add ISSUE-42 ISSUE-37
Esto registra que ISSUE-42 depende de ISSUE-37. ISSUE-42 no puede avanzar hasta que ISSUE-37 se cierre. La consulta inversa es igual de simple:
bd blocked
Eso retorna cada issue en el workspace actualmente bloqueado por una dependencia sin resolver. Y para un issue especifico:
bd dep list ISSUE-42
Esto muestra de que depende ISSUE-42 y que depende de ISSUE-42.
El modelo de datos es limpio. El problema no es registrar dependencias. El problema es verlas. Cuando tienes 30 issues activos a traves de cinco agentes, ejecutar bd blocked te da una lista. Una lista no te muestra que ISSUE-12 es un cuello de botella bloqueando siete tareas downstream a traves de tres agentes. Una lista no te muestra que Agent 3 creo una cadena de dependencia circular entre ISSUE-18 e ISSUE-22. Necesitas una vista espacial del grafo, no una secuencial.
Lo que Beadbox te muestra
Beadbox es una app de escritorio nativa que envuelve el CLI de beads con una interfaz visual. Lee de la misma base de datos .beads/ a la que tus agentes escriben, y se actualiza en tiempo real mientras trabajan.
En la vista de arbol de epic, cada issue que tiene dependencias sin resolver muestra un badge de bloqueado en linea. Ves la estructura completa del arbol de tu epic, con issues bloqueados marcados de un vistazo. Sin comando que ejecutar, sin salida que parsear.
La cadena de dependencia es visible espacialmente. Si ISSUE-42 depende de ISSUE-37, e ISSUE-37 depende de ISSUE-15, e ISSUE-15 esta asignado a Agent 1 que esta atascado, puedes trazar esa cadena escaneando el arbol. Ves la forma del cuello de botella sin reconstruirlo a partir de consultas CLI separadas.
La parte de tiempo real importa. Cuando Agent 1 finalmente cierra ISSUE-15, la UI de Beadbox lo refleja en un segundo. El badge de bloqueado en ISSUE-37 desaparece. Si ISSUE-37 era lo unico bloqueando a ISSUE-42, ese badge tambien desaparece. Ves la cadena de dependencia colapsar mientras el trabajo se completa, sin refrescar ni re-consultar.
Por debajo, esto funciona a traves de un pipeline directo: un servidor WebSocket observa el directorio .beads/ con fs.watch(). Cuando cualquier agente escribe en la base de datos (cerrando un issue, agregando una dependencia, actualizando estado), el evento del filesystem dispara un broadcast a todos los clientes conectados. La UI de React re-renderiza con datos frescos. Latencia sub-segundo desde la accion del agente hasta la actualizacion visual.
Un escenario concreto: detectando un cuello de botella
Cinco agentes estan trabajando en un epic de funcionalidad con 24 issues. Abres Beadbox y miras el arbol del epic. Doce issues estan en progreso. Seis muestran badges de bloqueado.
Eso ya es informacion que no tenias. bd list te mostraria 12 issues en progreso, pero necesitarias ejecutar bd blocked por separado y cruzar referencias para entender cuales issues en progreso estan realmente detenidos.
Escaneas los badges de bloqueado y notas algo: cuatro de los seis issues bloqueados todos dependen de ISSUE-19, una migracion de esquema de base de datos asignada a Agent 4. Agent 4 todavia esta trabajando en ello, pero ISSUE-19 se ha convertido en un punto unico de fallo. Cuatro agentes estan efectivamente inactivos, esperando por una sola tarea.
Sin la vista visual, podrias no detectar esto por otra hora. Con ella, puedes intervenir inmediatamente. Tal vez reasignas ISSUE-19 a un agente mas rapido. Tal vez lo divides en piezas mas pequenas que pueden desbloquear algunos dependientes tempranamente. Tal vez te das cuenta de que dos de esas cuatro dependencias fueron sobre-declaradas y pueden eliminarse con bd dep remove.
El punto no es que la informacion no estuviera disponible antes. Siempre estuvo en la base de datos. El punto es que la representacion visual hace que emerjan patrones que el texto plano oscurece.
Anti-patrones de dependencia comunes
Ejecutar multiples agentes de IA en un repositorio produce algunos problemas de dependencia recurrentes. Todos son mas faciles de detectar visualmente que a traves de consultas CLI.
Sobre-declaracion. Los agentes tienden a ser conservadores. Ante la duda, declaran una dependencia. El resultado es un grafo de dependencias mas denso de lo necesario, con issues bloqueados por trabajo que en realidad no necesitan. En Beadbox, detectas esto cuando un issue muestra un badge de bloqueado pero el issue bloqueante esta en una parte completamente no relacionada del codebase. Un rapido bd dep remove lo limpia.
Cadenas circulares. Agent A declara una dependencia del trabajo de Agent B. Agent B, trabajando independientemente, declara una dependencia del trabajo de Agent A. Ahora ambos estan bloqueados el uno por el otro y ninguno puede avanzar. El CLI de beads atrapa dependencias circulares obvias al momento de la creacion, pero los ciclos indirectos a traves de tres o mas issues son mas dificiles de detectar. En el arbol del epic, los notas como clusters de badges de bloqueado que nunca se resuelven, incluso mientras otro trabajo se completa alrededor de ellos.
Cuellos de botella de punto unico. Un issue acumula cinco, seis, siete dependientes downstream. Esto sucede naturalmente cuando agentes trabajando en paralelo todos necesitan la misma pieza fundamental. El escenario anterior ilustra el patron. En una vista de lista, ves siete issues bloqueados. En una vista de arbol, ves siete flechas apuntando al mismo nodo. El cuello de botella es obvio.
Para empezar
Beadbox funciona en macOS, Linux y Windows. Instalalo con Homebrew:
brew tap beadbox/cask && brew install --cask beadbox
Apuntalo a cualquier repositorio con un directorio .beads/. Si ya estas ejecutando beads con tu flota de agentes, Beadbox toma la base de datos existente y empieza a renderizar inmediatamente. Sin paso de importacion, sin configuracion, sin creacion de cuenta.
Tus agentes siguen usando el CLI. Ejecutan bd dep add, bd update, bd close como siempre. Beadbox observa la base de datos y refleja cada cambio en tiempo real. Obtienes la capa visual sin cambiar ningun flujo de trabajo de los agentes.
Beadbox es gratis durante la beta.
Si estas coordinando multiples agentes de IA en un solo codebase, el grafo de dependencias es lo primero que va a romper tu flujo de trabajo. Puedes gestionarlo a ciegas a traves del CLI, o puedes verlo. Verlo es mas rapido.