[🛠] AI Orchestration #5: Rediseñé la separación entre coordinador y workers que había abandonado

✨ Resumen de GPT-5.6 Sol

Un registro de cómo abandoné la división del trabajo cuando los mensajes hicieron perder el contexto al coordinador y, tras sufrir el cuello de botella de una sola sesión, la rediseñé con informes en archivos y commits exclusivos del coordinador.

Una vez abandoné la separación entre coordinador y workers

El mes pasado conecté de verdad un coordinador con varios workers. Un objetivo se dividía en varias tareas y el coordinador revisaba e integraba lo que implementaban los workers.

La división del trabajo era rápida. Las funciones que no se solapaban podían implementarse a la vez, mientras el coordinador se ocupaba de la dirección global del producto y de la integración. El problema era cómo entregaban sus resultados los workers.

Cada vez que terminaban o quedaban bloqueados, enviaban un informe a la sesión del coordinador. Al principio parecía natural. Pero, al aumentar su número, los informes se acumulaban en la conversación y cada mensaje nuevo detenía el trabajo actual y lo desviaba hacia otra tarea.

Leía el resultado de las pruebas de un worker, pasaba a comprobar el conflicto del Git index de otro y, justo cuando intentaba volver a la implementación original, llegaba un tercer informe. La conversación crecía con rapidez. Cuanto más se comprimía, más tiempo exigía reconstruir el objetivo, las prohibiciones de despliegue y el estado actual del stage. En cierto momento, el coordinador se parecía menos a un integrador que a una ventanilla para tramitar mensajes.

Finalmente abandoné la propia separación entre coordinador y workers. Incluso borré impulsivamente la Skill de coordinación que había creado. Pensé que, al hacerlo todo en una sola sesión principal, al menos el contexto no sería arrastrado en varias direcciones.

Volver a una sola sesión mostró por qué hacía falta dividir el trabajo

Sin embargo, al continuar un producto grande en una sola sesión apareció enseguida el cuello de botella opuesto.

La misma sesión debía ocuparse, en orden, de implementación, pruebas, coherencia documental, verificación en dispositivos físicos y preparación del Runtime. Si surgía una pregunta de prioridad o una entrega de otra sesión, primero había que reconstruir el estado del trabajo en curso. Terminar bien una cosa alargaba el conjunto; atender primero lo urgente obligaba a decidir hasta dónde cerrar la tarea existente.

El problema no era la división del trabajo. Era ineficiente que una sesión retuviera incluso tareas independientes. Separar coordinador y workers seguía siendo lo más eficiente, pero revivir la estructura en la que los workers entraban directamente en la conversación actual del coordinador solo repetiría el fracaso.

Esta vez, en lugar de renunciar a la división, decidí eliminar la ruta de entrega que interrumpía el contexto del coordinador.

Una notificación de una línea abría la misma puerta

Primero pensé que quizá bastaría con que el worker enviara una línea en lugar de un informe largo.

READY task-042: ruta del informe

Pero la longitud no era el problema. En cuanto un mensaje entraba en la conversación del coordinador, Codex podía tratarlo fácilmente como un contexto más reciente que el trabajo en curso. Incluso una sola línea conservaba la misma entrada para cambiar de tarea.

Por eso los workers ya no envían mensajes al coordinador. Los estados de finalización, bloqueo y fallo se guardan únicamente en archivos de informe. El coordinador revisa el inbox solo después de llevar su propio trabajo hasta un checkpoint o commit seguro.

Que llegue un informe no es un acontecimiento que deba interrumpir el trabajo actual. Solo añade un archivo a la siguiente cola de revisión.

Los Worktrees estaban limpios, pero se alejaban del estado más reciente

Después consideré asignar un Worktree y una Branch separados a cada worker. Como el Git index y los cambios sin commit no se mezclaban, parecía la opción más limpia.

En proyectos reales surgía un problema mayor. Varias funciones tocaban continuamente la misma API, el mismo schema y la misma pantalla. Las mejoras terminadas antes en una sesión no aparecían de inmediato en los demás Worktrees. Cada cual trabajaba de forma limpia, pero al integrar se acumulaban cambios construidos sobre estructuras antiguas. Entonces el volumen de correcciones se volvía desagradable.

Esta vez elegí la estructura opuesta.

Un solo main Working Tree
├─ Varios workers ven juntos los cambios más recientes
├─ Cada worker edita solo los archivos y hunks asignados
├─ Los workers no hacen stage ni commit
└─ Solo el coordinador revisa, hace stage y commit

Un Working Tree compartido también se enreda de inmediato si no tiene límites. Por defecto, cada archivo tiene un solo writer; solo se permiten ediciones paralelas del mismo archivo cuando los hunks están claramente separados. Los schemas comunes, la limpieza de imports, los formatters y otros cambios que mueven código cercano se serializan.

Tampoco acepto las pruebas de un worker como evidencia final. Pueden haberse ejecutado junto con cambios sin commit de otro worker. Cada worker verifica su alcance; el coordinador congela el conjunto de cambios y ejecuta una vez la regresión completa y el build.

Los informes se convirtieron en contratos de revisión

Reconstruí la Skill de coordinación eliminada siguiendo estos principios. La nueva Skill custom-coordinate-parallel-workers contiene este flujo.

El coordinador asigna un task id, el resultado que debe obtener el usuario y las rutas con permiso de escritura. El worker termina la implementación, la verificación acotada y la limpieza de procesos temporales; después genera el informe de forma atómica y se detiene. El informe recoge los archivos realmente cambiados, los resultados de las comprobaciones, los solapamientos, el alcance pendiente y el commit propuesto.

El coordinador no vuelve a leer todas las conversaciones. Primero consulta en el inbox el task id, el estado, el título y el resumen de verificaciones, y elige una tarea para integrar. Comprueba que el informe coincida con el diff real y solo entonces hace stage y commit de los hunks exactos.

Cuando se elige un candidato de publicación, un freeze impide nuevas mutations de los workers. No se repiten pruebas completas mientras siguen entrando cambios: la documentación de current state, la regresión completa, el build y la verificación del despliegue comienzan cuando el conjunto de release deja de moverse.

El informe ya no es un simple diario de trabajo. Se convirtió en el contrato de revisión que permite al coordinador confiar en un cambio y llevarlo al estado siguiente.

Ahora debe funcionar en trabajo real

Probé las herramientas de gestión de estado de la Skill en un entorno temporal aislado. Pasaron la finalización normal, los conflictos de rutas escribibles, el retrabajo tras una solicitud de cambio, el rechazo del freeze durante la ejecución y el aplazamiento al siguiente batch.

Todavía no he operado varias sesiones reales de Codex de este modo. La siguiente tarea paralela deberá mostrar si los informes solo por archivo perturban menos el contexto del coordinador y si se respeta la propiedad de rutas del Working Tree compartido.

La conclusión se parece a la inicial, pero ahora la razón está más clara. Hace falta separar coordinador y workers. Lo que falló no fue la división del trabajo, sino enviar en tiempo real cada informe a la conversación actual del coordinador.

El cambio que espero no consiste simplemente en lanzar más workers. Consiste en que el coordinador conserve su contexto hasta terminar su propio trabajo. La velocidad del trabajo paralelo dependía menos del número de workers que de cuántas veces se apartaba a quien integraba sus resultados.