Visualizando dependencias entre agentes de IA en tiempo real

Tienes cinco agentes de IA trabajando en una épica de feature. El Agente 1 está construyendo la capa de API. El Agente 2 necesita esa API para conectar el frontend. El Agente 3 está escribiendo tests de integración que dependen de ambos. Los Agentes 4 y 5 manejan migraciones y documentación, cada uno bloqueado por piezas diferentes.

Esto funciona por unos veinte minutos. Entonces el Agente 2 se detiene porque el Agente 1 encontró un problema inesperado de esquema. El Agente 3 ahora está bloqueado por el Agente 2, que está bloqueado por el Agente 1. Los Agentes 4 y 5 siguen avanzando, pero su trabajo no se puede mergear hasta que la cadena se resuelva. No te enteras hasta que te preguntas por qué nada se ha entregado en una hora y empiezas a ejecutar bd blocked en cada issue.

La información de dependencias existe. Vive en tu issue tracker. Pero cuando la gestionas a través de un CLI, estás reconstruyendo el grafo en tu cabeza desde salida de texto plano. Esa reconstrucción falla exactamente en el momento que más importa: cuando el grafo es complejo y las cosas se están rompiendo.

Cómo beads rastrea dependencias

beads es un issue tracker respaldado por git construido para la coordinación de agentes de IA. Almacena todo en una base de datos Dolt local dentro del directorio .beads/ de tu repo. Sin servicio cloud, sin cuentas, sin conflictos de sincronización.

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 no resuelta. Y para un issue específico:

bd dep list ISSUE-42

Esto muestra de qué depende ISSUE-42 y qué 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 entre 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 aguas abajo en tres agentes. Una lista no te muestra que el Agente 3 creó 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/ en la que tus agentes escriben, y se actualiza en tiempo real mientras trabajan.

En la vista de árbol de épica, cada issue que tiene dependencias no resueltas muestra un badge de bloqueado inline. Ves la estructura completa del árbol de tu épica, con issues bloqueados marcados de un vistazo. Sin comando que ejecutar, sin output 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 está asignado al Agente 1 que está atascado, puedes trazar esa cadena escaneando el árbol. Ves la forma del cuello de botella sin reconstruirlo desde consultas CLI separadas.

La parte de tiempo real importa. Cuando el Agente 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 único bloqueando ISSUE-42, ese badge también desaparece. Observas la cadena de dependencias colapsarse mientras el trabajo se completa, sin refrescar ni re-consultar.

Bajo el capó, funciona a través 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 sistema de archivos dispara una difusión a todos los clientes conectados. La UI React re-renderiza con datos frescos. Latencia sub-segundo desde la acción del agente hasta la actualización visual.

Un escenario concreto: detectando un cuello de botella

Cinco agentes trabajan en una épica de feature con 24 issues. Abres Beadbox y miras el árbol de épica. Doce issues están en progreso. Seis muestran badges de bloqueado.

Eso ya es información que no tenías. bd list te mostraría 12 issues en progreso, pero necesitarías ejecutar bd blocked por separado y cruzar referencias para entender cuáles issues en progreso están realmente estancados.

Escaneas los badges de bloqueado y notas algo: cuatro de los seis issues bloqueados dependen de ISSUE-19, una migración de esquema de base de datos asignada al Agente 4. El Agente 4 aún está trabajando en ello, pero ISSUE-19 se ha convertido en un cuello de botella de punto único. Cuatro agentes están efectivamente ociosos, esperando una sola tarea.

Sin la vista visual, podrías no detectar esto por otra hora. Con ella, puedes intervenir inmediatamente. Quizás reasignas ISSUE-19 a un agente más rápido. Quizás lo divides en piezas más pequeñas que pueden desbloquear algunos dependientes antes. Quizás te das cuenta de que dos de esas cuatro dependencias fueron declaradas en exceso y se pueden eliminar con bd dep remove.

El punto no es que la información estuviera no disponible antes. Siempre estuvo en la base de datos. El punto es que la representación visual hace emerger patrones que el texto plano oscurece.

Anti-patrones comunes de dependencias

Ejecutar múltiples agentes de IA en un repo produce unos cuantos problemas recurrentes de dependencias. Todos son más fáciles de detectar visualmente que a través de consultas CLI.

Sobre-declaración. Los agentes tienden a ser conservadores. En caso de duda, declaran una dependencia. El resultado es un grafo de dependencias más denso de lo necesario, con issues bloqueados por trabajo que realmente no necesitan. En Beadbox, detectas esto cuando un issue muestra un badge de bloqueado pero el issue bloqueador está en una parte completamente no relacionada del codebase. Un rápido bd dep remove lo limpia.

Cadenas circulares. El Agente A declara una dependencia del trabajo del Agente B. El Agente B, trabajando independientemente, declara una dependencia del trabajo del Agente A. Ahora ambos están bloqueados el uno por el otro y ninguno puede avanzar. El CLI de beads detecta dependencias circulares obvias al momento de creación, pero ciclos indirectos a través de tres o más issues son más difíciles de detectar. En el árbol de épica, 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 único. Un issue acumula cinco, seis, siete dependientes aguas abajo. Esto sucede naturalmente cuando agentes trabajando en paralelo todos necesitan la misma pieza fundamental. El escenario anterior ilustra el patrón. En una vista de lista, ves siete issues bloqueados. En una vista de árbol, ves siete flechas apuntando al mismo nodo. El cuello de botella es obvio.

Para empezar

Beadbox corre en macOS, Linux y Windows. Instálalo con Homebrew:

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

Apúntalo a cualquier repositorio con un directorio .beads/. Si ya estás ejecutando beads con tu flota de agentes, Beadbox toma la base de datos existente y empieza a renderizar inmediatamente. Sin paso de importación, sin configuración, sin creación 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 ningún workflow de agentes.

Beadbox es gratuito durante el beta.

Si estás coordinando múltiples agentes de IA en un solo codebase, el grafo de dependencias es lo que romperá tu workflow primero. Puedes gestionarlo a ciegas a través del CLI, o puedes verlo. Verlo es más rápido.