Acabas de levantar un segundo agente de Claude Code. Ahora tienes un problema.

El primer agente esta a medio camino de un refactoring. El segundo necesita construir una funcionalidad que toca algunos de los mismos archivos. Ninguno sabe que el otro existe. Tu eres el router, el almacen de estado y el resolutor de conflictos, todo a la vez, y tu unica herramienta es copiar y pegar contexto entre ventanas de terminal.

Aqui es donde la mayoria de los desarrolladores chocan con el muro usando Claude Code. No porque el agente sea malo programando. Porque no hay un sistema para decirle en que trabajar.

El problema del copiar y pegar

La mayoria de los workflows con Claude Code empiezan igual. Tienes una tarea en la cabeza (o en Jira, o en un issue de GitHub) y pegas la descripcion en el prompt del agente. "Construye un flujo de autenticacion." "Arregla el bug de paginacion." "Agrega soporte para modo oscuro."

Para un solo agente, esto funciona bien. El agente tiene todo el contexto, puedes observar su salida, y sabes cuando termina porque lo estas mirando.

Agrega un segundo agente y las grietas aparecen de inmediato.

El Agente A esta refactorizando la capa de API. El Agente B esta construyendo un nuevo endpoint. Ambos estan tocando server/routes.ts. Ninguno sabe de los cambios del otro. Descubres el conflicto cuando uno hace push y el trabajo del otro se rompe. O peor: ambos tienen exito localmente pero el resultado combinado esta roto de formas que ningun diff revela.

La causa raiz no es que los agentes sean descuidados. Es la ausencia de estado compartido. No hay un lugar donde "el Agente A es dueno del refactoring de la API" este registrado. No hay un estado que diga "el archivo de rutas esta siendo modificado, espera tu turno." Los agentes estan operando sobre prompts individuales con cero conciencia del panorama completo.

Agrega un tercer agente y pasas mas tiempo coordinando que programando.

Que necesitan realmente los agentes de un sistema de tareas

Antes de buscar una herramienta, vale la pena preguntar: que necesita realmente un agente de Claude Code para hacer buen trabajo?

Sorprendentemente poco.

Un identificador unico. Algo que pueda referenciar en commits y comentarios. "Arregle el bug" es inutil en un log multi-agente. "Completado PROJ-47: la paginacion devuelve conteo incorrecto en vistas filtradas" es rastreable.

Un alcance claro. Titulo, descripcion y criterios de aceptacion. No una novela. No una user story con personas. Una declaracion concreta de como se ve "terminado." "El endpoint /users devuelve resultados paginados. El tamano de pagina es 25 por defecto. El campo next_cursor es null en la ultima pagina."

Un estado que pueda actualizar. El agente necesita senalar donde esta: reclamado, en progreso, hecho. Sin esto, vuelves a asomarte a ventanas de terminal y adivinar.

Conciencia de dependencias. "No empieces esto hasta que PROJ-46 este mergeado" previene la falla multi-agente mas comun: construir sobre codigo que aun no existe.

Nota lo que falta en esta lista. Planificacion de sprints. Seguimiento de velocidad. Tableros Kanban. Story points. Epics con etiquetas de colores. Los agentes no necesitan teatro de gestion de proyectos. Necesitan una tarea, un estado y una forma de decir "termine."

El contrato CLAUDE.md

El sistema de tareas le dice a los agentes en que trabajar. El archivo CLAUDE.md les dice como trabajar.

Si estas ejecutando multiples agentes de Claude Code, cada uno deberia tener un CLAUDE.md que defina su identidad y limites. Esto no es configuracion opcional. Es la diferencia entre agentes que coordinan y agentes que se estorban mutuamente.

Aqui un ejemplo simplificado para un agente de ingenieria:

## Identity

Engineer for the project. You implement features, fix bugs,
and write tests. You own implementation quality.

## What You Own

- All files under `components/` and `lib/`
- Unit tests in `__tests__/`
- You may read but not modify files under `server/`

## What You Don't Own

