L’Agents API d’OpenAI ha sortit en beta pública aquesta setmana. Suport natiu per a orquestració multi-agent, operació autònoma de navegadors i programari, cerca d’eines i compressió de context. És el primer cop que aquest tipus d’infraestructura és accessible sense construir-la des de zero.
El problema és que «multi-agent» s’ha convertit en una paraula que tothom repeteix i gairebé ningú sap aplicar.
Un agent no és prou intel·ligent per fer-ho tot
Quan demanes a un sol model d’IA que investigui un tema, redacti un informe i el revisi críticament, obté tres tasques que es contradiuen entre elles. El mode recerca és expansiu: busca, acumula, no filtra. El mode redacció és narratiu: tria, condensa, simplifica. El mode revisió és destructiu per necessitat: cerca errors, contradiccions, llacunes.
Un únic agent que fa les tres coses tendeix a fer malament les tres, perquè les instruccions que optimitzen una tasca perjudiquen les altres. Els investigadors del MIT han documentat aquest fenomen en entorns de tasques mixtes: la qualitat de sortida cau entre un 23% i un 31% comparat amb agents especialitzats en seqüència.
L’orquestració multi-agent resol això per disseny. Cada agent té un rol fix, instruccions específiques i un àmbit d’actuació limitat, i l’orquestrador coordina el flux.
L’arquitectura de tres agents que pots construir avui
L’exemple més senzill per entendre el concepte en producció és un pipeline de producció de contingut: recerca → redacció → revisió. Tres agents, tres personalitats, un resultat.
L’agent de recerca rep la pregunta inicial i té accés a eines de cerca web. La seva instrucció és clara: retorna fets verificables, fonts concretes i dades numèriques. No interpreta, no redacta, només lliura materials en brut.
L’agent de redacció rep la sortida del primer i té instruccions narratives. Transforma el material en text estructurat per a l’audiència objectiu. No cerca, no avalua, només escriu.
L’agent de revisió rep el text generat i té instruccions explícitament crítiques: busca afirmacions sense font, contradiccions internes i arguments circulars. Retorna una llista de problemes, no una versió corregida.
L’orquestrador (que amb l’Agents API d’OpenAI pots definir amb unes poques línies de codi) decideix si el text passa la revisió o torna al segon agent per corregir-se. El bucle s’atura quan la revisió no detecta problemes o quan s’arriba a un màxim d’iteracions.
Amb GPT-6.1 Sol (que s’acosta al rendiment de GPT-6 Astra en tasques professionals però a una cinquena part del cost) un pipeline d’aquest tipus és econòmicament viable fins i tot per a un equip petit.
Per què la majoria d’implementacions fracassen al primer mes
El patró d’error més comú no és tècnic, és de disseny.
Els equips que comencen amb multi-agent solen fer dues coses alhora: definir agents amb rols massa amplis i no establir criteris clars de parada. Un agent de revisió que pot modificar el text directament deixa d’exercir la seva funció, es converteix en un segon redactor. Un orquestrador sense límit d’iteracions pot entrar en un bucle que no convergeix i consumir pressupost d’API sense produir res útil.
La regla és simple: cada agent ha de poder fallar en la seva tasca sense trencar el sistema. Si l’agent de recerca no troba fonts prou sòlides, ha de reportar-ho i aturar el flux, no inventar-se dades per continuar. Construir aquesta lògica de fallada explícita és el que separa un prototip d’una eina que pot treballar sense supervisió.
Apple ha anunciat aquesta mateixa setmana que endureix els permisos de macOS per als agents d’IA, reconeixent que l’accés ample a fitxers i navegació és un risc real. No és casualitat. Quan un agent opera de forma autònoma, els errors d’instrucció es propaguen sense cap humà que els aturi. I aquí és on el disseny de límits té tot el sentit del món.
Què en fem, d’això?
Com a empresa catalana amb un equip que ja usa l’API d’OpenAI, fins i tot de forma bàsica, la beta pública de l’Agents API és el moment de fer un prototip real. No un projecte d’R+D, sinó un cas d’ús concret, repetitiu i verificable. El pipeline de recerca-redacció-revisió és el més fàcil de mesurar perquè tens un output llegible i pots jutjar la qualitat sense eines addicionals.
Comença amb dos agents, no tres. Recerca i redacció. Afegeix la revisió quan tinguis clars els criteris de parada. Un pipeline complex que no conversa bé entre agents és pitjor que un de simple que funciona cada vegada.
Defineix el criteri d’èxit abans de desplegar. Quin percentatge de textos ha de passar la revisió en primera iteració perquè el sistema sigui útil? Sense aquest número, no podràs saber si el sistema millora o simplement s’executa.
Si avui demanes a un sol model que investigui, redacti i revisi alhora, ja estàs fent orquestració multi-agent. Només que amb un sol agent fent tres papers contradictoris i cap criteri de parada.
La pregunta, per tant, no és si val la pena separar-los. És quant temps fa que no mires els resultats amb prou atenció per adonar-te’n.