Què és un AI agent: cinc tipus clàssics, dues definicions rivals

L’exemple més antic del camp és una aspiradora en un món de dues caselles, A i B, cadascuna neta o bruta.¹ Sobreviu a tots els manuals perquè és el món més petit en què un agent pot estar encertat o equivocat.

El percept és una parella — on soc, i si aquí està brut — i les accions són SUCK, LEFT i RIGHT. Tot el programa és una línia.

type Percept = { dirty: boolean; where?: "A" | "B" };
type Action = "SUCK" | "LEFT" | "RIGHT";

const textbook = (p: Percept): Action =>
  p.dirty ? "SUCK" : p.where === "A" ? "RIGHT" : "LEFT";   

Executa’l contra totes les configuracions inicials del món de dues caselles:

A dirty, B dirty, start A    -> steps=3 clean=true
A clean, B dirty, start A    -> steps=2 clean=true
A dirty, B clean, start B    -> steps=2 clean=true

Això és un agent reflex simple: actua només sobre el percept actual, sense memòria de res anterior. No és una categoria de joguina — un termòstat n’és un, i també ho és una sola crida a un model de llenguatge sense cap conversa adjunta.

Ara trenca’l com ho fa la realitat. Un robot aspirador real té un sensor de brutícia i un para-xocs, no una casella etiquetada A sota la catifa. Treu la ubicació del percept i no canviïs res més:

const dirtOnly = (p: Percept): Action => (p.dirty ? "SUCK" : "RIGHT");

A dirty, B dirty, start A    -> steps=3   clean=true   still dirty=0
      t=0 at=A percept={dirty:true}  -> SUCK
      t=1 at=A percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:true}  -> SUCK

A dirty, B clean, start B    -> steps=500 clean=false  still dirty=1
      t=0 at=B percept={dirty:false} -> RIGHT
      t=1 at=B percept={dirty:false} -> RIGHT
      t=2 at=B percept={dirty:false} -> RIGHT
      t=3 at=B percept={dirty:false} -> RIGHT

El mateix programa, dues caselles. Des d’un estat inicial acaba en tres passos; des d’un altre s’estavella contra la paret de la dreta cinc-centes vegades i continuaria fins que se li acabés la bateria. No pot percebre la diferència entre les dues situacions, de manera que no pot actuar-hi de manera diferent. Russell i Norvig formulen el resultat general en una línia: els bucles infinits sovint són inevitables per als agents reflex simples en entorns parcialment observables.¹

Hi ha una solució que costa una línia i cap memòria, i val la pena mesurar-la abans de recórrer a res més sofisticat.

let seed = 12345;
const rnd = () => ((seed = (seed * 1103515245 + 12345) & 0x7fffffff) / 0x7fffffff);

const coin = (p: Percept): Action => (p.dirty ? "SUCK" : rnd() < 0.5 ? "LEFT" : "RIGHT");  

Dues mil execucions d’un passadís tot brut en tres mides, amb un únic generador amb seed durant tota la prova:

La randomització elimina completament el bucle. També costa: vuit habitacions necessiten quinze moviments si saps què fas, i aquest agent en fa 68,7 de mitjana i una vegada en va necessitar 306. Aquest és tot el capítol en miniatura. Cada capacitat que afegim compra correcció en un cas que l’agent anterior no podia gestionar, i la cobra en una moneda que primer has de posar-li nom.

Un agent percep el seu entorn mitjançant sensors i actua mitjançant actuadors. El programa de l’agent és la funció que va de percepts a accions — cada llistat anterior n’és un. La seqüència de percepts és tot el que s’ha percebut fins ara, i un agent reflex simple ho ignora tot excepte l’últim element.

Racionalitat és la paraula que la majoria d’articles entenen malament, i entendre-la bé fa que la resta d’aquest capítol sigui útil. Un agent no és racional o irracional en si mateix. Russell i Norvig defineixen un agent racional com aquell que, per a cada possible seqüència de percepts, selecciona l’acció que s’espera que maximitzi la seva mesura de rendiment, donada l’evidència d’aquesta seqüència i qualsevol coneixement incorporat que tingui.¹ La mesura de rendiment no és dins de l’agent: pertany al dissenyador, i la racionalitat només es defineix en relació amb ella.

