L'orquestrador: pensament CI/CD aplicat a agents d'IA

A l'article anterior d'aquesta sèrie descrivia un harness com l'entorn en què treballa un agent — instruccions, Skills, MCPs, hooks, permisos, tests, punts de revisió humana, tot funcionant plegat en lloc d'interaccions soltes.

Però un harness respon a què sap un agent i què té permès tocar. No respon a una pregunta diferent: en quin ordre passa la feina, i qui és responsable de cada part.

Aquesta és la peça que vull afegir ara: l'orquestració.

Un sol agent fent-ho tot es corregeix ell mateix les tasques

He tingut sessions en què un únic agent, en un únic context, interpretava una petició ambigua, decidia què significava "acabat", escrivia el codi i després em deia que ja estava — tot sense una sola comprovació independent enmig.

Quan l'especificació era ambigua, omplia el buit amb la seva pròpia suposició en lloc de senyalar-lo. Quan la implementació acabava, el mateix agent que l'havia escrit era també el que jutjava si complia els requisits (assumits). Mai es forçava una segona opinió, perquè no hi havia un segon res — només un flux continu de decisions sense cap costura on jo pogués intervenir.

Això no és un problema del model. És un problema d'estructura. Demaneu a qualsevol enginyer que escrigui una feature, defineixi què significa "acabat" i aprovi la seva pròpia PR, tot sense que ningú revisi res enmig, i ja sabeu com acaba això.

Aquest patró ja té nom: CI/CD

Ningú confiaria en un únic script anomenat ship_it.sh que compila, testeja i desplega sense cap punt de control enmig. Per això existeixen els pipelines de CI/CD:

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

Cada pas té una única responsabilitat. Cada pas pot fallar de manera independent. Res avança només perquè el pas anterior "semblava estar bé".

Un flux de treball amb agents es pot estructurar de la mateixa manera:

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

Això no és una metàfora que estic forçant per semblar enginyós. És el mateix problema de fons: una feina massa important per confiar-la a una sola passada sense control es beneficia de dividir-se en etapes, cadascuna amb una responsabilitat clara i una condició de sortida clara.

Tres rols, tres agents

Un cop existeix el pipeline, els rols dins seu resulten evidents:

• Refiner Agent — llegeix la petició original i la converteix en una especificació clara: dependències, casos límit, restriccions, criteris d'acceptació. La seva única feina és eliminar l'ambigüitat, no escriure codi.
• Implementation Agent — construeix la solució seguint aquesta especificació. Respecta l'arquitectura, les convencions i els límits tècnics ja definits al harness. No decideix quins són els requisits — aquesta decisió ja s'ha pres abans.
• Verification Agent — revisa el resultat contra l'especificació, executa o proposa comprovacions, i busca específicament riscos, deute tècnic, casos límit i regressions. No té cap interès que la implementació sigui "bona"; la seva única feina és esbrinar si realment ho és.

Cap d'ells necessita ser un model més llest que els altres. El valor no és en la intel·ligència, és en no deixar que la mateixa passada de feina faci la pregunta, la respongui i es posi la nota.

L'orquestrador és el router, no un quart cervell

És temptador pensar que l'orquestrador és la peça "llesta" que ho lliga tot. No ho és, i tractar-lo així fa perdre el sentit de la idea.

La feina de l'orquestrador és mecànica: decidir l'ordre d'execució, passar la sortida correcta d'un agent com a entrada del següent, definir la condició que s'ha de complir abans que un pas pugui començar, i aturar el pipeline en els punts on una persona necessita mirar-lo.

Si l'orquestrador comença a prendre decisions de criteri sobre la feina en si — decidir si una implementació és prou bona, per exemple — acabeu de recrear el problema de l'agent únic, amb passos de més.

Punts d'aprovació humana: on el pipeline s'atura a propòsit

Els dos punts de control que més importen són just després de l'especificació i just després de la verificació.

Aprovar l'especificació abans que comenci la implementació fa que els desacords es detectin mentre encara són barats — una frase per editar, no una PR per reescriure. Aprovar la verificació abans de donar alguna cosa per entregada fa que l'última paraula sobre "això està realment acabat" sigui d'una persona, no de l'agent que ho ha construït.

Aquest és exactament l'equilibri que m'importa: mantenir la velocitat del pipeline sense perdre control tècnic en els dos moments que més importen.

Per què no tot ha de viure en un sol CLAUDE.md

Un cop teniu un bon harness, existeix la temptació de ficar-ho tot en un únic fitxer d'instruccions i deixar que un sol agent el llegeixi sencer per a cada tasca.

Però un Refiner no necessita detalls d'arquitectura a nivell d'implementació, i un Implementation Agent no necessita veure com la verificació puntua el deute tècnic. Ficar-ho tot en un context compartit no fa més intel·ligent l'agent — només el fa més lent a l'hora de trobar les parts que realment importen per al pas en què es troba.

L'orquestració també és una decisió d'abast: cada agent rep la part del harness rellevant per al seu rol, no tot per defecte.

Conclusió

Un harness defineix l'entorn en què treballa un agent. Un orquestrador defineix la seqüència en què es fa servir aquest entorn, i en quins punts una persona ha de donar el vistiplau abans que comenci el següent pas.

Cap dels dos substitueix el criteri. Els dos existeixen per assegurar que el criteri — el vostre, i el de l'agent — s'apliqui en el moment correcte, en lloc de tot de cop, o mai.

Al pròxim article d'aquesta sèrie entraré en detall sobre què va exactament en aquest primer punt de control: Spec-Driven Development: Let AI Write the Code, Not the Requirements — i per què el pas del Refiner és el primer que es salta la majoria d'equips, i l'últim que es paga.

Fins llavors, la pregunta que val la pena fer-se no és:

Ha acabat l'agent la tasca?

És:

Quin pas s'ha encarregat de comprovar de debò que era la tasca correcta, feta de la manera correcta?

Si esteu fent servir alguna cosa semblant a això — encara que sigui de manera informal — m'agradaria saber com repartiu els rols. No dubteu a escriure'm.