Triaje de tareas bloqueadas en desarrollo paralelo

Ahora puedes ejecutar 10 agentes de IA programando en paralelo. Dale a cada uno un issue, apuntalos a una base de datos beads compartida, y dejalos trabajar. Los agentes crean subtareas, reportan bugs que descubren, actualizan estados y cierran issues cuando terminan. Es genuinamente productivo.

Hasta que algo se bloquea.

Cuando un humano se bloquea, dice algo. Publica en Slack, lo marca en el standup, se acerca al escritorio de alguien. Los agentes no hacen nada de eso. Un agente choca con una dependencia que no puede resolver, y o se detiene silenciosamente o empieza a trabajar alrededor del problema de formas que crean mas problemas. Tres agentes pueden estar atascados en la misma tarea upstream sin resolver y no te enteras hasta que te preguntas por que nada ha salido en cuatro horas.

Este es el problema de triaje para el desarrollo con agentes. No "como hacemos mejores standups" sino "como vemos que esta atascado a traves de una flota de trabajadores autonomos que no se quejan." Esto es lo que hemos aprendido construyendo Beadbox, un dashboard en tiempo real para beads que te muestra exactamente que estan haciendo tus agentes, en que estan bloqueados, y que acaba de quedar disponible.

Salta a lo que te interesa:

• Como los agentes crean cadenas de bloqueo -- los patrones unicos del trabajo con agentes
• Deteccion automatica de dependencias -- atrapa bloqueos mientras se forman
• Flujo de triaje CLI-first -- scriptable, ejecutable por agentes
• Visibilidad en tiempo real -- ve los bloqueos en el momento en que ocurren
• Evaluando herramientas de triaje -- que buscar
• El loop del supervisor -- como ejecutamos 10+ agentes diariamente

Como los agentes crean cadenas de bloqueo

Los agentes generan problemas de dependencia de forma diferente a los equipos humanos. Entender los modos de fallo importa porque las respuestas de triaje son diferentes.

Los agentes no modelan dependencias por adelantado. Un arquitecto humano descompone una funcionalidad en tareas y piensa en el orden. Un agente de programacion recibe una tarea, empieza a trabajar, y descubre a mitad de la implementacion que necesita algo que aun no existe. Podria crear un nuevo issue para esa dependencia. Podria intentar construirlo en linea y crear un desastre. Podria simplemente detenerse. Ninguno de estos resultados es visible a menos que estes observando la base de datos de issues.

Los agentes trabajan mas rapido de lo que se actualizan los grafos de dependencia. Agent-3 cierra una tarea que Agent-7 estaba esperando, pero Agent-7 no lo sabe porque verifico los bloqueos hace 10 minutos. Mientras tanto, Agent-7 sigue inactivo o trabajando en algo de menor prioridad. El desbloqueo ocurrio, pero la informacion no se propago.

Las dependencias circulares emergen de la descomposicion paralela. Cuando multiples agentes descomponen trabajo simultaneamente, pueden crear ciclos que ningun agente individual ve. Agent-1 crea Tarea A que depende de Tarea B. Agent-2 crea Tarea B que depende de Tarea C. Agent-3 crea Tarea C que depende de Tarea A. Cada dependencia tenia sentido localmente. El ciclo solo es visible desde arriba.

La contencion de recursos es invisible. Dos agentes necesitan modificar el mismo archivo, o ambos necesitan el entorno de staging, o ambos necesitan que la misma libreria compartida este en un estado estable. No se crea ningun issue de dependencia porque ningun agente sabe que el otro existe. Ambos simplemente se ralentizan y ninguno reporta por que.

El hilo comun: los agentes producen situaciones de bloqueo mas rapido de lo que las reportan. El supervisor (tu) necesita herramientas que detecten bloqueos automaticamente, no herramientas que esperen a que alguien levante una bandera.

Deteccion automatica de dependencias

La solucion son datos de dependencia explicitos y consultables, creados en el momento de la tarea y verificados continuamente. Asi se ve con beads, el issue tracker Git-native con el que ejecutamos nuestra flota de agentes.

Los agentes registran dependencias cuando crean tareas:

# El agente crea una tarea y descubre que necesita una API que no existe
API_TASK=$(bd create \
  --title "Implement /api/v2/orders endpoint" \
  --type task --priority 2 --json | jq -r '.id')

# El agente crea su propia tarea y declara la dependencia
UI_TASK=$(bd create \
  --title "Build order history page" \
  --type task --priority 2 --json | jq -r '.id')

