El orquestador: pensamiento CI/CD aplicado a agentes de IA

En el artículo anterior de esta serie describía un harness como el entorno en el que trabaja un agente — instrucciones, Skills, MCPs, hooks, permisos, tests, puntos de revisión humana, todo funcionando junto en lugar de interacciones sueltas.

Pero un harness responde a qué sabe un agente y qué tiene permitido tocar. No responde a una pregunta distinta: en qué orden sucede el trabajo, y quién es responsable de cada parte.

Esa es la pieza que quiero añadir ahora: la orquestación.

Un solo agente haciéndolo todo se corrige a sí mismo las tareas

He tenido sesiones en las que un único agente, en un único contexto, interpretaba una petición ambigua, decidía qué significaba "terminado", escribía el código y luego me decía que ya estaba — todo sin una sola comprobación independiente en medio.

Cuando la especificación era ambigua, rellenaba el hueco con su propia suposición en lugar de señalarlo. Cuando la implementación terminaba, el mismo agente que la había escrito era también el que juzgaba si cumplía los requisitos (asumidos). Nunca se forzaba una segunda opinión, porque no había un segundo nada — solo un flujo continuo de decisiones sin ninguna costura donde yo pudiera intervenir.

Eso no es un problema del modelo. Es un problema de estructura. Pedidle a cualquier ingeniero que escriba una feature, defina qué significa "terminado" y apruebe su propia PR, todo sin que nadie revise nada en medio, y ya sabéis cómo acaba eso.

Este patrón ya tiene nombre: CI/CD

Nadie confiaría en un único script llamado ship_it.sh que compila, testea y despliega sin ningún punto de control en medio. Por eso existen los pipelines de CI/CD:

Pull branch/tag
      ↓
Build
      ↓
Run unit tests
      ↓
Run integration tests
      ↓
Generate version
      ↓
Deploy

Cada paso tiene una única responsabilidad. Cada paso puede fallar de forma independiente. Nada avanza solo porque el paso anterior "parecía estar bien".

Un flujo de trabajo con agentes se puede estructurar de la misma forma:

Read request
      ↓
Refine spec
      ↓
Human approval
      ↓
Implement changes
      ↓
Run checks
      ↓
Verify output
      ↓
Human approval
      ↓
Deliver

Esto no es una metáfora que estoy forzando para sonar ingenioso. Es el mismo problema de fondo: un trabajo demasiado importante como para confiarlo a una sola pasada sin control se beneficia de dividirse en etapas, cada una con una responsabilidad clara y una condición de salida clara.

Tres roles, tres agentes

Una vez existe el pipeline, los roles dentro de él resultan obvios:

Refiner Agent — lee la petición original y la convierte en una especificación clara: dependencias, casos esquina, restricciones, criterios de aceptación. Su único trabajo es eliminar la ambigüedad, no escribir código.
Implementation Agent — construye la solución siguiendo esa especificación. Respeta la arquitectura, las convenciones y los límites técnicos ya definidos en el harness. No decide cuáles son los requisitos — esa decisión ya se tomó antes.
Verification Agent — revisa el resultado contra la especificación, ejecuta o propone comprobaciones, y busca específicamente riesgos, deuda técnica, casos esquina y regresiones. No tiene ningún interés en que la implementación sea "buena"; su único trabajo es averiguar si de verdad lo es.

Ninguno de ellos necesita ser un modelo más listo que los demás. El valor no está en la inteligencia, está en no dejar que la misma pasada de trabajo haga la pregunta, la responda y se ponga la nota.

El orquestador es el router, no un cuarto cerebro

Es tentador pensar que el orquestador es la pieza "lista" que lo une todo. No lo es, y tratarlo así echa por tierra la idea.

El trabajo del orquestador es mecánico: decidir el orden de ejecución, pasar la salida correcta de un agente como entrada del siguiente, definir la condición que tiene que cumplirse antes de que un paso pueda empezar, y detener el pipeline en los puntos donde una persona necesita mirarlo.

Si el orquestador empieza a tomar decisiones de criterio sobre el trabajo en sí — decidir si una implementación es suficientemente buena, por ejemplo — acabáis de recrear el problema del agente único, con pasos de más.

Puntos de aprobación humana: donde el pipeline se detiene a propósito

Los dos puntos de control que más importan son justo después de la especificación y justo después de la verificación.

Aprobar la especificación antes de que empiece la implementación hace que los desacuerdos se detecten mientras todavía son baratos — una frase que editar, no una PR que reescribir. Aprobar la verificación antes de dar algo por entregado hace que la última palabra sobre "esto está realmente terminado" sea de una persona, no del agente que lo construyó.

Este es exactamente el equilibrio que me importa: mantener la velocidad del pipeline sin perder control técnico en los dos momentos que más importan.

Por qué no todo debe vivir en un solo `CLAUDE.md`

Una vez tenéis un buen harness, existe la tentación de meterlo todo en un único archivo de instrucciones y dejar que un solo agente lo lea entero para cada tarea.

Pero un Refiner no necesita detalles de arquitectura a nivel de implementación, y un Implementation Agent no necesita ver cómo la verificación puntúa la deuda técnica. Meterlo todo en un contexto compartido no hace más inteligente al agente — solo lo hace más lento a la hora de encontrar las partes que de verdad importan para el paso en el que está.

La orquestación también es una decisión de alcance: cada agente recibe la parte del harness relevante para su rol, no todo por defecto.

Conclusión

Un harness define el entorno en el que trabaja un agente. Un orquestador define la secuencia en la que se usa ese entorno, y en qué puntos una persona tiene que dar el visto bueno antes de que empiece el siguiente paso.

Ninguno de los dos sustituye el criterio. Los dos existen para asegurar que el criterio — el vuestro, y el del agente — se aplique en el momento correcto, en lugar de todo de golpe, o nunca.

En el próximo artículo de esta serie entraré en detalle sobre qué va exactamente en ese primer punto de control: Spec-Driven Development: Let AI Write the Code, Not the Requirements — y por qué el paso del Refiner es el primero que se salta la mayoría de equipos, y el último que se paga.

Hasta entonces, la pregunta que merece la pena hacerse no es:

¿Ha terminado el agente la tarea?

Es:

¿Qué paso se encargó de comprobar de verdad que era la tarea correcta, hecha de la forma correcta?

Si estáis usando algo parecido a esto — aunque sea de forma informal — me gustaría saber cómo repartís los roles. No dudéis en escribirme.