La especificació s’escriu convencionalment com quatre coses, PEAS: mesura de rendiment, entorn, actuadors, sensors.

Fixa’t quina fila és l’estranya. Gairebé tots els equips que construeixen agents el 2026 escriuen E, A i S — els schemas de les eines, les integracions, el format dels missatges — perquè el codi no s’executarà sense això. Gairebé ningú escriu P. Sense això, «el nostre agent ho està fent bé» no té cap significat que ningú pugui comprovar, i «racional» no es pot aplicar al sistema en absolut, només a una demostració. El Capítol 29 tracta de convertir P en un número, i per això existeix.

    ┌───────────────────────── the environment ─────────────────────────┐
    │                                                                   │
    │   ┌──────────────────────── the agent ─────────────────────┐      │
    │   │                                                        │      │
 ───┼──►│  sensors  ──►  the agent program  ──►  actuators  ─────┼──────┼──►
percept │                                                        │    action
    │   └────────────────────────────────────────────────────────┘      │
    └───────────────────────────────────────────────────────────────────┘
                                   ▲
              the performance measure lives out here, in the head of
              whoever built the thing, and the agent cannot change it

Els entorns de tasca es classifiquen encara més al llarg de set eixos, cinc dels quals decideixen gran part de la dificultat aquí: completament o parcialment observable, determinista o no, episòdic o seqüencial, estàtic o dinàmic, conegut o desconegut.¹ Un agent que parla amb eines reals a través d’una xarxa real és al racó difícil de tots cinc — no determinista fins i tot a temperature zero (Capítol 17) i, el que se subestima, desconegut, perquè no tens cap model fiable del que fan les teves pròpies eines al món. Per això el bucle del Capítol 23 necessita més gestió d’errors que planificació.

Els terres reals no són unidimensionals, així que elevem el món a un plànol. Els coixinets són parets, els asteriscos són brutícia, i el robot comença a la cambra central:

        col  0 1 2 3 4 5 6
      row 0  * . . # . . *
      row 1  . # . # . # .
      row 2  . # . S . # .        S = the robot starts here
      row 3  . # . # . # .
      row 4  * . . # . . *

La millora òbvia és la memòria. L’agent manté un mapa: cada casella on ha estat i cada casella on s’ha activat el para-xocs. La seva regla és caminar cap a una casella adjacent que no hagi visitat — dreta, després avall, després esquerra, després amunt — i recular quan tot el que té al voltant ja és conegut. Això és un agent reflex basat en model: manté estat intern a partir de l’historial de percepts, de manera que pot actuar sobre allò que no pot veure en aquell moment.

És una millora real, i continua no sent suficient:

5,000 steps allowed -> steps=5,000  distinct squares visited=13/25  still dirty=2/4

Cinc mil moviments, mig terra sense veure. El mapa és correcte i les regles són correctes. El que l’agent no pot fer és utilitzar el mapa per anar a algun lloc: les seves regles només responen «a quin dels meus quatre veïns he d’entrar», de manera que, un cop s’acaben les caselles no visitades al seu costat, no té cap manera d’expressar el pensament hi ha una casella no visitada a vuit moviments i m’agradaria ser-hi. Sap on és. No sap on vol ser.

Un agent basat en objectius conserva, a sobre del seu model del món, una descripció de la situació que vol provocar, i tria accions cercant sobre seqüències d’accions fins que en troba una que acaba allà. Els objectius converteixen la selecció d’accions d’una consulta en una cerca.

L’objectiu és «no queda cap casella bruta». La cerca és un recorregut en amplada fins a la casella bruta més propera, i el camí que retorna és el pla.

goal-based (fewest moves)      -> moves=27  battery=52  still dirty=0
      from 2,3 -> 4,6 via 5 moves:  2,3 2,4 3,4 4,4 4,5 4,6
      from 4,6 -> 0,6 via 4 moves:  4,6 3,6 2,6 1,6 0,6
      from 0,6 -> 4,0 via 10 moves: 0,6 0,5 0,4 1,4 2,4 2,3 2,2 3,2 4,2 4,1 4,0
      from 4,0 -> 0,0 via 4 moves:  4,0 3,0 2,0 1,0 0,0

