Esta es mi terminal ahora mismo.

Sesión de tmux con 13 agentes

13 agentes Claude Code, cada uno en su propio panel de tmux, trabajando en el mismo codebase. No como experimento. No para presumir. Así es como desarrollo software todos los días.

El proyecto es Beadbox, un dashboard en tiempo real para monitorear agentes de IA de programación. Está construido por la misma flota de agentes que monitorea. Los agentes escriben el código, lo prueban, lo revisan, lo empaquetan y lo lanzan. Yo coordino.

Si estás ejecutando más de dos o tres agentes y te preguntas cómo rastrear lo que están haciendo, esto es a lo que he llegado después de meses de iteración. Un bug se reportó a las 9 AM y el fix se envió a las 3 PM, mientras cuatro otros flujos de trabajo corrían en paralelo. No siempre sale bien, pero la productividad es real.

El equipo

Cada agente tiene un archivo CLAUDE.md que define su identidad, lo que posee, lo que no, y cómo se comunica con otros agentes. No son asistentes genéricos de "haz lo que sea". Cada uno tiene un trabajo específico y límites explícitos.

Grupo	Agentes	Qué poseen
Coordinación	super, pm, owner	Despacho de trabajo, specs de producto, prioridades de negocio
Ingeniería	eng1, eng2, arch	Implementación, diseño de sistemas, suites de tests
Calidad	qa1, qa2	Validación independiente, gates de release
Operaciones	ops, shipper	Testing de plataforma, builds, ejecución de releases
Crecimiento	growth, pmm, pmm2	Analytics, posicionamiento, contenido público

La palabra clave es límites. eng2 no puede cerrar issues. qa1 no escribe código. pmm nunca toca el código fuente de la app. Super despacha trabajo pero no implementa. Los límites existen porque sin ellos, los agentes derivan. "Ayudan" refactorizando código que no necesitaba refactorización, o cerrando issues que no estaban verificados, o tomando decisiones arquitecturales para las que no están calificados.

Cada CLAUDE.md comienza con un párrafo de identidad y una sección de límites. Aquí hay una versión abreviada de lo que tiene eng2:

## Identity
Engineer for Beadbox. You implement features, fix bugs, and write tests. You own implementation quality: the code you write is correct, tested, and matches the spec.

## Boundary with QA
QA validates your work independently. You provide QA with executable verification steps. If your DONE comment doesn't let QA verify without reading source code, it's incomplete.

Este patrón escala. Cuando empecé con 3 agentes, podían compartir un solo prompt genérico. Con 13, los roles explícitos y los protocolos son la diferencia entre coordinación y caos.

La capa de coordinación

Tres herramientas sostienen la flota.

beads es un issue tracker open-source y nativo de Git construido exactamente para este workflow. Cada tarea es un "bead" con un estado, prioridad, dependencias y un hilo de comentarios. Los agentes leen y escriben en la misma base de datos local a través de un CLI llamado bd.

bd update bb-viet --claim --actor eng2   # eng2 reclama un bug
bd show bb-viet                           # ver el spec completo + comentarios
bd comments add bb-viet --author eng2 "PLAN: ..."  # eng2 postea su plan

gn / gp / ga son herramientas de mensajería para tmux. gn envía un mensaje al panel de otro agente. gp mira el output reciente de otro agente (sin interrumpirlo). ga encola un mensaje no urgente.

gn -c -w eng2 "[from super] You have work: bb-viet. P2."  # despacho
gp eng2 -n 40                                               # revisar progreso
ga -w super "[from eng2] bb-viet complete. Pushed abc123."  # reportar

Protocolos CLAUDE.md definen rutas de escalación, formato de comunicación y criterios de completitud. Cada agente sabe: reclamar el bead, comentar tu plan antes de programar, ejecutar tests antes de hacer push, comentar DONE con pasos de verificación, marcar ready for QA, reportar a super.

Así se ve en la práctica. Este es un bead real de hoy temprano: super asigna la tarea, eng2 comenta un plan numerado, eng2 comenta DONE con pasos de verificación de QA y criterios de aceptación marcados, super despacha a QA.

Un hilo de comentarios real mostrando el workflow completo PLAN/DONE

