Iniciaste seis agentes Claude Code en paneles de tmux. Cada uno reclamó una tarea. Todos están produciendo output, desplazándose más rápido de lo que puedes leer. Uno acaba de hacer commit de algo. Otro está ejecutando tests. Un tercero lleva sospechosamente callado 20 minutos.

No tienes idea de qué está pasando realmente.

Este es el problema central de los workflows de agentes en paralelo. Los agentes en sí son productivos. Claude Code puede reclamar trabajo, escribir código, ejecutar tests y reportar finalización a través de comandos estructurados. Pero el humano que supervisa seis o diez de estos agentes no tiene una vista agregada. Terminas alternando entre paneles de tmux, revisando el historial del terminal y reconstruyendo el estado del proyecto en tu cabeza.

Eso funciona con dos agentes. Se desmorona con cinco.

Cómo los agentes reportan trabajo a través de beads

La base es beads, un issue tracker open-source y nativo de Git construido exactamente para este workflow. beads da a los agentes una forma estructurada de registrar lo que están haciendo, y te da a ti una forma estructurada de consultarlo. Cada acción del agente se convierte en un comando CLI que escribe en una base de datos local.

Cuando un agente toma trabajo:

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

Cuando descubre un prerrequisito y crea un nuevo issue:

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"

Cuando termina:

bd update bb-f8o --status closed
bd comments add bb-f8o --author agent-3 \
  "DONE: Implemented request throttling. Commit: a1c9e4f"

Cada uno de esos comandos toma milisegundos. Cada uno escribe en la misma base de datos local. Los agentes no necesitan tokens de API, clientes HTTP ni flujos de autenticación. Ejecutan comandos shell, igual que ejecutan git commit o npm test.

Después de unas horas de trabajo paralelo, la base de datos contiene el cuadro completo: quién está trabajando en qué, qué está bloqueado, qué acaba de terminar y qué está disponible. La información existe. El problema es visualizarla.

Lo que `bd list` no puede mostrarte

Puedes consultar la base de datos desde la terminal:

bd list --status=in_progress
bd blocked
bd ready

Cada uno de esos comandos retorna datos útiles. Pero los retorna como texto plano, una instantánea a la vez. Para entender el estado de tu proyecto, ejecutas bd list, luego bd show en algunos issues, luego bd dep list para ver qué está bloqueando qué, luego bd blocked para encontrar agentes estancados. Armas el rompecabezas manualmente.

Cuando los agentes se mueven rápido (cerrando tres issues en 90 segundos, cada uno desbloqueando trabajo diferente aguas abajo), la CLI no puede seguir la velocidad de los cambios. Cuando terminas de leer bd blocked, dos de esos bloqueos ya se resolvieron.

Lo que Beadbox te muestra

Beadbox es un app de escritorio nativo que observa tu directorio .beads/ y renderiza el estado completo del proyecto en tiempo real. Cuando un agente ejecuta bd update en una terminal, Beadbox capta el cambio en el sistema de archivos y lo envía a la UI vía WebSocket en milisegundos. Sin polling. Sin botón de refresh. Sin alternar entre paneles de tmux para descubrir quién hizo qué.

Esto es lo que te da concretamente:

Árboles de progreso de épicas. Tu feature de nivel superior muestra 7 de 12 subtareas completas. Expándela y ve cuáles están en progreso (y qué agente es dueño de cada una), cuáles están bloqueadas y cuáles acaban de quedar disponibles. Un vistazo reemplaza una docena de comandos bd show.

Badges de dependencia en cada issue. Ves instantáneamente que bb-q3l está esperando a bb-f8o sin ejecutar un solo comando. Cuando bb-f8o se cierra, bb-q3l aparece como desbloqueado. La cascada es visible mientras sucede.

Resaltado de tareas bloqueadas. Cada issue bloqueado aparece con sus dependencias listadas inline. No cazas bloqueadores. Están en pantalla, ordenados por prioridad, en el momento en que existen.

Cambio de workspace para múltiples proyectos. Si ejecutas agentes en múltiples proyectos, cambia entre bases de datos beads desde un dropdown. Cada workspace recuerda sus propios filtros y estado de vista.

Sincronización en tiempo real. El pipeline de actualización es fs.watch en el directorio .beads/, enviado vía WebSocket a la UI React. Propagación sub-segundo significa que ves la actividad de los agentes mientras sucede, no en intervalos de polling de 30 segundos.

El workflow de monitoreo

Cuando Beadbox está abierto junto a tu sesión de tmux, el monitoreo se convierte en reconocimiento de patrones en lugar de investigación activa. Esto es lo que debes observar:

Tareas in-progress estancadas. Un agente que reclamó una tarea hace dos horas y no la ha actualizado está atascado o se cayó. En un workflow humano, dos horas no significan nada. Para un agente, silencio durante tanto tiempo es una señal de alerta. Revisa el panel de tmux, dale un empujón al agente o reasigna el trabajo.

Acumulación de tareas bloqueadas. Si las tareas bloqueadas comienzan a acumularse y todas apuntan a la misma dependencia no resuelta, esa dependencia es tu camino crítico. Repriorízala, asígnala a tu agente más rápido o resuélvela tú mismo.

Dependencias falsas. Los agentes declaran dependencias en exceso durante la planificación. Modelan lo que creen que van a necesitar basándose en su lectura inicial del codebase. Cuando el trabajo comienza, muchas de esas dependencias resultan innecesarias. Cuando identificas una tarea bloqueada cuya dependencia parece incorrecta, elimínala:

bd dep remove bb-q3l bb-f8o

Ese único comando desbloquea la tarea instantáneamente. En Beadbox, ves la transición de bloqueado a disponible en tiempo real.

Trabajo listo sin asignar. Después de una cascada de desbloqueos, puedes tener cinco tareas súbitamente disponibles sin agente asignado. Ese es tu momento de despacho. Dirige agentes ociosos al trabajo listo de mayor prioridad.

El loop de triage es simple: busca bloqueos, resuelve o reasigna, busca trabajo listo, despacha. Beadbox convierte cada búsqueda en un vistazo en lugar de una secuencia de comandos CLI.

Por qué esto importa a escala

Dos agentes, los supervisas mirando terminales. Tres o cuatro, empiezas a perder el hilo. Con seis o diez, necesitas instrumentación.

Los agentes no son el cuello de botella. Claude Code es rápido. Escribe código, ejecuta tests e itera sobre fallas sin esperar por ti. El cuello de botella es la capacidad del supervisor de ver el tablero completo: qué agentes son productivos, cuáles están atascados, por dónde pasa el camino crítico y qué acaba de abrirse.

Un dashboard visual en tiempo real convierte eso de una investigación (ejecuta cinco comandos, lee el output, mantén el estado en tu cabeza) en un escaneo (mira la pantalla). Esa diferencia se acumula a lo largo de un día entero de coordinación de agentes en paralelo.

Para empezar

Instala Beadbox con Homebrew:

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

Si tus agentes ya usan beads, Beadbox detecta workspaces .beads/ existentes automáticamente. Abre el app y tus issues están ahí. Sin paso de importación, sin creación de cuenta, sin sincronización en la nube. Tus datos permanecen en tu máquina.

Si eres nuevo en beads, instala el CLI (go install github.com/steveyegge/beads/cmd/bd@latest), ejecuta bd init en tu proyecto y comienza a despachar trabajo a tus agentes. Beadbox muestra todo lo que hacen en el momento en que lo hacen.

Beadbox corre en macOS, Linux y Windows. Gratuito durante el beta.