- Deployment configuration (that's ops)
- Issue triage and prioritization (that's the coordinator)
- QA validation (QA tests your work independently)

## Completion Protocol

Before marking any task done:
1. Run the full test suite: `pnpm test`
2. Verify your change works manually
3. Comment what you did with the commit hash
4. Push before reporting completion

La seccion de limites es la parte estructural. Sin propiedad explicita de archivos, los agentes divagan. Un agente de ingenieria refactoriza "amablemente" la configuracion de deployment. Un agente de QA "arregla" un test cambiando el codigo bajo prueba en lugar del test mismo. Los limites explicitos previenen estos modos de falla.

El protocolo de finalizacion importa igual. Previene la falla de agente mas comun: declarar algo como terminado cuando solo compila. "Ejecutar la suite completa de tests" y "verificar manualmente" son gates concretos. Un agente que sigue este protocolo produce trabajo en el que un humano puede confiar. Un agente sin el produce trabajo que tienes que revisar linea por linea.

Escala esto a multiples agentes y obtienes una flota donde cada miembro conoce su carril, su protocolo de traspaso y lo que significa "terminado."

Gestion de tareas CLI-first

Aqui una observacion de workflow que me tomo mas tiempo internalizar del que deberia: los agentes de Claude Code trabajan dramaticamente mejor con herramientas CLI que con interfaces GUI.

Tiene sentido cuando lo piensas. Un agente de Claude Code vive en la terminal. Puede ejecutar comandos, leer salidas y tomar acciones basadas en resultados. Pedirle que navegue una UI web, haga clic en botones e interprete paginas renderizadas es luchar contra la interfaz natural del agente.

Un sistema de tareas basado en CLI significa que el agente puede hacer esto en un solo flujo:

# Read the task
task show PROJ-47

# Claim it
task update PROJ-47 --status in_progress --assignee agent-1

# Do the work...

# Report completion
task comment PROJ-47 "DONE: Fixed pagination. Commit: abc1234"
task update PROJ-47 --status done

Sin cambio de contexto. Sin ventanas de navegador. Sin capturas de pantalla de un tablero Kanban. El agente lee una tarea, hace el trabajo y actualiza el estado, todo sin salir del entorno donde opera.

La salida tambien es legible por maquinas. Cuando necesitas verificar que esta pasando con todos los agentes, puedes consultar:

task list --status in_progress    # What's being worked on?
task list --assignee agent-2      # What is agent-2 doing?
task list --blocked               # What's stuck?

Esta es la forma del tooling que funciona. Un CLI que habla el idioma del agente.

Beads: seguimiento de issues local-first para agentes

El workflow que describi arriba no es hipotetico. Es lo que ejecuto todos los dias con beads, un issue tracker open-source y local-first construido exactamente para este tipo de desarrollo dirigido por agentes.

beads almacena issues (llamados "beads") en una base de datos Dolt local junto a tu codebase. Cada bead tiene un ID, titulo, descripcion, estado, prioridad, dependencias y un hilo de comentarios. El CLI se llama bd, y es la interfaz que los agentes usan para leer tareas, actualizar estado y dejar comentarios estructurados.

Aqui un workflow real. Creo una tarea:

bd create --title "Fix pagination on filtered views" \
  --description "The /users endpoint returns wrong count when filters are applied. Page size defaults to 25. next_cursor should be null on the last page." \
  --priority p2

Un agente la reclama:

bd update bb-r3k2 --claim --actor eng1
bd update bb-r3k2 --status in_progress

Antes de escribir cualquier codigo, el agente comenta su plan:

bd comments add bb-r3k2 --author eng1 "PLAN:
1. Fix count query in /users to apply filters before COUNT()
2. Add cursor boundary check for last page
3. Add test cases for filtered pagination

Files:
- server/routes/users.ts - fix count query
- server/routes/users.test.ts - add filtered pagination tests"

Esto es un checkpoint. Si el plan esta mal, lo detectas en 30 segundos en lugar de descubrir una mala implementacion 45 minutos despues.

El agente hace el trabajo, ejecuta tests y comenta la finalizacion:

bd comments add bb-r3k2 --author eng1 "DONE: Fixed filtered pagination count.

- COUNT() now applies the same WHERE clause as the data query
- next_cursor returns null when offset + page_size >= total_count
- Added 4 test cases covering filtered + unfiltered pagination

Commit: a1b2c3d"

bd update bb-r3k2 --status ready_for_qa

La tarea ahora tiene un audit trail completo: que se solicito, que planeo el agente, que hizo realmente, y el commit hash para revisar. Un segundo agente ejecutando QA puede tomarla y verificar independientemente.

Esto funciona porque beads habla el mismo idioma que los agentes. Todo es un comando CLI. Todo produce salida estructurada. No hay desajuste de impedancia entre la herramienta y el agente.

Ver el panorama completo

El workflow CLI escala a 3 o 4 agentes antes de que llegues a un nuevo techo. No un techo de herramientas. Uno cognitivo.

Con 5 agentes, ejecutar bd list y ensamblar mentalmente el estado del proyecto es como leer una hoja de calculo e intentar mantener un grafo de dependencias en la cabeza. Que tareas estan bloqueadas? Que agente no ha actualizado su estado en 20 minutos? El epic de la funcionalidad esta al 60% o al 80%? La informacion esta toda ahi en la salida del CLI, pero armarla requiere esfuerzo que se acumula con cada agente adicional.

Aqui es donde encaja Beadbox. Es un dashboard en tiempo real que se coloca encima de beads y te muestra el estado de toda tu flota de agentes. Arboles de dependencias renderizados visualmente. Barras de progreso de epics. Hilos de comentarios de agentes que puedes escanear sin ejecutar cinco comandos bd show.

Beadbox no reemplaza el CLI. Los agentes siguen usando bd para todo. Beadbox es la capa que abres cuando necesitas el panorama completo: que flujos de trabajo se mueven, cuales estan atascados y donde estan los cuellos de botella. Observa la base de datos de beads buscando cambios y se actualiza en tiempo real, asi que nunca ves datos obsoletos.

Es gratuito durante la beta y se ejecuta completamente en tu maquina. Sin cuentas, sin nube, tus datos se quedan locales.

Primeros pasos

No necesitas 13 agentes para obtener valor de la gestion estructurada de tareas. Empieza con dos agentes de Claude Code y una regla: cada tarea obtiene un bead, cada agente comenta su plan antes de programar, cada finalizacion incluye pasos de verificacion.

El patron se multiplica. Una vez que los agentes tienen un sistema de tareas compartido, puedes agregar agentes de QA que verifican trabajo independientemente. Puedes agregar un coordinador que despacha tareas desde una cola de prioridades. Puedes escalar a 5, 10, 15 agentes sin que la sobrecarga de coordinacion crezca linealmente, porque los protocolos manejan lo que antes era cambio de contexto manual.

Las herramientas:

beads para gestion de tareas local-first. Open source.
Claude Code como runtime de agentes.
Beadbox para supervision visual cuando la flota crece.

Si estas construyendo workflows como este, dale una estrella a Beadbox en GitHub.

Como gestionar tareas para agentes de Claude Code