Quan els agents fallen: anatomia dels problemes en sistemes generatius

En els últims mesos, els agents generatius han passat de ser una curiositat tècnica a ocupar un lloc real en l'arquitectura de molts sistemes. Cada cop més empreses els integren per coordinar fluxos, respondre a clients o executar tasques complexes sense intervenció humana.

Però darrere d'aquesta promesa d'automatització "intel·ligent" hi ha un fet incòmode: els agents fallen, i ho fan de maneres difícils d'anticipar.

La majoria de les guies parlen de com fer-los resilients. Tanmateix, abans de dissenyar resilència, cal entendre on es trenquen. Aquest text no busca mostrar bones pràctiques, sinó explorar els punts febles més comuns, els que solen aparèixer quan un agent deixa de comportar-se com esperem.

Un agent generatiu no és només un model que respon. És una cadena de dependències que van des del model base fins a les eines que utilitza. Cada capa és una possible font d'error.

El model fundacional pot ser la primera esquerda. De vegades el problema no rau en la seva capacitat, sinó en el seu context. Quan se superen els límits de tokens o es combinen instruccions de manera confusa, el model comença a "inventar" passos o repetir frases. En producció, això es tradueix en decisions errònies i converses que es desvien sense motiu.

L'orquestració és un altre punt sensible. Un error en la gestió d'estat, una variable mal passada o una condició mal definida pot provocar bucles infinits o respostes incoherents. Moltes fallades visibles dels agents no venen del model, sinó de la manera com el dirigim.

La infraestructura també té la seva quota de responsabilitat. Latències altes, sessions que expiren o sistemes que no suporten la concurrència real de l'ús diari. Quan un agent depèn de múltiples components distribuïts, n'hi ha prou amb un petit retard per trencar la sincronia de tot el flux.

La base de coneixement (KB) sol ser una font silenciosa d'errors. Indexar malament, no filtrar versions antigues o no controlar la rellevància del contingut fa que l'agent respongui amb informació imprecisa. I el pitjor: ho fa amb seguretat.

Les eines externes amplifiquen el risc. Una API que canvia la seva resposta, una funció que no retorna error explícit o un timeout sense control poden congelar l'execució completa. Quan l'agent no té un pla B, la conversa s'estanca o es reinicia sense avís.

La seguretat i el compliment també són vulnerables. Les injeccions de prompt o l'exposició de dades sensibles en logs ocorren més sovint del que s'admet. No es tracta només d'atacs intencionals, sinó de descuits en com s'emmagatzemen i rastregen els contextos.

L'observabilitat tanca la llista. Molts equips no aconsegueixen identificar una fallada perquè el sistema no registra prou informació. Sense mètriques clares o traces semàntiques, l'error es repeteix sense deixar rastre.

A la pràctica, la majoria dels incidents s'agrupen en cinc patrons estructurals.

Dependència compartida. Quan tots els fluxos depenen d'un mateix servei o component (per exemple, la base vectorial), qualsevol interrupció afecta tot el sistema. És un punt únic de fallada, i gairebé sempre passa desapercebut fins que ocorre.

Capacitat insuficient. Molts agents funcionen bé en entorns de prova, però col·lapsen en escalar. No és només un tema de CPU o memòria: també de límits de tokens, mida de context i saturació de les cues de trucades.

Latència creixent. No sempre hi ha una fallada tècnica. De vegades el sistema simplement deixa de ser útil perquè triga massa. Els usuaris abandonen abans que l'agent acabi de raonar.

Dependències fràgils. Els agents depenen de serveis externs: traductors, cercadors, bases vectorials, serveis de correu. Quan una d'aquestes peces canvia o falla, l'agent no té manera de recuperar-se.

Desviació de comportament. És el més difícil de detectar. El model comença a ignorar regles, oblidar passos o respondre amb un to diferent. Ocorre lentament, a mesura que el context s'omple o les instruccions perden pes.

Imagina un agent que depèn d'una API per consultar preus. Un dia, aquesta API canvia un camp de la seva resposta. L'agent, que espera un format anterior, interpreta malament les dades. El resultat és una trucada fallida que no genera error, i que s'intenta repetir. En segons, el sistema entra en un bucle silenciós que consumeix tokens, incrementa costos i bloqueja la resta de tasques.

Tot va començar amb un canvi menor, però la manca d'aïllament entre components va fer que la fallada es propagués.

En la majoria dels casos, els agents no fallen per ser “poc intel·ligents”, sinó perquè manquen de límits clars entre etapes. Cada error que no es gestiona es converteix en una bola de neu.

Hi ha senyals que apareixen molt abans d'una fallada completa. Latències que pugen lentament, respostes truncades, logs buits o repeticions semàntiques (“Intentant resoldre…” una vegada i una altra).

Monitorar aquests senyals exigeix més que mètriques tècniques: cal observabilitat semàntica, la capacitat d'entendre si l'agent està pensant o només repetint.

També ajuda introduir caos controlat. Proves on se simulen errors de xarxa, respostes corruptes o temps d'espera forçat. Si l'agent no es pot recuperar d'això, probablement tampoc ho farà en producció.

La resiliència no s'afegeix al final del desenvolupament. Es dissenya des del principi, assumint que cada component fallarà en algun moment.

Això implica construir aïllament entre mòduls, afegir validacions explícites i definir comportaments de recuperació. Però sobretot, implica acceptar que els agents no són sistemes deterministes: pensen amb incertesa, i això exigeix una arquitectura que sàpiga conviure amb ella.

Un agent generatiu no falla per no raonar, sinó per no preveure l'error.

I entendre les seves fallades és el primer pas per dissenyar agents que de veritat puguin sostenir-se en el món real.