Els 4 Modes de Fallada dels Agents d'IA en Producció (i Com Mitigar-los)

La promesa i la realitat

La promesa dels agents és seductora: li dones a un LLM un objectiu i un grapat d’eines, i el deixes iterar en un bucle fins que decideix que ha acabat. Llegeix, raona, crida una eina, observa el resultat, torna a raonar. Sona a màgia.

La realitat en producció és menys romàntica. Aquest bucle és exactament on es cremen els diners i on l’estat es corromp. I la part més incòmoda: les fallades que veuràs no són problemes de qualitat del model. Un model més gran no les arregla. Són problemes del bucle de control — el mateix tipus de problema que fa dècades que resols amb watchdogs, circuit breakers i màquines d’estat, només que aplicat a un domini nou.

Quatre modes de fallada es repeteixen en qualsevol runtime agèntic, tant és el framework. Si construeixes sobre agents, te’ls trobaràs. La bona notícia és que cadascun té una mitigació coneguda i barata. Aquest post és el mapa.

Anatomia d’un torn

Abans de les fallades, el vocabulari. Un torn és un cicle: una invocació al LLM més l’execució de les eines que demani. Una tasca són molts torns encadenats fins a una condició de sortida. L’agent «viu» dins d’aquest bucle de torns.

Tot el que pot anar malament amb un bucle cau en tres categories: no acaba mai, acaba sense progressar, o acaba malament. Els quatre modes de fallada són variants concretes d’aquestes tres. Anem un a un.

Fallada 1: el bucle que no acaba mai

Símptoma. L’agent crida la mateixa eina amb els mateixos arguments una vegada i una altra. O alterna entre dues accions en un cicle A-B-A-B-A. O toca el mateix recurs quaranta vegades sense que res canviï. La factura de tokens puja en línia recta i no en surt cap resultat.

Per què passa. El LLM no té una memòria fiable de «això ja ho he provat i no ha funcionat». Un resultat d’eina lleugerament ambigu li fa reintentar el mateix. Un estat que no entén el deixa fent voltes. No és que el model sigui ximple: és que el bucle no té frens.

La mitigació. Un detector de bucles que inspeccioni l’historial recent de crides a eines. Tres patrons cobreixen la majoria de casos:

// Senyals de bucle sobre l'historial recent de tool-calls.
function detectLoop(history: ToolCall[]): LoopSignal | null {
  // Les tools de només lectura (read, list, status) s'EXCLOUEN:
  // repetir-les és legitim, no és un bucle.
  const actions = history.filter((c) => !c.tool.isReadOnly);

  // 1. Crides identiques consecutives (mateixa tool + mateixos args)
  if (lastNAreIdentical(actions, 3)) {
    return { kind: "identical", advice: "abort" };
  }

  // 2. El mateix objectiu tocat N vegades sense ni un canvi d'estat
  if (sameTargetWithoutWrite(actions, 4)) {
    return { kind: "target-repetition", advice: "abort" };
  }

  // 3. Cicle alternant A-B-A-B-A
  if (isAlternatingCycle(actions, 5)) {
    return { kind: "alternating", advice: "abort" };
  }

  return null;
}

El paràmetre que importa. El llindar N. Massa baix i cancel·les feina vàlida (un agent que reintenta dues vegades alguna cosa raonable). Massa alt i pagues milers de tokens abans de tallar. No hi ha un número universal: depèn de la classe d’eina. Comença conservador, mesura, i ajusta amb les dades reals dels teus bucles.

Fallada 2: el torn que es queda penjat

Símptoma. Un torn comença i no acaba mai. La crida al LLM es queda esperant, una eina bloqueja en una operació de xarxa sense timeout, un subprocés mor i el pare segueix esperant una resposta que no arribarà. L’«slot» de l’agent queda ocupat per sempre. En un sistema amb diversos agents en paral·lel, un grapat de torns penjats et consumeix tota la capacitat.

Per què passa. Timeouts del proveïdor del LLM, I/O sense cota, deadlocks, un procés fill que el sistema operatiu va matar per memòria i del qual ningú es va assabentar. Qualsevol cosa que pugui bloquejar, en producció, acaba bloquejant.

La mitigació. El patró clàssic del procés zombi, aplicat a torns: heartbeats més un watchdog. Cada torn emet un batec (un timestamp) mentre està viu. Un procés en segon pla escaneja periòdicament i, si troba un torn el darrer batec del qual és més vell que el llindar, el dóna per mort, allibera l’slot i opcionalment reencua la tasca.

Fallada 3: el torn que no fa res

Símptoma. L’agent produeix un paràgraf preciós explicant el que farà, o directament declara «la tasca està completa» — però crida zero eines. No ha passat res. L’estat està intacte. És especialment freqüent en rols de coordinació i amb models que rellisquen cap al mode conversa.

Per què passa. Els models instruct estan entrenats per ser eloqüents. Si no els forces la crida a funció, et tornen prosa. I hi ha una fallada més subtil i més perillosa: un model que creu que ha acabat però no ha tocat res.

La mitigació. Una porta d’execució (execution gate). Per als torns que se suposa que han d’actuar, exigeix com a mínim una crida a eina. Zero crides en un torn que havia d’executar alguna cosa equival a torn fallit — no acceptis la narració com a resultat. Els rols genuïnament conversacionals o de coordinació queden exempts.

