Quan els equips de desenvolupament comencen a construir sistemes amb agents d'intel·ligència artificial, apareix una temptació gairebé irresistible: connectar els agents directament mitjançant trucades síncrones. Al cap i a la fi, és el patró més familiar. Un agent planificador invoca un agent d'enriquiment, que al seu torn fa una trucada a un agent de preus, i així successivament. Tot funciona a la demo, la latència sembla acceptable i el codi queda net. Però aquesta arquitectura, aparentment senzilla, amaga un parany que ja vam pagar car en l'era dels microserveis: el monòlit distribuït. Quan els agents es truquen directament, cada interacció es converteix en un acoblament rígid, cada fallada es propaga en cascada i, el pitjor de tot, la conversa entre agents desapareix tan bon punt acaba la trucada. No hi ha registre, ni possibilitat de repetició, ni auditoria. És el mateix problema de sempre, només que disfressat d'intel·ligència artificial.
Imaginem un flux típic de processament de comandes. Un agent planificador rep una comanda i, per enriquir-la, necessita dades d'un agent d'enriquiment. Aquest agent, al seu torn, consulta un agent de preus, i aquest a un agent antifrau. Tot ocorre en una cadena de trucades HTTP síncrones. A la demo, el temps de resposta és d'uns segons, però en producció, quan un agent es troba amb un registre de producte mal format o una API externa inestable, la cadena es bloqueja. L'agent d'enriquiment entra en un bucle de reintents, no retorna res, i els agents que esperen a dalt queden penjats. La cua de comandes s'acumula, el rendiment cau a zero i no hi ha errors al tauler de control, només un silenci que fa mal. I quan algú pregunta què estava fent l'agent just abans de penjar-se, l'única resposta és un bolcat de pila. No hi ha rastre dels missatges intercanviats. La conversa va ocórrer a la memòria RAM i es va perdre per sempre.
Aquest escenari no és un problema d'intel·ligència artificial. És un problema d'arquitectura de sistemes distribuïts que ja vam resoldre fa una dècada amb els microserveis, però que ara ressuscita sota el disfressa d'agents. Les trucades directes entre agents reintrodueixen cinc mals que qualsevol arquitecte experimentat reconeix a l'instant: acoblament fort, fallades en cascada, tempestes de fan-out, absència de contrapressió i, el més crític, falta de traçabilitat. Quan l'agent A ha de conèixer l'adreça, el format de sol·licitud i la resposta de l'agent B, el graf de dependències queda gravat al codi. Afegir un nou agent de compliment normatiu obliga a modificar el planificador perquè li enviï també les dades. La disponibilitat d'una cadena de cinc agents és el producte de les seves disponibilitats individuals, i la latència al percentil 99 és la suma de totes les cues. Amb agents d'IA, les inferències del qual poden trigar segons, aquestes cues es tornen enormes i el sistema es torna fràgil.
La solució és coneguda, avorrida i efectiva: no deixis que els agents es truquin directament. En lloc d'això, publiquen esdeveniments en un broker o registre central, i altres agents se subscriuen als esdeveniments que els interessen. L'agent planificador no invoca el d'enriquiment; publica un esdeveniment 'order.enrichment.requested' i segueix endavant. L'agent d'enriquiment, quan estigui llest i al seu propi ritme, consumeix aquest esdeveniment, fa la seva feina i publica un altre esdeveniment amb el resultat. Qui necessiti les dades enriquides —l'agent de preus, el de frau, o un de nou d'auditoria que s'afegeixi el pròxim trimestre— se subscriu a l'esdeveniment de resultat. El planificador mai sap qui hi ha a l'altre costat. El contracte entre agents es redueix a un únic element: l'esquema de l'esdeveniment. Un esquema tipificat i versionat és tota la superfície d'acoblament. La resta desapareix.
Què guanya el sistema amb aquest canvi? Primer, durabilitat. L'esdeveniment es guarda a disc abans que cap agent el toqui. Si l'agent d'enriquiment cau durant una hora, la feina espera al registre. Quan torna, continua des d'on ho va deixar. Segon, repetició. Si un desplegament erroni a l'agent de preus causa problemes, es pot reiniciar l'offset del consumidor i tornar a executar els esdeveniments d'ahir amb el codi corregit. Depurar una decisió estranya es converteix en llegir la seqüència exacta d'esdeveniments associada a un identificador de traça. No es pot repetir una trucada HTTP que no es va gravar, però sempre es pot repetir un registre d'esdeveniments. Tercer, auditoria gratuïta. El que abans era una tasca onerosa de compliment —tenir un registre de cada decisió de cada agent— ara és simplement el log. Cada intenció, cada resultat, amb el seu segell de temps. Quan un auditor pregunta per què es va marcar una comanda concreta, la resposta no es reconstrueix a partir de la memòria, es llegeix del registre.
A més, la contrapressió deixa de ser un problema. Si un agent productor genera esdeveniments més ràpid del que el consumidor pot processar-los, no és una fallada, és un retard mesurable. El buffer és el punt: es pot observar com creix la cua i escalar en conseqüència. L'acoblament es torna tan lax que afegir un agent consisteix simplement a agregar un subscriptor; eliminar-lo, a treure un subscriptor; canviar la implementació d'un agent per complet sense que ningú a dalt se n'assabenti, perquè només estaven parlant amb el tema. El graf de dependències deixa de ser codi que mantenir i es converteix en configuració d'encaminament.
L'objecció habitual és que s'afegeix un salt de xarxa i un broker per gestionar. És cert: una trucada directa té menys latència que publicar i consumir. Però el cost real de l'arquitectura síncrona no són els mil·lisegons, sinó la fragilitat i la ceguesa. Els fluxos de treball amb agents d'IA no estan limitats per la latència de xarxa, sinó pels segons que triga una inferència o una trucada a eina. Estalviar un salt de broker en un camí que ja gasta tres segons en un bucle de raonament és un error d'arrodoniment. El que realment importa és poder saber què va passar i que el sistema no caigui tot alhora. Un esdeveniment que es pot repetir val més que un mil·lisegon estalviat.
Per descomptat, hi ha compromisos reals. Ara cal operar un broker: Kafka, NATS, SQS o Redis Streams, segons l'escala. Cal dissenyar per a consistència eventual i consumidors idempotents —d'aquí que l'esquema inclogui un camp d'idempotència. I els patrons request/response, on cal una resposta immediata per continuar, es modelen com un esdeveniment de sol·licitud i un altre de resposta correlacionats, cosa que sembla més feina fins que cal repetir un d'ells. Per a intercanvis genuïnament síncrons, de baixa latència i entre dues parts, una trucada directa encara és vàlida. El problema no és l'existència de trucades, sinó la malla d'agents que es bloquegen mútuament.
A Q2BSTUDIO, portem anys aplicant aquests principis en el desenvolupament d'aplicacions a mida per a empreses que necessiten sistemes robustos i escalables. Sabem que l'arquitectura basada en esdeveniments no és una moda, sinó una necessitat quan es treballa amb intel·ligència artificial i agents autònoms. El nostre equip integra aquestes solucions amb serveis cloud a AWS i Azure, garantint ciberseguretat i traçabilitat a cada capa, i complementa la presa de decisions amb taulers de Business Intelligence a Power BI. No es tracta d'evitar les trucades directes per dogma, sinó d'entendre que la conversa entre agents és l'actiu més valuós del sistema, i ha de quedar registrada, no volatilitzar-se a la RAM.
La propera vegada que et sentis temptat de cablejar l'agent A directament amb l'agent B, fes-te una pregunta: quan això es pengi a les tres de la matinada, què hauré de llegir per entendre què va passar? Si la resposta és un bolcat de pila, has construït malament el sistema. Posa un registre al mig i deixa que els agents deixin un rastre de paper. No deixis que els teus agents d'IA es truquin directament. El broker no és un extra, és la peça que sobreviu.