Super ejecuta un loop de patrullaje cada 5-10 minutos: mira el output de cada agente activo, verifica el estado del bead, confirma que el pipeline no se ha detenido. Es como una rotación de guardia en producción, excepto que los servicios son agentes de IA y los incidentes son "eng2 lleva sospechosamente callado 20 minutos."

Un día real

Esto es lo que pasó un miércoles a finales de febrero de 2026.

9:14 AM - Un usuario de GitHub llamado ericinfins abre el Issue #2: no puede conectar Beadbox a su servidor remoto de Dolt. La app solo soporta conexiones locales. Owner lo ve y lo señala para super.

9:30 AM - Super despacha el trabajo. Arch diseña un flujo de auth de conexión (toggle de TLS, campos de usuario/contraseña, paso de variables de entorno). PM escribe el spec con criterios de aceptación. Eng lo toma y empieza a implementar.

Mientras tanto, en paralelo:

PM reporta dos bugs descubiertos durante el testing de release. Uno es cosmético: el badge del header muestra "v0.10.0-rc.7" en lugar de "v0.10.0" en builds finales. El otro es específico de plataforma: la herramienta de captura de pantalla devuelve una franja en blanco en Macs ARM64 porque Apple Silicon renderiza el WebView de Tauri a través de composición Metal, y el backing store está vacío.

Ops identifica la causa del bug de captura. La solución es elegante: después de la captura, verificar si la altura de la imagen es sospechosamente pequeña (menos de 50px para una ventana que debería tener 800px de alto), y recurrir a captura basada en coordenadas de pantalla en su lugar.

Growth extrae datos de PostHog y ejecuta un análisis de correlación de IPs. El hallazgo: los anuncios de Reddit han generado 96 clics y cero usuarios retenidos atribuibles. El tráfico del README de GitHub convierte al 15.8%. Este mismo artículo existe gracias a ese análisis.

Eng1, desbloqueado por el diseño del Activity Dashboard de arch, comienza a construir gestión de estado de filtros cruzados y funciones utilitarias. 687 tests pasando.

QA1 valida el fix del badge del header: levanta un servidor de tests, usa automatización de navegador para verificar que el badge se renderiza correctamente, confirma que 665 tests unitarios pasan, marca PASS.

2:45 PM - Shipper fusiona el PR del release candidate, hace push del tag v0.10.0 y dispara el workflow de promoción. CI construye artefactos para las 5 plataformas (macOS ARM, macOS Intel, Linux AppImage, Linux .deb, Windows .exe). Shipper verifica cada artefacto, actualiza las notas de release en ambos repos, redespliega el sitio web y actualiza el cask de Homebrew.

3:12 PM - Owner responde en el GitHub Issue #2:

Buenas noticias: v0.10.0 acaba de publicarse con soporte completo de auth para servidor Dolt. Actualiza y deberías estar desbloqueado.

Bug reportado por la mañana. Fix enviado por la tarde. Y mientras eso pasaba, la siguiente feature ya se estaba diseñando, otro bug se estaba investigando, se estaban analizando analytics, y QA estaba verificando independientemente un fix separado.

Eso no es porque 13 agentes sean rápidos. Es porque 13 agentes son paralelos.

Lo que sale mal

Esta es la parte que la mayoría de posts de "mira mi setup de IA" omiten.

Los límites de tasa golpean con alta concurrencia. Cuando 13 agentes corren en la misma cuenta de API, quemas tokens rápido. En este día particular, super, eng1 y eng2 golpearon el techo de límite de tasa simultáneamente. Todos paran. Esperas. Es el equivalente en IA de todos en la oficina intentando usar la impresora al mismo tiempo, excepto que la impresora cobra por página y hay un tope de páginas por minuto.

QA rebota trabajo. Esto es por diseño, pero agrega ciclos. QA rechazó un build porque el comentario "DONE" del ingeniero no incluía pasos de verificación. El fix funcionaba, pero QA no podía confirmarlo sin leer código fuente. De vuelta a eng, reescribir el comentario de completitud, de vuelta a QA, re-verificar. Veinte minutos para lo que debieron ser cinco. El protocolo crea fricción, pero la fricción es estructural. Cada vez que me he saltado QA, algo se rompió en producción.

