🎭 El Orchestrator: cerebro del sistema
En el centro de cualquier sistema escalable de loop engineering está el orchestrator: la sesión de agente que lee la especificación, decide qué tareas ejecutar, inicia workers y valida los resultados. No escribe código directamente. Su función es razonar sobre el estado del proyecto y tomar decisiones de alto nivel sobre qué hacer después.
💬 Cómo describe Cole Medin el orchestrator
"Enviamos nuestra especificación inicial al orquestador y este tiene que analizarla, decidir cuántos workers iniciar y luego darles instrucciones a todos. Cada uno consume tokens y después llegan los resultados."
El orchestrator funciona como un gerente de proyectos automatizado. Recibe la spec (lo que hay que hacer), analiza el estado actual del repositorio y decide: ¿cuántos workers necesito? ¿Qué tareas asigno a cada uno? ¿En qué orden? ¿Cuándo está completo el trabajo? Cada una de estas decisiones cuesta tokens de reasoning, y por eso el orchestrator es una de las partes más costosas del sistema.
📋 Responsabilidades del orchestrator
- ✓Leer la especificación y entender el alcance total del trabajo
- ✓Planificar rondas: dividir el trabajo en oleadas de ejecución
- ✓Asignar workers: crear prompts específicos para cada worker
- ✓Validar resultados: comprobar si los workers entregaron lo esperado
- ✓Decidir el siguiente paso: iniciar una nueva oleada o declarar que se completó el trabajo
⚙ Workers: ejecución paralela y aislada
Los workers son sesiones de agente independientes que reciben una tarea específica del orchestrator y la ejecutan. Cada worker opera de forma aislada, idealmente en su propia worktree de git, para que varios workers puedan trabajar en paralelo sin interferir con el código de los demás.
"Si varios agentes se encargan de tareas dentro de un loop, tenemos que asegurarnos de que se ejecuten de forma aislada para que no interfieran entre sí. Así es como escalamos lo que producimos con la ayuda de la programación con IA."
✓ Worktrees para aislamiento
- ✓Cada worker opera en una copia aislada del repositorio
- ✓Sin conflictos de archivos entre workers paralelos
- ✓Cada uno puede hacer commits y crear ramas independientes
- ✓Merge controlado por el orchestrator al final
⚙ Anatomía de un worker
- 1.Recibe una tarea específica del orchestrator
- 2.Inicia una sesión de agente en un worktree
- 3.Ejecuta: escribe código, realiza pruebas, valida
- 4.Reporta el resultado al state store
💾 Gestión externa del estado
Uno de los problemas más críticos de los loops largos es el saturación de contexto: a medida que el agente acumula historial de conversación, la ventana de contexto del LLM se sobrecarga y la calidad de las respuestas se degrada. La solución arquitectónica es mover el estado fuera del LLM, usando un base de datos externa como fuente de verdad.
"Cuando simplemente usas slash loop en Claude Code, el proceso continúa en la misma sesión del agente de programación. Si mantienes el loop durante un tiempo, el contexto de tu LLM crecerá demasiado y lo abrumará."
📊 Ventana de contexto vs. almacén de estado
✗ Sin estado externo
Todo el historial vive en la ventana de contexto. Después de 10-20 iteraciones, el LLM empieza a "olvidar" las instrucciones iniciales, generar código repetido y perder coherencia. Es como intentar memorizar un libro entero en vez de consultar notas.
✓ Con estado externo (Postgres/Neon)
La base de datos almacena: tareas completadas, tareas pendientes, resultados de validación, registros de decisiones y costo acumulado. Cada nueva sesión del orchestrator lee solo el estado actual, no todo el historial. El context window se convierte en caché, no en almacenamiento.
🗄 Lo que almacena el State Store
Runs
Historial de ejecuciones: especificación original, rondas realizadas, estado general (running, paused, completed, failed).
Events / Logs
Cada decisión del orquestador y cada resultado de un worker. Permite la auditoría y la depuración posterior a la ejecución.
Estado de la tarea
Estado de cada tarea individual: pending, in_progress, completed, failed. El orquestador lo lee para decidir la siguiente ronda.
Seguimiento de costos
Tokens consumidos por ronda y por worker, costo total acumulado. Permite definir límites de presupuesto.
🔄 El flujo completo de una ronda
Una "ronda" es la unidad de trabajo del sistema orchestrator-workers. Cada round sigue un flujo predecible: el orchestrator lee el estado, decide qué hacer, despacha workers, recopila resultados y evalúa si necesita más rounds. Este ciclo se repite hasta que se alcanza el goal o se agota el budget.
🏃 Paso a paso de un round
El orchestrator lee el state store
Consulta la base de datos para saber: ¿qué tareas están pendientes? ¿Qué entregaron los workers de la ronda anterior? ¿Hay errores que corregir?
Planifica la ola de workers
Decide cuántos workers iniciar, qué tareas asignar a cada uno y prepara los prompts específicos. Eso es el fan-out.
Los workers se ejecutan en paralelo
Cada worker comienza en un worktree aislado, ejecuta su tarea (escribe código, corre pruebas) y guarda el resultado en el almacén de estado.
Fan-in: el orquestador recopila resultados
Cuando todos los workers terminan, el orchestrator lee los resultados del state store y evalúa: ¿todo pasó? ¿Hay fallas? ¿Debo volver a ejecutar algún worker?
Decisión: siguiente ronda o conclusión
Si queda trabajo pendiente, el orchestrator planifica la siguiente ronda. Si se alcanzó el goal, declara que la run está completa y se lo informa a la persona.
"El orquestador usó 6,000 tokens en la planificación inicial y luego en las instrucciones para nuestros primeros tres workers de la primera ronda."
🛡 Durabilidad y capacidad de reanudar
Los loops largos inevitablemente fallan en algún momento. La máquina puede reiniciarse, la sesión del agente puede caerse, la red puede oscilar. La cuestión no es si va a fallar, pero cuando. Durabilidad significa que el sistema puede reanudar desde donde quedó, sin perder el trabajo ya realizado. Y eso solo es posible con una gestión externa del estado.
"Estoy guardando aquí todos los loops que ejecutamos, los distintos eventos y los registros para que siempre podamos reanudar un flujo de trabajo más adelante. Así que gestionamos todo nuestro estado en una base de datos externa."
🔧 Cómo funciona la capacidad de reanudación
Punto de control por ronda
Al final de cada round, el estado completo se guarda en la base de datos: tareas completadas, resultados de los workers y decisiones del orchestrator. Si el sistema se cae entre rounds, basta con leer el último checkpoint y continuar.
Resume from last good state
El orchestrator no necesita el historial de conversación para retomar. Lee el state store y sabe exactamente en qué punto está el proyecto. Una nueva sesión de agente es tan eficaz como la anterior.
Limpieza de workers huérfanos
Si un worker se cae a mitad de la ejecución, el orchestrator lo detecta (mediante un timeout o el estado en la base de datos) y puede volver a asignar la tarea a un nuevo worker en la siguiente ronda.
🎯 Punto de reflexión
Sin durabilidad, la ingeniería de loops es un juguete caro. Imagina ejecutar un loop durante 4 horas, gastar cientos de miles de tokens y perderlo todo porque se cerró la terminal. El state externo transforma un experimento frágil en un sistema que puede ejecutarse de verdad. Cole Medin construyó exactamente eso en su dashboard: "Estoy guardando esto aquí para que siempre podamos reanudar un workflow más adelante."
❓ Preguntas
La arquitectura orchestrator-workers es elegante en teoría, pero plantea serias preguntas prácticas. Cole Medin, a pesar de haber creado un panel funcional para esto, mantiene una postura cautelosa.
¿El orchestrator es un cuello de botella de costos?
Cada decisión del orquestador consume tokens de razonamiento. Cuanto más compleja es la especificación, más tokens se necesitan para planificar rondas y evaluar resultados. Cole mostró que una sola ejecución de una aplicación sencilla consumió más de 1 millón de tokens. La pregunta es: ¿vale la pena pagar ese costo de razonamiento por cada decisión o un workflow determinista (como Archon) lo resuelve mejor?
¿Quién valida al validador?
El orchestrator valida los resultados de los workers, pero también es un LLM. Si alucina durante la validación (aceptando un resultado malo como bueno), el error se propaga a las rondas siguientes. Sin human-in-the-loop en puntos críticos, la autovalidación puede ser un punto ciego peligroso.
Determinismo frente a autonomía: ¿dónde está el equilibrio?
Cole Medin prefiere workflows deterministas en los que el humano define los steps. Boris Cherny prefiere autonomía total, con el orchestrator decidiendo todo. La verdad probablemente está en el medio: usar el orchestrator para decisiones de enrutamiento y modelo para el código, pero no para definir todo el proceso.
⚠ La provocación de Cole
Cole sintetiza su postura sobre darle autonomía total al orchestrator: "Queremos quitarle la decisión al agente de programación tanto como podamos y aplicar el razonamiento del LLM solo cuando realmente necesitemos que escriba el código." El orchestrator debe ser lo mínimo necesario, no lo máximo posible.
📋 Resumen del módulo
Módulo siguiente:
2.1 — Ventajas reales (Ruta 2: Ventajas vs. desventajas)