(3/3) El loop mai ha estat la part difícil — els guardrails sí

Fer que un model percebi, raoni, planifiqui, actuï i observi en cicle ja és fàcil avui dia. Qualsevol framework et dona aquest loop en quatre línies. La part difícil —la que cap framework fa per tu— és tot el que evita que el loop se't mengi els diners, les dades de producció, o totes dues coses, sense fer soroll.

A la primera part deia que la fallada real d'AutoGPT, el març de 2023, no va ser un model feble —va ser la condició d'aturada que hi faltava, i el sector ha après aquesta lliçó a trossos des d'aleshores, una factura d'API descontrolada cada cop. Tres anys després, la mecànica del loop és un problema resolt, publicat i mesurat amb benchmarks. El que separa una demo d'una cosa que deixaries tocar producció no és un model més intel·ligent dins del loop —és la disciplina que l'envolta. En diré loop engineering: és una llista curta i concreta de guardrails, i la majoria d'incidents es remunten a un d'ells que s'ha saltat.

Un límit d'iteracions que dispara passi el que passi digui el model

El primer guardrail és el més bàsic i el que falta més sovint: un màxim dur de quants cicles pot córrer un loop, imposat des de fora del model, que dispara encara que la sortida del propi model insisteixi que li queda un pas per acabar. Sona massa obvi per escriure'l fins que recordes que AutoGPT es va llançar sense això —l'eina que va fer d'«agèntic» una paraula d'ús corrent en enginyeria no tenia un sostre dur sobre el seu propi loop, i usuaris el trobaven regularment encara corrent, i encara facturant, molt més enllà del punt on la tasca tenia cap possibilitat d'acabar bé. Un model a qui preguntes «ja has acabat» sovint dirà que no quan hauria de dir que sí, i que sí quan hauria de dir que no; un límit que no li demana l'opinió és la solució.

Un sostre de pressupost, perquè els tokens són la unitat que s'acaba

La segona part explicava per què l'arquitectura és una corba de cost —un sistema multi-agent pot córrer a uns 15 cops els tokens d'una simple interacció de xat, segons les xifres que la mateixa Anthropic ha publicat sobre el seu sistema de recerca. Un loop construït sense un sostre de pressupost explícit no falla fent soroll quan arriba a aquest múltiple; falla com una factura, dies després, quan algú la llegeix. La solució és avorrida i innegociable: un sostre de tokens o de diners imposat a la capa d'infraestructura, independent de la pròpia comptabilitat del loop, perquè un loop que ja s'està portant malament és l'últim a qui voldries fer responsable de vigilar la seva pròpia despesa.

Detecció per a la fallada que sembla que no passa res

Els límits d'iteracions i els sostres de pressupost atrapen un loop que fa massa. Una fallada més silenciosa és un loop que no fa res de nou —repetint el mateix moviment improductiu, rellegint el mateix fitxer, reintentant la mateixa crida que falla, sense avançar de manera mesurable cap a l'objectiu. Aquest cas necessita la seva pròpia comprovació: compara l'estat entre iteracions, i si res canvia de manera significativa durant N cicles seguits, atura't i marca-ho en lloc de deixar que el límit ho atrapi eventualment després d'haver cremat tot el pressupost en un loop que ja estava encallat tres iteracions abans.

El «context rot» ja és una fallada de producció amb nom i article propi

Hi ha una segona versió, més subtil, d'«encallat»: un loop que encara produeix sortida nova a cada cicle, però la sortida empitjora a mesura que creix la transcripció, perquè el context acumulat del propi model degrada el seu raonament. L'informe de Chroma Research del juliol de 2025, «Context Rot: How Increasing Input Tokens Impacts LLM Performance» (Hong, Troynikov i Huber), va avaluar divuit models de primera línia i va trobar que la precisió es degradava de manera no uniforme a mesura que creixia la mida de l'entrada —molt abans d'arribar al límit de context declarat d'un model—, amb una troballa concreta i contraintuïtiva: els models rendien pitjor amb documents llargs lògicament coherents que amb la mateixa longitud de text barrejat i incoherent. Un loop de llarga durada va afegint contingut a la seva pròpia transcripció per construcció, cosa que vol dir que cada cicle extra grava, sense que ningú s'ho miri, exactament el recurs que l'article mostra que es degrada. Un loop que mai retalla ni reinicia el seu context es va gastant la seva pròpia qualitat de raonament, cicle a cicle, algú hi estigui atent o no.

Una resposta deliberadament brusca a aquest problema val la pena anomenar-la perquè inverteix l'instint de guardar més context, no menys: la tècnica «Ralph Wiggum» de Geoffrey Huntley (ghuntley.com, maig de 2025) fa córrer un agent de codi en un loop de bash contra un fitxer de tasca persistent, però reinicia la finestra de context del model a cada iteració —res passa d'una transcripció a l'altra. L'estat sobreviu al sistema de fitxers i a l'historial de git, fora del model del tot. És una resposta a cop de força al context rot: si una transcripció llarga és el que et degrada el raonament en silenci, no en guardis cap de llarga —guarda l'estat durador en algun lloc que no es degradi, i deixa que el model comenci cada cicle de zero.

