(1/3) Només dues coses fan que un loop sigui agèntic

«Agèntic» s'ha convertit en la paraula més sobrecarregada del software, i gairebé ningú que la faci servir sap dir-te quines dues coses fan que un loop ho sigui de debò.

Programo des de finals dels noranta, i la major part d'aquest temps l'he passat mantenint sistemes que desperten algú a les 3 de la matinada quan es comporten malament. Així que quan alguna cosa s'executa sola en loop —decidint què fer a continuació sense que jo escrigui res entremig— la primera pregunta mai no és «és prou intel·ligent?». És «quan s'atura, i com sé que s'ha aturat pel motiu correcte?».

Aquesta pregunta acaba ordenant tot el camp. El marxandatge barreja dues coses ben diferents: una interfície de xat que respon educadament, i un sistema que continua actuant després que tu hagis deixat de mirar. Només la segona és un loop, i el que el fa agèntic no són les bones maneres ni un avatar simpàtic —són dues peces d'enginyeria. Un trigger que l'engega sense que una persona escrigui un prompt nou cada cop. I un objectiu que algú diferent del model pugui verificar, perquè el loop tingui un motiu real per aturar-se, en comptes de l'opinió d'un model que diu que ja ha acabat.

Un loop necessita un trigger, no una finestra de xat

Una interfície de xat és petició-resposta: tu preguntes, respon, espera. Un loop agèntic arrenca d'una altra cosa —un esdeveniment (arriba un tiquet, dispara un webhook), una programació (cada nit a les 2), o una persona que li passa una tasca i se'n va (arregla aquest test que falla). La diferència importa perquè canvia qui hi està atent. En una finestra de xat, llegeixes cada resposta abans que passi la següent. En un loop, per disseny, ningú ho fa —aquest és precisament el motiu de construir-ne un. Cosa que vol dir que el loop ha de portar el seu propi criteri sobre si ha acabat, perquè tu no hi ets per subministrar-l'hi torn a torn.

Els tres tipus de trigger, a més, no són intercanviables. Un trigger basat en esdeveniments hereta els problemes de fiabilitat de la cua o el webhook que l'alimenta —esdeveniments duplicats, entregues fora d'ordre, un reintent que dispara el mateix loop dues vegades amb la mateixa entrada. Un trigger programat hereta el problema contrari: s'executa hi hagi feina o no, així que el primer pas dins del loop sol haver de ser «hi ha realment alguna cosa a fer aquí», o has construït un no-operation car que corre cada nit per sempre. El traspàs humà és el cas més indulgent, perquè una persona ha triat el moment —però també és el que la majoria de demos fan servir per defecte, cosa que amaga quanta responsabilitat de trigger porten realment els altres dos tipus.

L'objectiu l'ha de poder verificar algú diferent del model que ha fet la feina

Aquesta és la peça que la majoria de demos «agèntiques» es salten. Si l'única prova que una tasca ha funcionat és el mateix model dient «fet», no tens una condició d'aturada —tens l'opinió d'un model, i els models s'equivoquen sovint sobre la seva pròpia feina, exactament de les maneres que t'esperaries: se salten casos límit, marquen com a verd un build trencat, donen per acabada una migració a mig fer. Un objectiu verificable el comprova alguna cosa externa al raonament que l'ha produït —un test que passa o falla, un esquema que valida, un diff que revisa una persona o un segon model. On aquesta comprovació hi falta, el loop no té un objectiu. Té una sensació amb un botó d'aturada que ningú està obligat a prémer.

Percebre, raonar, planificar, actuar, observar: la forma que hi ha sota tots aquests sistemes

Un cop tens un trigger i un objectiu verificable, el loop en si segueix una forma fixa: percebre l'estat actual (llegir el fitxer, l'error, el tiquet), raonar sobre què implica, planificar el pas següent, actuar, observar el resultat, i repetir fins que la comprovació de l'objectiu passi o es toqui un límit. El que és nou no és la construcció del loop —fa dècades que programem while (!fet). El que és nou és que el model raona sobre estat no estructurat entre accions, en lloc de seguir un guió fix escrit per endavant.