Però la lliçó de fons és més gran que un gate. És la regla més important de tot el document:

A la pràctica això vol dir que la transició a «completat» la decideix el runtime després de comprovar efectes reals, no l’agent dient que ja està. Costa més d’implementar. És la diferència entre una demo i producció.

Fallada 4: l’error mal classificat

Símptoma. Alguna cosa falla. Un sistema ingenu fa una de tres coses, totes dolentes: reintenta per sempre, es rendeix al primer error, o tracta tots els errors igual. Però un parpelleig de xarxa transitori i un «no tens permís» exigeixen respostes oposades. Reintentar un error de permisos és cremar tokens; rendir-se davant d’un 5xx transitori és abandonar feina que hauria sortit bé al segon intent.

Per què passa. Els errors són heterogenis i el codi tendeix a tractar-los com una massa uniforme — un catch genèric que no distingeix.

La mitigació. Una taxonomia explícita d’errors connectada a una taula de polítiques. Cada tipus d’error té una fila: quants reintents, quin backoff, i quina acció terminal quan s’esgoten.

Tipus d’error	Reintents	Backoff	Acció en esgotar-se
Transitori (xarxa, 5xx)	3	exponencial	escalar a supervisor
Rate limit (429)	5	exponencial + jitter	escalar a supervisor
Entrada invàlida (4xx)	0	—	corregir l’entrada / abortar
Permisos / auth	0	—	escalar a un humà
Contracte / lògica	1	—	abortar
Desconegut	2	exponencial	escalar a un humà

Dues propietats fan que aquesta taula funcioni. Primera: és exhaustiva — tot error cau en alguna fila, i els desconeguts tenen una política conservadora per defecte (pocs reintents i després escalar). Segona, i crítica: l’acció en esgotar-se mai és «marcar com a completat en silenci». Quan s’esgoten els intents, escales o abortes. Mai fingeixes èxit. És el mateix principi de la Fallada 3, vist des de l’altre costat.

El fil conductor

Quan ja fa una estona que t’hi baralles, veus que les quatre fallades són la mateixa història explicada quatre vegades: l’agent no és l’autoritat sobre el seu propi progrés.

• El bucle infinit és l’agent creient que avança quan no avança.
• El torn penjat és l’agent sense donar senyals de vida i el sistema sense assabentar-se’n.
• El torn buit és l’agent afirmant acció on no n’hi va haver.
• L’error mal classificat és l’agent (o un catch mandrós) malinterpretant què significa una fallada.

En les quatre, la solució és la mateixa de fons: el runtime —no el model— és qui decideix quan parar, què compta com a viu, què compta com a acció i què significa un error. Tracta l’agent com un treballador capaç però poc fiable dins d’un arnès fiable. L’arnès és on viu la robustesa de producció.

Observabilitat: veure la fallada abans de pagar-la

No pots mitigar el que no veus. Els quatre modes de fallada són invisibles fins que arriba la factura o el tiquet de suport — tret que instrumentis el bucle.

La recomanació concreta: adopta les convencions semàntiques d’OpenTelemetry per a GenAI. Un span per torn amb atributs gen_ai.* (sistema, model, tokens d’entrada i sortida, motiu de finalització), i spans fill per cada crida a eina. A sobre, unes poques mètriques: torns executats, tokens consumits, latència del LLM, execucions d’eines, reintents i escalats.

Amb aquesta telemetria, les fallades deixen de ser invisibles:

• El bucle infinit apareix com un pic en la taxa de tokens per minut.
• El torn penjat és un span que s’obre i no es tanca mai.
• El torn buit és un torn el span del qual no té cap fill de tipus tool-call.
• L’error mal classificat és un pic de reintents sobre el mateix tipus d’error.

La checklist

Si t’emportes una sola cosa, que sigui aquesta llista. És el mínim viable per dur agents a producció sense ensurts:

• Detector de bucles (idèntics / alternants / mateix objectiu), eximint eines de només lectura.
• Heartbeat més watchdog per a torns penjats, i timeout explícit a tota crida externa.
• Execution gate: els torns d’acció exigeixen com a mínim una crida a eina; la narració mai compta com a èxit.
• Taxonomia d’errors amb taula de polítiques; l’acció en esgotar-se és escalar o abortar, mai fingir que s’ha completat.
• Mai auto-Done: la finalització es decideix per efectes verificables, no per la paraula de l’agent.
• Instrumentació OTel GenAI més una alerta sobre la taxa de tokens.

Preguntes freqüents

Conclusió

Cap d’aquestes quatre fallades s’arregla amb un model millor, perquè cap és una fallada d’intel·ligència: són fallades de bucle de control. I això, en realitat, són bones notícies. Vol dir que no estàs davant d’un problema nou i irresoluble, sinó davant de problemes vells i ben entesos —watchdogs, circuit breakers, màquines d’estat, taxonomies d’error— reaplicats a un domini que sembla nou però no ho és tant.

L’agent aporta la intel·ligència. Tu aportes l’arnès. La fiabilitat de producció no viu en el prompt: viu en el codi que envolta el bucle.