Orientar-se, no només observar, abans del pas següent

El cicle percebre-raonar-planificar-actuar-observar de la primera part té un cosí més vell que val la pena manllevar: el loop OODA de John Boyd —Observar, Orientar, Decidir, Actuar—, que va desenvolupar al llarg dels anys setanta i va formalitzar en sessions com «Patterns of Conflict» als anys vuitanta, pensat originalment per explicar per què un pilot de caça podia decidir més ràpid que un altre en combat. El detall que la majoria d'adaptacions de l'OODA al software deixen de banda és el pas d'orientar, diferent de simplement observar: és l'acte explícit de contrastar una observació nova amb el model que ja tens de la situació, abans de decidir què significa. Un loop agèntic que salta directament d'«observar la sortida de l'eina» a «decidir la següent acció» es salta exactament aquest pas, i és normalment on falla el loop que descrivia a la primera part —el que raona endavant a partir d'una imatge del món vella o incorrecta. Orientar-se és el guardrail que atrapa una mala observació abans que es converteixi en una decisió pitjor, no després.

Un punt de control abans de qualsevol cosa irreversible, que un humà ha de superar de debò

Cada guardrail anterior tracta de mantenir acotat el comportament del propi loop. Aquest últim tracta del que el loop pot fer al món sense preguntar primer. Esborrar dades, enviar un correu, fer push a una branca compartida, gastar diners reals fora d'un pressupost aïllat —accions com aquestes necessiten un punt de control humà explícit que el loop no pugui esquivar, no un flag de configuració que pugui raonar per superar si decideix que la situació ho justifica. Els altres guardrails acoten quant de temps i quant gasta un loop; aquest acota què li està permès fer mentre corre, i és el que converteix un loop descontrolat en un error car en comptes d'un error irrecuperable, si hi falta.

Sí, cada un d'aquests guardrails et costa velocitat

L'objecció honesta a tots sis és que frenen el loop —un límit d'iteracions vol dir que s'atura abans que potser hagués acabat tot sol, un punt de control humà vol dir una pausa real en lloc d'execució sense supervisió, un pas d'orientar-se vol dir un pas extra abans de cada decisió en lloc d'anar directe a la següent acció. És cert, i no és un defecte a optimitzar quan et fiïs més del sistema. Tot el valor d'un loop sense supervisió és que ningú el vigila convertint tokens en accions en temps real; tot el risc és exactament el mateix. Cada guardrail d'aquí intercanvia una part d'aquesta velocitat sense supervisió per la capacitat de deixar-lo córrer sense mirar cada cicle —que és el punt real de construir un loop, no un impost que li poses.

El que posaria en marxa abans de deixar córrer qualsevol loop

1. Un límit dur d'iteracions, imposat des de fora del model, que dispara passi el que passi digui la seva pròpia sortida.
2. Un sostre de pressupost —tokens o diners— imposat a la capa d'infraestructura, no dins la comptabilitat del propi loop.
3. Detecció de no-progrés que compara l'estat entre cicles i marca un encallament abans que el límit ho atrapi eventualment.
4. Una estratègia de context —retallar, resumir, o reiniciar com fa Ralph— perquè la qualitat del raonament no es degradi en silenci a mesura que creix la transcripció.
5. Un pas d'orientar-se explícit que contrasta cada observació nova amb el model que el loop ja té de la situació abans de decidir la següent acció.
6. Un punt de control humà per a qualsevol cosa irreversible, que el loop no pugui esquivar amb raonament.

El loop és el 20% fàcil; això és l'altre 80%

Cap d'aquests sis guardrails necessita un model més intel·ligent. Necessiten la mateixa disciplina que ha mantingut vius els sistemes de producció des de molt abans que «agèntic» fos una paraula que fes servir ningú: saber quan aturar-se, saber què costa una cosa, adonar-se quan s'encalla, i no deixar-lo mai fer alguna cosa que no puguis desfer sense preguntar primer. Aquest és el fil que travessa tota la sèrie —un trigger i un objectiu verificable a la primera part, una arquitectura triada per la forma real de la tasca a la segona, i els guardrails d'aquí que fan que tot plegat sigui segur de deixar córrer. Encerta els tres, i un loop es guanya el seu lloc sense que l'hagis de vigilar. Salta-te'n un, i tens el problema d'AutoGPT amb un model millor enganxat a sobre.

Si estàs construint un d'aquests sistemes i vols una segona opinió sobre on haurien d'anar els guardrails, contacta'ns.