Vint-i-set moviments, terra net. Però mira la columna de bateria i l’últim tram del pla. La columna 0 té catifa: travessar una casella amb catifa costa sis unitats de bateria, una casella de rajola en costa una. L’agent va tornar a casa pujant per la columna 0 perquè són quatre moviments en lloc de vuit, i aquests quatre moviments sobre catifa costen 24, mentre que la volta de vuit moviments n’hauria costat 13.

No pot fer res més. Un objectiu és una prova binària: el terra és net o no ho és. Cada pla que acaba amb el terra net el satisfà igualment, de manera que quan diversos funcionen l’agent no té res per triar entre ells. Preferir un èxit a un altre requereix un número sobre els resultats, i aquest número és una funció d’utilitat. Un agent que la maximitza és un agent basat en utilitat.

El canvi al codi és un terme dins de la cerca. La cerca en amplada compta moviments; fes que compti cost i tens l’algorisme de Dijkstra i un agent diferent:

const nd = dist.get(k)! + (byCost ? cell.cost : 1);   // <- the entire difference

goal-based    (fewest moves)   -> moves=27  battery=52  still dirty=0
utility-based (cheapest route) -> moves=31  battery=41  still dirty=0
      from 4,0 -> 0,0 via 8 moves: 4,0 4,1 4,2 3,2 2,2 1,2 0,2 0,1 0,0

Quatre moviments extra, onze unitats de bateria menys: un vint-i-u per cent més barat. Mateix objectiu, mateix mapa, mateix codi excepte per un terme. Els dos agents només difereixen en què intenten fer bé, i prenen rutes diferents per tornar a casa.

Aquest també és el primer punt en què l’agent necessita una cosa que no pot produir. Algú ha de decidir quant val una unitat de bateria en relació amb un moviment. La utilitat és la mesura de rendiment escrita en una forma amb què l’agent pot calcular, i escriure-la és feina del dissenyador. Quan la gent diu que un agent «ha optimitzat la cosa equivocada», gairebé mai vol dir un bug. Vol dir que aquesta línia es va escriure sense prou cura.

Ara deixa que la brutícia torni. Quatre habitacions es tornen a embrutar a quatre ritmes diferents, i a l’agent no se li diu mai quins són. Visita una habitació per tick i només veu aquella habitació. La mesura de rendiment són els room-ticks passats bruts durant 4.000 ticks — com més baix, millor.

Un agent d’aprenentatge, en la descomposició del manual, és qualsevol dels anteriors més tres parts: un element d’aprenentatge que canvia l’agent, un crític que li diu com ho està fent l’agent respecte d’un estàndard de rendiment fix, i un generador de problemes que proposa accions que val la pena provar pel que ensenyarien.¹ Tres polítiques en el mateix entorn. La primera no aprèn; la segona i la tercera aprenen el mateix i ho utilitzen de manera diferent.

Les taxes ocultes eren 0,35 per a la cuina, 0,05 per al rebedor, 0,02 per a l’estudi i 0,01 per a les golfes — i l’aprenent A les va trobar. Va identificar correctament la cuina com l’habitació més bruta de la casa, i després va anar a la cuina a cada tick durant la resta de la simulació mentre les altres tres quedaven brutes per sempre. És cinc vegades pitjor que no aprendre gens, i no està espatllat.

La lliçó és la de la secció d’utilitat. L’aprenent A va maximitzar «probabilitat que l’habitació que estic a punt de visitar estigui bruta». La mesura de rendiment era «room-ticks passats bruts». Números diferents; el segon és el que puntuava el crític, i ningú no ho va dir a l’agent. L’aprenent B multiplica la mateixa taxa apresa pel temps des de l’última visita — la brutícia que espera trobar, en lloc de la probabilitat de trobar-ne alguna — i supera la patrulla de la qual partia.