Las ventanas de contexto se llenan. Los agentes acumulan contexto durante una sesión. Super tiene un protocolo para enviar una directiva de "guarda tu trabajo" al 65% de uso de contexto. Si pierdes la ventana, el agente pierde el hilo de lo que estaba haciendo.

Los agentes se atascan. A veces un agente entra en un loop de errores y sigue reintentando el mismo comando fallido. El loop de patrullaje de super lo detecta, pero solo si verificas con suficiente frecuencia. He perdido 30 minutos con un agente que fallaba educadamente en silencio.

El overhead de coordinación es real. Archivos CLAUDE.md, protocolos de despacho, loops de patrullaje, comentarios en beads, reportes de completitud. Para un setup de dos agentes, esto es excesivo. Para 13 agentes, es la estructura mínima viable. Hay un punto de cruce alrededor de 5 agentes donde la coordinación informal deja de funcionar y necesitas protocolos explícitos o empiezas a perder la pista de lo que está pasando.

Lo que he aprendido

La especialización supera a la generalización. 13 agentes enfocados superan a 3 "full-stack". Cuando qa1 solo valida y nunca escribe código, atrapa cosas que eng se perdió cada vez. Cuando arch solo diseña y nunca implementa, los diseños son más limpios porque no hay tentación de atajar el spec para facilitar la implementación.

QA independiente no es negociable. QA tiene su propio clon del repo. Testea el código pushed, no el working tree. No confía en el auto-reporte del ingeniero. Suena lento. Atrapa bugs en cada release.

Necesitas visibilidad o la flota deriva. Con 5+ agentes, no puedes rastrear el estado alternando entre paneles de tmux y ejecutando bd list en tu cabeza. Necesitas un dashboard que te muestre el árbol de dependencias, qué agentes están trabajando en qué y qué beads están bloqueados. Este es el problema que construí Beadbox para resolver.

El loop recursivo importa. Los agentes construyen Beadbox. Beadbox monitorea a los agentes. Cuando los agentes producen un bug en Beadbox, la flota lo detecta a través del mismo proceso de QA que detectó todos los demás bugs. La herramienta mejora porque el equipo que más la usa es el equipo que la construye. Soy consciente de que esto es o brillante o la máquina de Rube Goldberg más elaborada jamás construida. Las features enviadas sugieren lo primero. Mi factura de tokens sugiere lo segundo.

El stack

Si quieres intentar esto, esto es lo que necesitas:

beads: Issue tracker open-source nativo de Git. Es la columna vertebral de coordinación. Cada agente lee y escribe en él.
Claude Code: El runtime de agentes. Cada agente es una sesión de Claude Code en un panel de tmux con su propio archivo de identidad CLAUDE.md.
tmux + gn/gp/ga: Multiplexor de terminal para ejecutar agentes lado a lado. Las herramientas de mensajería permiten a los agentes comunicarse sin memoria compartida.
Beadbox: Dashboard visual en tiempo real que te muestra lo que la flota está haciendo. Es sobre lo que estás leyendo.

No necesitas los 13 agentes para empezar. Dos ingenieros y un agente de QA, coordinados a través de beads, cambiarán cómo piensas sobre lo que un solo desarrollador puede entregar.

Qué viene después

La mayor brecha en el setup actual es responder tres preguntas de un vistazo: qué agentes están activos, ociosos o atascados? Dónde se acumula el trabajo en el pipeline? Y qué acaba de pasar, filtrado por el agente o etapa que me interesa?

Ahora mismo eso requiere un loop de patrullaje y muchos comandos gp. Así que estamos construyendo un dashboard de coordinación directamente en Beadbox: una franja de estado de agentes en la parte superior, un flujo de pipeline mostrando dónde se acumulan los beads, y un feed de eventos con filtros cruzados donde hacer clic en un agente o etapa del pipeline filtra todo lo demás para coincidir. Las tres capas comparten la misma fuente de datos en tiempo real. Las tres se actualizan en vivo.

Vista previa del Activity Dashboard

Los 13 agentes lo están construyendo ahora mismo. Escribiré sobre ello cuando se lance.

Desarrollo software con 13 agentes de IA. Así se ve realmente