bd dep add "$UI_TASK" "$API_TASK"

Ese bd dep add es una sola llamada CLI. Cualquier agente de IA para programar (Claude Code, Cursor, Copilot Workspace) puede ejecutarlo. Sin libreria cliente de API, sin danza de autenticacion. La dependencia ahora es datos estructurados, consultable por cualquier otro agente o script.

La deteccion de ciclos corre automaticamente:

# beads verifica el grafo completo de dependencias buscando ciclos
bd dep cycles

# Salida cuando existen ciclos:
# CYCLE DETECTED: beads-a1b -> beads-c3d -> beads-e5f -> beads-a1b

En un grafo de 5,000 dependencias, esto toma ~70ms. Ejecutalo como un hook post-commit o en un cron de 5 minutos. Cuando tres agentes independientemente crean un ciclo de dependencia, lo atrapas en minutos en lugar de descubrirlo horas despues cuando los tres estan detenidos.

Muestra cada tarea bloqueada en un solo comando:

bd blocked --json | jq -r '.[] |
  "BLOCKED: \(.id) \(.title)\n  waiting on: \(.blocked_by | join(", "))\n  assignee: \(.owner // "unassigned")\n"'

Salida:

BLOCKED: beads-x7q Build order history page
  waiting on: beads-m2k Implement /api/v2/orders endpoint
  assignee: agent-3

BLOCKED: beads-r4p Deploy staging environment
  waiting on: beads-j9w Fix Docker build, beads-n1c Update TLS certificates
  assignee: agent-7

Ahora sabes que Agent-3 y Agent-7 estan atascados, en que estan atascados, y que necesita pasar para desbloquearlos. Toda esa consulta tomo 30ms en una base de datos de 10K issues.

Detecta PRs bloqueados por convenciones de nombres de branches:

#!/bin/bash
# blocked-prs.sh: encontrar PRs cuyas dependencias no han hecho merge

for pr in $(gh pr list --json number,headRefName --jq '.[].headRefName'); do
  ISSUE_ID=$(echo "$pr" | grep -oE 'beads-[a-z0-9]+')
  [ -z "$ISSUE_ID" ] && continue

  BLOCKERS=$(bd show "$ISSUE_ID" --json | jq -r '.blocked_by[]' 2>/dev/null)
  for blocker in $BLOCKERS; do
    BLOCKER_STATUS=$(bd show "$blocker" --json | jq -r '.status')
    if [ "$BLOCKER_STATUS" != "closed" ]; then
      echo "PR ($pr) bloqueado: $ISSUE_ID esperando $blocker ($BLOCKER_STATUS)"
    fi
  done
done

Veinte lineas de shell. Corre localmente, lee datos locales, te dice que PRs de tus agentes aun no pueden hacer merge y por que.

Flujo de triaje CLI-first

El triaje en un flujo de trabajo con agentes no es una reunion. Es un script que corre en un loop. El supervisor (humano o agente) mira que esta atascado y toma una decision por cada item.

Este es el script de triaje que realmente usamos:

#!/bin/bash
# triage.sh: triaje de bloqueos de flota de agentes

echo "========================================="
echo "REPORTE DE TRIAJE: $(date +%Y-%m-%d %H:%M)"
echo "========================================="