Un detall d’implementació va decidir el resultat. En la primera versió de l’aprenent B, una habitació on no havia aparegut brutícia en tres visites rebia una taxa exactament zero — i zero per qualsevol cosa és zero, així que no es visitava mai més i l’estimació no es podia corregir mai. Suavitzar la fracció, èxits més u sobre assajos més dos, va convertir 11.895 en 1.576. «Encara no observat» i «mesurat i ha sortit zero» són afirmacions diferents, i un sistema que les emmagatzema al mateix camp pren decisions que no pot desfer.

  1  simple reflex    percept ────────────────────────────────► rules ────► action
  2  model-based      percept ──► [state] ──────────────────► rules ────► action
  3  goal-based       percept ──► [state] ──► [goal] ──────► search ───► action
  4  utility-based    percept ──► [state] ──► [goal] ──► [U] ──► argmax ► action
  5  learning         all of the above, plus [critic] ──► changes the parts above

Cadascun dels cinc és avui en producció amb un altre nom.

Dues files són més properes que una analogia, d’una manera que costa diners.

El chat és un agent reflex basat en model el model del qual no és intern. Al manual, l’estat és una variable dins del programa de l’agent. En un chat és la transcripció: viu al teu costat, es reenvia sencera en cada crida i es reconstrueix des de zero dins del model cada vegada. Aquesta és la factura quadràtica del Capítol 16, i és el mateix objecte que el manual dibuixava com una caixa etiquetada «estat». Aquesta és la diferència, mesurada en una pregunta de seguiment amb i sense els dos missatges anteriors:

with the transcript      prompt=67  "The current temperature in Lisbon, Portugal is 15°C."
without the transcript   prompt=29  "Lisbon is the capital of Portugal, not a city in Portugal."

El mateix model, les mateixes tres paraules d’input d’usuari, i el segon és el robot del passadís estavellant-se contra la paret. No hi havia eines en aquella execució, així que el 15 és inventat — però l’estat és el que fa que el seguiment signifiqui alguna cosa. El reconstrueixes cada vegada i en pagues 2,3× els input tokens en una conversa de dos torns. El Capítol 16 va mesurar fins on arriba aquest multiplicador al torn quaranta.

Reflexion és un agent d’aprenentatge que canvia el seu input en lloc del seu programa. En la descomposició del manual, l’element d’aprenentatge modifica l’element de rendiment. Reflexion deixa els weights intactes i escriu text reflexiu en un buffer episòdic que l’intent següent llegeix.³ L’element d’aprenentatge és un prompt, la memòria una fila de base de dades, l’element de rendiment un model congelat — i el diagrama és el del manual, sense canvis.

I aquest és el límit honest del mapatge. Els cinc tipus classifiquen el programa de l’agent. El 2026 aquest programa està partit pel mig: una part és el teu codi, una part és dins de weights que no has entrenat. Quan un model decideix tot sol cridar una eina, la prova d’objectiu és al teu programa o al model? La taxonomia no té resposta, perquè quan es va escriure no hi havia cap altre lloc on pogués ser — i aquesta pregunta és exactament on se separen les dues definicions modernes.

Les definicions són arguments sobre comportament, i són molt més fàcils de jutjar amb una traça al davant.

El bucle de sota envia la conversa a un model; si la resposta conté una tool call, executa l’eina, afegeix el resultat i ho envia tot de nou. S’executa contra un Qwen2.5-0.5B-Instruct local darrere d’un endpoint amb forma d’OpenAI en aquesta màquina — la costura del Capítol 14, així que al bucle no li importa ni sap què hi ha darrere del port.

const BASE = process.env.LLM_BASE_URL ?? "http://127.0.0.1:8799/v1";

async function loop(question: string, maxTurns = 6) {
  const messages: Msg[] = [
    { role: "system", content: SYSTEM },
    { role: "user", content: question },
  ];

  for (let turn = 1; turn <= maxTurns; turn++) {
    const reply = await call(messages, TOOLS);
    const calls = reply.choices[0].message.tool_calls ?? [];
    messages.push(reply.choices[0].message);

    if (!calls.length) return messages;                      

    for (const c of calls) {
      const out = runTool(c.function.name, JSON.parse(c.function.arguments));
      messages.push({ role: "tool", name: c.function.name, content: out });
    }
  }
  throw new Error("turn cap reached");                       
}