Aquest moviment concret —intercalar un rastre de raonament amb cada acció, en comptes de comprometre's amb un pla per endavant i executar-lo a cegues— és el que va formalitzar ReAct. L'article de Yao et al. de 2022 (publicat a ICLR 2023) va mostrar que deixar que un model generi un rastre de raonament curt abans de cada acció, en lloc d'actuar directament des del prompt, produïa una millora absoluta de la taxa d'èxit del 34% a ALFWorld i del 10% a WebShop respecte a mètodes previs d'imitació i de reforç —fent servir només un o dos exemples al prompt. El mecanisme és el que compta: el rastre de raonament permet al model adonar-se, a mig camí, que la seva última acció no ha fet el que esperava, i corregir el rumb, en comptes de comprometre's amb un pla estàtic i executar-lo fins al fracàs.

El pas d'observar és el que la majoria d'implementacions primerenques es queden curtes. És temptador tractar «actuar» com el final del cicle i alimentar el següent raonament amb el que hagi tornat l'acció, sense filtrar. Però una crida a una eina pot fallar en silenci —un script que retorna 0 sense haver fet res, una API que torna una llista buida en lloc d'un error— i si el loop no comprova explícitament què ha passat de veritat contra el que esperava que passés, raonarà endavant partint d'una premissa falsa. Bona part del que sembla «el model és curt» en un loop que es porta malament és això: ningú ha construït un pas d'observació real, així que el loop raona sobre una imatge del món que és vella o incorrecta.

Ja ho hem vist abans: la viralitat no és un objectiu verificable

AutoGPT es va llançar el març de 2023 i es va convertir en un dels repositoris de creixement més ràpid de la història de GitHub, amb xifres que apunten a més de 100.000 estrelles en poques setmanes. També es va convertir en l'exemple d'advertència més clar del camp, per un motiu que encaixa exactament amb els dos requisits d'abans: tenia triggers i tenia ambició, però no tenia de manera fiable un objectiu que res fora del model pogués comprovar. Usuaris van reportar que s'entestava en loops indefinits, cremant pressupost d'API perseguint una tasca que ja havia acabat efectivament, o desviant-se de l'encàrrec original del tot. El diagnòstic d'Andrej Karpathy sobre agents construïts així va ser directe: una finestra de context finita els porta a «sortir-se dels rails». L'Avram Piltch, de Tom's Hardware, ho va dir més esmolat en la seva ressenya de l'abril de 2023: AutoGPT podia ser «massa autònom per ser útil». La distància entre AutoGPT i ReAct és reveladora: l'un era una demo viral amb trigger i sense aturada verificable; l'altre era un article avorrit i mesurat amb benchmarks que havia resolt el problema d'enginyeria real sis mesos abans, amb una fracció de l'atenció.

Sí, mecànicament, és un while loop

Concedeixo l'objecció òbvia, perquè és certa fins on arriba: treu-hi la terminologia i un loop agèntic és un while al voltant d'una crida a un model. No hi ha màgia amagada al flux de control. El que canvia és qui calcula la condició i el pas següent. En un programa normal, els havies escrit tu per endavant. Aquí, un model llegeix estat no estructurat —logs, un diff, un fitxer a mig escriure, un missatge d'error— i decideix tant què fer a continuació com, si ho has construït bé, si ja ha acabat. Això és un salt de capacitat real. I és exactament per això que el requisit de verificació d'abans no és opcional: la mateixa flexibilitat que permet al model gestionar un cas que no havies previst és la que li permet convèncer-se que una cosa trencada està bé.

Abans de dir que alguna cosa és un loop, comprovo quatre coses

1. Què l'engega, dit explícitament —esdeveniment, programació o traspàs humà. Si ningú sap dir el trigger, algú s'està planificant per fer de cangur d'un script improvisat.
2. Un objectiu definit com una comprovació externa, no com una pregunta que li faries al model sobre la seva pròpia feina. Un test, un validador, un diff que revisa algú altre.
3. Una aturada dura independent del model —un nombre màxim d'iteracions o un límit de pressupost que dispara encara que el model insisteixi que gairebé ha acabat. És el que li faltava a AutoGPT.
4. Un rastre visible de què ha fet i per què, a cada pas, perquè un error sigui una sessió de debugging i no un misteri.

La pregunta d'arquitectura ve ara

Res de tot això et diu quants models haurien de fer el raonament, ni si haurien de córrer en paral·lel, en seqüència, o amb un supervisor llegint la seva feina —això és una decisió a part, amb la seva pròpia corba de cost, i és el tema de la segona part d'aquesta sèrie. Però comença aquí: un trigger, i un objectiu que algú diferent del model pugui comprovar. Tot el que la gent anomena «agèntic» i es salta un dels dos és una demo, no un sistema que voldries deixar corrent sense supervisió.

Si estàs construint un d'aquests sistemes i vols parlar de com encaixa en un stack de producció, contacta'ns.