# 1. Que esta bloqueado?
echo -e "\n--- TAREAS BLOQUEADAS ---"
bd blocked --json | jq -r '.[] |
  "[\(.priority)] \(.id) \(.title)
    bloqueado por: \(.blocked_by | join(", "))
    asignado a: \(.owner // "sin asignar")\n"'

# 2. Que esta disponible para que los agentes lo tomen?
echo -e "\n--- LISTO (desbloqueado, abierto) ---"
bd ready --json | jq -r '.[] |
  "[\(.priority)] \(.id) \(.title) (\(.owner // "sin asignar"))"'

# 3. Cuales agentes se han quedado en silencio?
echo -e "\n--- IN_PROGRESS OBSOLETOS (sin actualizacion en 2h) ---"
CUTOFF=$(date -v-2H +%Y-%m-%dT%H:%M:%S 2>/dev/null || date -d '2 hours ago' --iso-8601=seconds)
bd list --status=in_progress --json | jq -r --arg cutoff "$CUTOFF" '.[] |
  select(.updated_at < $cutoff) |
  "OBSOLETO: \(.id) \(.title) (ultima actualizacion: \(.updated_at), asignado a: \(.owner // "desconocido"))"'

# 4. Salud de dependencias
echo -e "\n--- CICLOS DE DEPENDENCIA ---"
bd dep cycles 2>&1 || echo "No se detectaron ciclos."

echo -e "\n--- ESTADISTICAS DE FLOTA ---"
bd stats

Para equipos humanos, "obsoleto" significa 48 horas sin actualizacion. Para agentes, 2 horas de silencio en una tarea in-progress es una senal de alerta. O el agente esta atascado y no lo reporta, o se estrello. De cualquier forma, necesitas mirar.

El arbol de decision para cada item bloqueado:

1. Puede otro agente desbloquearlo? Reprioriza la tarea bloqueante, asigna un agente disponible.
2. Es falsa la dependencia? Los agentes a veces declaran dependencias excesivamente conservadoras durante la planificacion. Si el bloqueo no es real, eliminalo: bd dep remove beads-x7q beads-m2k (elimina la dependencia de x7q sobre m2k, desbloqueando x7q al instante).
3. Se puede dividir el trabajo? Haz que el agente bloqueado haga las partes que no necesitan la dependencia. Crea una tarea de seguimiento para el resto.
4. Es un bloqueo externo? Algo que solo un humano puede resolver (API key, decision de diseno, acceso). Etiquetalo, anota la resolucion esperada, y reasigna el agente a otro trabajo disponible.

La opcion 2 pasa constantemente con agentes. Modelan dependencias basandose en su comprension del codebase al momento de planificar. Una vez que la implementacion empieza, la forma real del trabajo revela que la mitad de esas dependencias eran innecesarias.

Visibilidad en tiempo real del trabajo de agentes

Ejecutar un script de triaje cada 30 minutos deja vacios. Cuando los agentes trabajan rapido, muchas cosas pasan entre verificaciones. La pregunta es: puedes ver los bloqueos formarse en tiempo real?

Como lo hace Beadbox:

La base de datos de beads vive en un directorio .beads/ en tu filesystem. Cada bd update, bd create, o bd close que un agente ejecuta escribe en ese directorio. Beadbox lo observa con fs.watch() y envia los cambios a la UI por WebSocket en milisegundos.

El efecto practico: Agent-5 ejecuta bd update beads-x7q --status=closed en una terminal. El dashboard de Beadbox muestra inmediatamente esa tarea como cerrada, y cualquier tarea que estaba bloqueada por ella se ilumina como recien disponible. Ves la cascada sin ejecutar ningun comando.

Esto importa porque el trabajo con agentes crea rafagas. Un agente podria cerrar tres tareas en 90 segundos, cada una desbloqueando diferentes tareas downstream. Un dashboard basado en polling con un intervalo de refresco de 30 segundos te mostraria un estado intermedio confuso. La propagacion sub-segundo te muestra el panorama completo mientras sucede.

Si no usas Beadbox, los filesystem watches igual funcionan:

# Observa la base de datos de beads para cambios, alerta sobre nuevos bloqueos
# Nota: fswatch dispara con cada escritura. En produccion harias debounce
# (ej., sleep 2 despues de cada trigger) para evitar ruido durante escrituras en rafaga.
fswatch -o .beads/ | while read; do
  BLOCKED_COUNT=$(bd blocked --json | jq length)
  if [ "$BLOCKED_COUNT" -gt 0 ]; then
    echo "$(date): $BLOCKED_COUNT tareas actualmente bloqueadas"
    # Envia a ntfy, webhook de Slack, o cualquier sistema de notificacion
  fi
done

Cierra el loop con CI:

# En tu paso post-build de CI: cierra automaticamente el issue cuando el build pasa
if [ "$BUILD_STATUS" = "success" ]; then
  ISSUE_ID=$(echo "$BRANCH_NAME" | grep -oE 'beads-[a-z0-9]+')
  if [ -n "$ISSUE_ID" ]; then
    bd update "$ISSUE_ID" --status=closed
    bd comments add "$ISSUE_ID" --author ci \
      "Build passed. Commit: $COMMIT_SHA. Closing automatically."
  fi
fi

Cuando CI cierra ese issue, todo lo que estaba bloqueado por el queda desbloqueado. Si un agente esta observando bd ready buscando trabajo nuevo, toma la tarea desbloqueada automaticamente. Sin humano en el loop para desbloqueos rutinarios.

Esta es la diferencia entre herramientas que rastrean estado y herramientas que lo propagan. La mayoria del software de gestion de proyectos hace lo primero: actualizas una tarjeta, la tarjeta cambia de color. La propagacion significa que los efectos downstream (desbloquear dependientes, mostrar trabajo disponible, actualizar el progreso general) suceden sin que nadie haga clic en nada.

Evaluando herramientas de triaje para flujos con agentes

Si estas buscando herramientas para gestionar una flota de agentes, los requisitos son diferentes de lo que un equipo humano necesita.

Imprescindible: CLI que los agentes puedan invocar. Si tu issue tracker solo tiene UI web, los agentes no pueden usarlo. Necesitan ejecutar comandos de shell. bd create, bd update, bd blocked son comandos de una linea que cualquier agente de programacion ya sabe ejecutar. Las APIs REST tambien funcionan, pero requieren tokens de autenticacion, clientes HTTP y manejo de errores. Los Unix pipes son mas simples.

Imprescindible: grafo de dependencias consultable. "Bloqueado" como etiqueta de estado es inutil para la automatizacion. Necesitas "A depende de B" como datos estructurados para que los scripts puedan recorrer el grafo, detectar ciclos y calcular que esta listo.

Imprescindible: lecturas locales sub-segundo. Cuando los agentes consultan trabajo disponible, el tiempo de respuesta importa. Un round-trip de API de 2 segundos por consulta, multiplicado por 10 agentes consultando cada minuto, crea overhead medible. beads retorna resultados de bd ready en 30ms en una base de datos de 10K issues porque todo es local.

Deseable: propagacion de cambios en tiempo real. Si los agentes crean y resuelven 50 issues por hora, necesitas ver el estado mientras cambia, no en un intervalo de refresco.

Senal de alerta: "deteccion de bloqueos con IA." Las herramientas que afirman detectar bloqueos analizando descripciones de issues producen falsos positivos y pierden bloqueos reales que nunca se escribieron. Las declaraciones explicitas con bd dep add son superiores a la inferencia.

Senal de alerta: herramientas que requieren un navegador para hacer triaje. Desbloquear una tarea a traves de una UI web toma 5-15 segundos de clics. A traves del CLI, bd dep remove toma 18ms. En 50 tareas bloqueadas, eso es 1 minuto vs 12 minutos. Cuando supervisas agentes que se mueven rapido, la velocidad de triaje es tu cuello de botella.

Como las herramientas comunes manejan el bloqueo

El loop del supervisor

Este es el flujo de trabajo que ejecutamos diariamente, gestionando 10+ agentes de IA en un solo proyecto:

1. Los agentes declaran dependencias al momento de crear tareas. Cada bd create que tiene un prerequisito recibe un bd dep add inmediatamente. Es una sola llamada CLI extra por tarea.

2. Un agente supervisor ejecuta bd blocked cada 30 minutos. Si algo esta recien bloqueado, o resuelve el bloqueo el mismo (repriorizar, reasignar) o lo marca para el humano.

3. Beadbox corre en la pantalla del humano. El dashboard muestra el grafo completo de dependencias con tareas bloqueadas resaltadas en tiempo real. La mayoria del tiempo, la automatizacion maneja los desbloqueos rutinarios. Cuando no puede (dependencia externa, decision arquitectonica, otorgamiento de acceso), el humano ve el problema inmediatamente e interviene.

4. Las tareas obsoletas se marcan agresivamente. Un agente que no ha actualizado su tarea in-progress en 2 horas esta atascado o se estrello. El supervisor verifica y o empuja al agente, reasigna el trabajo, o investiga.

5. Las dependencias falsas se podan continuamente. Los agentes sobre-declaran dependencias durante la planificacion. A medida que la implementacion revela la forma real del trabajo, el supervisor (o los propios agentes) eliminan dependencias que resultaron ser innecesarias. Un grafo limpio es un grafo util.

El principio subyacente: los agentes son rapidos pero no tienen autoconciencia. No saben lo que otros agentes estan haciendo, no se dan cuenta cuando los bloqueos se resuelven, y no se quejan cuando estan atascados. El trabajo del supervisor es ser el sistema nervioso que conecta todo eso. Datos de dependencia estructurados, consultados automaticamente y renderizados visualmente, es lo que hace eso posible.

Beadbox es gratis durante la beta. Te muestra que estan haciendo tus agentes, que esta bloqueado, y que acaba de quedar disponible, en tiempo real.

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

Si ya usas beads, Beadbox lee tu directorio .beads/ existente sin paso de importacion. Pruebalo.