Dues línies carreguen tota la idea, i totes dues estan marcades; la resta és comptabilitat. Els tres comportaments són visibles en una sola execució. Quan se li pregunta una cosa que pot fer sol, el model respon. Quan se li pregunta una cosa que no pot fer, crida:

=== a question the model cannot answer, one tool available
  turn 1  prompt= 187  out= 21  finish=tool_calls  CALL get_temperature({"city": "Oslo"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
  turn 2  prompt= 238  out= 12  finish=stop        TEXT "The current temperature in Oslo is 4
                                                        degrees Celsius."
  => model calls=2  prompt tokens=425  output=33  wall=6,257 ms
  => stopped by: the model produced text instead of a call

I s’atura — el tercer comportament, i el més fàcil de passar per alt, perquè sembla que no passi res. El bucle acaba perquè el torn 2 ha tornat sense cap tool call. Ningú no ho ha decidit; ho ha decidit el model, emetent prosa. La condició de terminació d’aquest programa és el signe d’una absència.

Dues execucions més mereixen l’espai. Quan se li demana comparar dues ciutats, el model emet totes dues tool calls en un sol torn, rep les dues lectures i s’equivoca en la comparació:

  turn 1  prompt= 188  out= 43  finish=tool_calls  CALL get_temperature({"city": "Oslo"}),
                                                        get_temperature({"city": "Lisbon"})
          tool  get_temperature -> {"city":"Oslo","celsius":4}
          tool  get_temperature -> {"city":"Lisbon","celsius":19}
  turn 2  prompt= 284  out= 13  finish=stop        TEXT "Oslo is currently warmer than Lisbon
                                                        at 4°C."

Les eines han funcionat. La crida paral·lela ha funcionat. El bucle ha funcionat. La resposta és falsa, amb tots dos números correctes asseguts a la transcripció. Embolicar un model en un bucle no fa que raoni; dona a un model que s’equivoca la capacitat d’actuar sobre el seu error — que és el Capítol 30 per avançat, i la meitat del Capítol 29.

Ara elimina el return marcat i deixa que el bucle s’executi fins al límit. Mateixa pregunta, mateix model:

  turn 1  prompt= 187  out= 21  CALL get_temperature({"city": "Oslo"})
  turn 2  prompt= 238  out= 12  TEXT "The current temperature in Oslo is 4 degrees Celsius."
  turn 3  prompt= 261  out= 30  TEXT "Could you please specify the exact location you're..."
  turn 4  prompt= 302  out= 14  TEXT "Sure! Could you tell me which city you're interested in?"
  turn 5  prompt= 327  out= 35  TEXT "I'm sorry, but I need more details to provide an..."
  turn 6  prompt= 373  out= 12  TEXT "Which city would you like to know the temperature for?"
  => model calls=6  prompt tokens=1,688  output=124  wall=25,261 ms  stopped by: turn cap

Quatre vegades els input tokens, quatre vegades el temps de rellotge, i un final en què l’agent ha oblidat què se li havia preguntat i interroga l’usuari sobre una pregunta que ja havia contestat al torn u. La resposta correcta era a la pantalla al torn 2, i cada torn posterior ha empitjorat la transcripció.

Així doncs, un agent no és un bucle. És un bucle més una regla per sortir-ne, i aquest en té exactament una. El Capítol 23 en troba cinc, i mostra què es trenca quan en falta cadascuna.

Totes dues citades en lloc de parafrasejades, perquè és en les paràfrasis on es fabrica la confusió.

La primera definició posa el límit en qui controla el flux. Building effective agents d’Anthropic posa nom a l’ambigüitat i hi pren partit:

«A Anthropic, categoritzem totes aquestes variacions com a sistemes agentic, però tracem una distinció arquitectònica important entre workflows i agents: els workflows són sistemes en què els LLMs i les eines s’orquestren mitjançant camins de codi predefinits. Els agents, en canvi, són sistemes en què els LLMs dirigeixen dinàmicament els seus propis processos i l’ús d’eines, mantenint el control sobre com compleixen les tasques.»⁴

La prova és una pregunta sobre el teu codi font: qui ha triat el pas següent? Un switch al teu programa: workflow. El model: agent. El mateix document diu que els agents «normalment són només LLMs que utilitzen eines a partir de feedback ambiental en un bucle» — que és exactament el llistat anterior.

La segona definició posa el límit en la independència respecte de l’usuari. A practical guide to building agents d’OpenAI obre la seva pàgina definicional així:

«Mentre que el software convencional permet als usuaris simplificar i automatitzar workflows, els agents poden dur a terme els mateixos workflows en nom dels usuaris amb un alt grau d’independència. Els agents són sistemes que compleixen tasques de manera independent en nom teu.»⁵

Dues frases més tard, a la mateixa pàgina, exclou:

«Les aplicacions que integren LLMs però no els utilitzen per controlar l’execució del workflow — pensa en chatbots simples, LLMs d’un sol torn o classificadors de sentiment — no són agents.»⁵

Llegeix aquestes cites en ordre. Les frases inicials tracen la línia a la independència: aquesta cosa se’n va i acaba la feina sense mi? La quarta la traça al control de l’execució, que és exactament la línia d’Anthropic. Proves diferents, mateixa pàgina, i hi ha sistemes reals sobre els quals discrepen.

A sota hi ha una col·lisió de vocabulari, i provoca discussions en reunions reals. En el primer document un workflow és una arquitectura, i és allò que no és un agent. En el segon, un workflow és «una seqüència de passos que cal executar per assolir l’objectiu de l’usuari» — la feina en si, que tot agent té. «Hem substituït el workflow per un agent» és coherent segons la primera definició i gairebé sense sentit segons la segona.

Tres sistemes que existeixen el 2026, sota totes dues definicions.

Dos dels tres canvien de bàndol. Això no és un fracàs de cap dels dos documents. És un avís sobre una mena de reunió en què dues persones que estan completament d’acord sobre què fa un sistema passen una hora discrepant sobre com anomenar-lo.

Les definicions xoquen perquè cadascuna col·lapsa dues preguntes independents en una sola paraula. Separa-les i el desacord es converteix en una taula, que és més útil que un veredicte.

Cada definició discuteix una cel·la diferent, i les altres dues no estan en disputa. Així que quan l’etiqueta importa — en un contracte, una revisió de risc, un postmortem — les dues frases que val la pena escriure no són «és un agent», sinó qui ha triat el pas següent i qui estava mirant. Totes dues es poden respondre llegint codi, cap necessita la definició de ningú, i juntes porten totes les conseqüències que l’etiqueta pretenia condensar.

Res d’això és nou. Wooldridge i Jennings van revisar els sentits competidors d’«agent» el 1995;⁶ Franklin i Graesser van fer la pregunta d’aquest capítol el 1996, van reunir les definicions en circulació i van trobar que discrepaven.⁷ Un survey del 2023 encara defineix agents des dels primers principis — «entitats artificials que perceben el seu entorn, prenen decisions i fan accions»⁸ — perquè no existia cap definició moderna acordada per citar, i CoALA descriu parts en lloc de traçar cap límit.⁹ Trenta anys de refusar posar-se d’acord indiquen que la paraula fa més d’una feina.

Ara la conseqüència que arriba abans que la filosofia: la factura.

Cada mesura aquí té la mateixa forma. La crida única va costar 39 input tokens; la mateixa pregunta amb una eina va costar 420 en dues crides; el bucle sense la seva regla d’aturada va costar 1.688 en sis. El creixement és pitjor que lineal, perquè el torn n porta tots els torns anteriors amb ell: la columna de prompt d’aquesta execució de sis torns diu 187, 238, 261, 302, 327, 373. El Capítol 16 va derivar que el total és $\Theta(n^2)$ i va ajustar la corba en una conversa real. Un agent converteix cada tasca en aquesta conversa, tant si cap humà la veu com si no.

Si aquests recompte de tokens mesurats haguessin anat a un endpoint comercial amb les tarifes que el Capítol 16 va llegir el 6 de setembre de 2026 — 2,00 $ per milió d’input tokens i 12,00 $ per milió d’output tokens — les quatre execucions quedarien així:

La fila dos contra la fila u és el número que cal recordar. Set vegades i mitja el cost, per una resposta pitjor a una pregunta que el model ja sabia. No hi havia res mal configurat: existia una eina, així que el model la va utilitzar — i la troballa del Capítol 18, que el que fa mal és el preu d’un catàleg i no la seva precisió, té aquí la seva demostració més barata amb un catàleg d’una sola eina.

Per això la meitat útil de tots dos documents és la meitat sobre no construir això. El d’Anthropic és directe: troba la solució més simple possible i afegeix complexitat només quan calgui, cosa que «podria voler dir no construir sistemes agentic en absolut», perquè els sistemes agentic «intercanvien latència i cost per un millor rendiment de tasca» i «per a moltes aplicacions, optimitzar crides LLM úniques amb retrieval i exemples in-context sol ser suficient».⁴ El seu cas a favor d’un agent és estret: problemes oberts en què no pots predir el nombre de passos i no pots hardcode un camí, en un entorn en què confies, acceptant «costos més alts i el potencial d’errors compostos».⁴ La pantalla d’OpenAI n’és el reflex — judici complex, conjunts de regles impossibles de mantenir, dades no estructurades — i acaba igual: «altrament, pot ser suficient una solució determinista».⁵

Així doncs, en la taxonomia d’aquest capítol: un nombre fix de passos en un ordre fix és una pipeline, i anomenar-la agent no la farà més ràpida. Si el nombre de passos depèn del que trobis pel camí, vols un bucle — i compres aquesta flexibilitat amb N crides, una transcripció quadràtica i un sistema que pot equivocar-se N vegades en lloc d’una.

Ara tens la taxonomia, totes dues definicions modernes, els dos eixos que les fan compatibles, i un bucle curt que respon, crida i s’atura.

Aquest bucle té una sola manera d’acabar: el model deixa de demanar eines. El Capítol 23 el trenca expressament, set vegades, i cada trencament hi afegeix una peça. Una tasca impossible, i no acaba mai — un límit de torns. Una nit en execució, i arriba la factura — un pressupost en dòlars. Una eina que falla — un error sobre el qual el model pot actuar. La mateixa crida dues vegades — una clau d’idempotència. Un fitxer que no hauria d’haver tocat — una aprovació humana. Un reinici a mig camí — persistència de sessió. Una eina que triga tres minuts en silenci — progrés i cancel·lació. El que en surt és un harness, el fitxer sobre el qual s’executa la resta d’aquest curs.

Això deixa la pregunta sobre la qual tractava realment la diagonal disputada d’aquest capítol. Un bucle que decideix el seu propi pas següent ha de decidir quan aturar-se, i acabem de veure què passa quan no pot: sis torns, quatre vegades la factura, i un agent interrogant l’usuari sobre una pregunta que ja havia contestat. Aturar-se no és una sola condició. Quantes n’hi ha, i quina salta primer?

LLM Powered Autonomous Agents (2023) de Lilian Weng és la descomposició més coneguda d’un language agent en planificació, memòria i ús d’eines, i és la lectura següent adequada al costat dels dos documents de proveïdor; els seus tres components són els Capítols 23, 24 i 18 d’aquest curs en aquest ordre.

Cada número d’aquest capítol s’ha produït en aquesta màquina i no se n’ha estimat cap. El passadís, el plànol, els quatre agents que el recorren i les tres polítiques de patrulla són el TypeScript de més amunt, executat a Node 22; les xifres de l’agent randomitzat són mitjanes sobre 2.000 execucions amb seed cadascuna i les xifres de patrulla són execucions úniques amb seed de 4.000 ticks. Les traces del model provenen de Qwen2.5-0.5B-Instruct en float32 sobre CPU amb greedy decoding, servit per loopback per un petit endpoint local en Python que carrega els weights i parla amb la forma d’OpenAI chat-completions — la costura una altra vegada, amb els tensors al costat Python i el bucle al costat TypeScript — de manera que els recompte de tokens són els del tokenizer d’aquell model i les latències són les d’aquella màquina. Les úniques xifres preses d’un altre lloc són els dos preus de la taula de costos, que són les tarifes que el Capítol 16 va llegir a la pàgina de preus d’OpenAI el 6 de setembre de 2026, aplicades aquí a recompte de tokens mesurats localment com a il·lustració i no com a factura observada.