Más agentes, más coordinación

Un agente de programación es una herramienta. Dos o más empiezan a parecer un equipo, y los equipos traen un viejo problema: la coordinación. Alguien debe decidir qué hacer, alguien debe recordar cómo van las cosas y alguien debe comprobar que «listo» significa listo.

Cuando uso Claude Code o Codex en una sesión, soy esas tres personas. Funciona hasta que el trabajo supera una sesión. Entonces soy el enrutador, copiando contexto entre conversaciones, recordando qué cambio esperaba a cuál y volviendo a explicar decisiones ya tomadas. Los agentes son rápidos. La coordinación soy yo, y yo no lo soy.

Por eso he estado investigando herramientas que se toman en serio la coordinación. No para construir una fábrica autónoma de software, sino para entender qué parte de ese trabajo puede hacerse explícita.

Tres responsabilidades fáciles de confundir

Decidir el trabajo. Qué parte viene después, quién la asume y con qué instrucciones. Eso es orquestación.

Mantener el estado. Qué está listo, bloqueado, en curso y qué depende de qué. Debe sobrevivir al final de una sesión, porque los agentes olvidan y yo también.

Verificar. Si el resultado cumple de verdad los criterios. Importa quién lo hace. Un agente que escribe el código y luego lo aprueba no ha verificado mucho.

La mayor parte de la confusión que he encontrado viene de que una herramienta hace las tres cosas sin dejarlo claro o de que nadie asume claramente la tercera.

Lo que he estado probando

Dos herramientas del mismo ecosistema encajan bien con las dos primeras responsabilidades. No construí ninguna; soy un usuario intentando entenderlas.

Gas City se describe como un SDK para construir la orquestación de flujos de programación con múltiples agentes. Toma la infraestructura reutilizable de Gas Town (proveedores de ejecución, distribución de trabajo, fórmulas y vigilancia del estado) y la hace configurable. En mis términos, es un candidato a decidir el trabajo.

Beads es un gestor persistente de tareas, consciente de las dependencias, creado para agentes de programación. En lugar de un plan Markdown que un agente quizá relea o no, el trabajo es un grafo de tareas con dependencias explícitas. Así, «¿qué está listo para empezar?» se convierte en una consulta, no en una suposición. En mis términos, es mantener el estado.

Configuré ambos localmente, junto con Serena, que ofrece a los agentes navegación y edición de código por símbolos mediante MCP, en lugar de leer archivos enteros. Después ejecuté una prueba de extremo a extremo deliberadamente pequeña en un escenario sintético. El flujo leyó una especificación aprobada, produjo un plan, revisó ese plan, lo dividió en un grafo de tareas en Beads, implementó el cambio en un árbol de trabajo aislado y ejecutó comprobaciones protegidas. Una sesión separada hizo la revisión antes de la comprobación final.

Pasó. El cambio eran unas pocas líneas en un módulo de cálculo de ejemplo.

Quiero ser preciso sobre lo que demuestra. Demuestra que este flujo puede funcionar de extremo a extremo, con esta configuración, en algo diminuto. No demuestra que escale, que sea más rápido que yo con un agente ni que esté listo para construir un producto real. Llegar hasta ahí también requirió varias ejecuciones de diagnóstico, lo cual ya es un dato sobre el coste de operarlo.

Dónde está la verificación

La parte que más me interesa es la relación entre cerrar una tarea y demostrar que terminó. En un gestor, cerrarla es un cambio de estado. Quiero que el cierre exija evidencia: qué comprobaciones se ejecutaron, en qué commit y quién las revisó. El sistema debería poder decir «cerrada porque estas comprobaciones pasaron», no solo «cerrada».

Por eso también mantengo la especificación y las decisiones fuera de la herramienta de seguimiento. Esta guarda el estado de ejecución; los motivos del trabajo viven en documentos que no cambian cuando cambio de herramienta.

Para las comprobaciones en sí, he estado leyendo sobre Dagger (pipelines como código, con motor de ejecución portátil y caché) y las ejecuciones de Nx solo para lo afectado. No he adoptado ninguno en mi configuración y no tengo mediciones que compartir. Están en la lista porque «ejecutarlo todo, siempre» sale caro cuando los agentes producen cambios más rápido de lo que termina la CI.

Preguntas abiertas

• ¿Dónde reduce la orquestación la coordinación manual y dónde solo crea otro sistema que operar? Un entorno con múltiples agentes tiene su propia configuración, fallos y actualizaciones. Ese coste es real.
• ¿Cuánta autonomía es útil antes de que la revisión se convierta en el cuello de botella? Más agentes significan más cambios que verificar, y la revisión no se paraleliza tan bien como la generación de código.
• ¿Cuál es el mínimo de contexto para que una tarea siga haciéndose bien? Con poco, el agente adivina. Con demasiado, se ahoga.

Aún no tengo respuestas y desconfío de quien ya las tiene. Tengo una visión más clara de las tres responsabilidades y la fuerte impresión de que la última es la que más merece protección: alguien, o algo independiente, debe comprobar el trabajo.