Els primers projectes d'IA generativa a l'empresa van ser, gairebé tots, assistents que responen preguntes. Són útils, però tenen dos límits clars: només actuen quan algú els escriu i la seva memòria es redueix al que cap a la conversa. Un agent d'IA va un pas més enllà: raona sobre un objectiu, planifica els passos, consulta informació de l'organització i executa accions en altres sistemes. I quan hi ha diversos agents treballant junts, l'arquitectura importa tant com el model.
Aquest article repassa les decisions de disseny que determinen si un sistema d'agents serà mantenible i escalable o si es convertirà en un prototip impossible de portar a producció.
Les quatre peces d'un agent
Un agent és l'orquestració de quatre elements:
| Peça | Què aporta | Exemple |
|---|---|---|
| Model de raonament | Interpreta la intenció, decideix i planifica la seqüència d'accions | Un model de llenguatge de propòsit general |
| Instruccions | Defineixen l'especialitat, el to, els límits i què fer davant el dubte | «Agent de nòmina», «agent de compliment normatiu» |
| Coneixement | Memòria de la conversa i accés a documentació pròpia mitjançant cerca semàntica (RAG) | Polítiques internes, procediments, convenis |
| Eines | Connectors que permeten consultar i modificar sistemes reals | ERP, CRM, sistema de recursos humans |
La peça que introdueix més risc és l'última: quan un agent pot canviar l'estat d'un sistema (crear una comanda, modificar un contracte, enviar un correu), deixa de ser un experiment i passa a ser una aplicació amb conseqüències. Per això convé que cada agent tingui poques eines i ben acotades.
Sistemes multiagent: especialitzar i coordinar
Un únic agent que ho sap tot i ho pot tot és difícil de provar i de corregir. L'alternativa és descompondre per domini: a recursos humans, per exemple, un agent de vacances, un altre de nòmina i un altre d'incorporació, cadascun amb les seves instruccions, el seu coneixement i els seus permisos.
Per sobre, un agent orquestrador rep la petició, identifica quins agents hi han d'intervenir, en quin ordre i amb quines dependències, i compon la resposta final. Hi ha dues maneres d'orquestrar:
- Seqüencial: el flux està definit per endavant. És l'opció adequada per a processos amb passos obligatoris i requisits de compliment, com una incorporació en un sector regulat o una revisió financera.
- Autònoma: el model decideix el flux sobre la marxa segons el context i els resultats parcials de cada agent. Dona més flexibilitat, però és menys previsible i exigeix més traçabilitat i més proves.
A la pràctica, molts sistemes combinen totes dues: un esquelet seqüencial per a allò que s'ha de complir sempre i trams autònoms on la variabilitat és acceptable.
Arquitectura orientada a esdeveniments: autonomia de debò
Si un agent només actua quan algú li escriu, continua sent reactiu. L'autonomia real arriba quan reacciona a allò que passa al negoci: s'emet una factura, arriba un correu a una bústia, baixa l'inventari d'un article o venç un termini. L'arquitectura orientada a esdeveniments (EDA) proporciona aquesta capacitat.
Tres avantatges la fan gairebé imprescindible en sistemes d'agents:
- Disparadors automàtics. Els agents se subscriuen a esdeveniments i actuen sense intervenció humana: preparar una reclamació de cobrament, obrir una incidència o llançar una alerta.
- Resposta en temps real. L'agent actua quan es produeix l'esdeveniment, no quan algú revisa una safata.
- Resiliència. Com que estan desacoblats, la fallada d'un agent no fa caure el sistema: l'esdeveniment queda a la cua i es processa quan el component es recupera.
Protocols d'interoperabilitat: MCP i A2A
Dos estàndards estan ordenant un ecosistema que fins fa poc era una col·lecció d'integracions a mida:
- MCP (Model Context Protocol): una capa comuna per oferir eines i context a qualsevol agent. Una eina publicada per MCP es pot reutilitzar en agents construïts amb plataformes diferents.
- A2A (Agent-to-Agent): un estàndard emergent perquè agents de plataformes i llenguatges diferents es comuniquin de manera segura.
Apostar-hi des del principi redueix la dependència d'un proveïdor i evita refer integracions cada vegada que canvia el model o la plataforma.
Govern, seguretat i monitoratge
Un agent en producció necessita el mateix rigor que qualsevol aplicació crítica, i alguns controls específics:
- Identitat pròpia per agent. Cada agent es dona d'alta al proveïdor d'identitat amb permisos mínims sobre dades i API, i les seves accions queden registrades al seu nom. Els principals proveïdors, com Microsoft Entra, ja ofereixen identitats específiques per a agents.
- Persona en el bucle. Les decisions no estàndard o d'alt risc (una concessió de crèdit, un canvi contractual, qualsevol acció irreversible) requereixen aprovació humana explícita.
- Compliment aplicat a la plataforma. Les polítiques de protecció de la informació i les obligacions del RGPD i del Reglament europeu d'IA s'apliquen de manera centralitzada, no agent per agent.
- Traçabilitat completa. Cada pas (orquestrador, agent, eina, resposta) es registra amb eines d'observabilitat com OpenTelemetry o Azure Monitor. Sense aquest rastre, depurar un error o respondre a una auditoria és gairebé impossible.
- Avaluació contínua. Com que les respostes no són deterministes, es proven de manera automàtica i periòdica la fidelitat a les fonts i la seguretat del contingut, no només en el moment del lliurament.
Quina plataforma triar
No hi ha una solució única. L'elecció equilibra velocitat de desenvolupament, control tècnic i integració amb el que ja existeix:
| Plataforma | Desenvolupament | Integració | Desplegament | Encaixa en |
|---|---|---|---|---|
| Copilot Studio | Low-code, visual | Microsoft 365 i Power Platform | Núvol gestionat | Prototips ràpids i fluxos creats per usuaris de negoci |
| Microsoft Foundry (abans Azure AI Foundry) | Pro-code (Python, C#) | Ecosistema Azure | Contenidors, Kubernetes | Sistemes crítics amb requisits de compliment |
| n8n | Low-code, visual | Agnòstic, amb suport de MCP | Núvol o instal·lació pròpia | Integracions complexes i portabilitat |
| LangChain, LlamaIndex | Biblioteques de Python | API genèriques | Contenidors, Kubernetes | Experimentació i models oberts |
Una arquitectura dual en entorns Microsoft
En organitzacions que ja treballen amb Microsoft, una combinació que funciona bé és:
- Al davant, Copilot Studio, com a cara conversacional i orquestració d'alt nivell. Els usuaris de negoci poden crear i ajustar fluxos sense programar.
- Al darrere, Microsoft Foundry, com a motor per a allò complex: RAG avançat, models ajustats, avaluació i desplegament controlat.
- Per als agents desenvolupats a mida, un SDK com Semantic Kernel (avui integrat a Microsoft Agent Framework), independent del model i amb suport dels protocols oberts.
El principi és senzill: la capa del davant gestiona l'experiència d'usuari; la del darrere garanteix seguretat, escalabilitat i compliment en les operacions crítiques.
Sis comprovacions abans de producció
Si un sistema en falla alguna, el seu manteniment a mitjà termini està en risc:
- Modularitat: cada agent té un rol únic i un conjunt limitat d'eines?
- Infraestructura desacoblada: fa servir esdeveniments i pot escalar horitzontalment amb contenidors quan creixen els disparadors i la demanda?
- Protocols estàndard: la comunicació entre agents i eines fa servir MCP o A2A?
- Identitat i accés: cada agent té identitat pròpia amb permisos mínims sobre dades i API?
- Traçabilitat: es registra cada pas de l'orquestrador i dels agents?
- Avaluació automatitzada: hi ha proves periòdiques de fidelitat i de seguretat del contingut?
Per on començar
L'èxit depèn menys de la tecnologia que d'aplicar amb disciplina uns pocs principis: modularitat, govern, observabilitat i compliment. Un camí raonable:
- Triar un o dos casos d'ús amb valor clar i risc controlat.
- Definir des del principi les identitats, els permisos i els punts d'aprovació humana.
- Construir una prova de concepte en un entorn controlat, amb traçabilitat des del primer dia.
- Escalar de manera gradual, amb mètriques de qualitat que es revisen contínuament.
A Bidatia ajudem a dissenyar aquest tipus d'arquitectures i a portar-les a producció amb els controls adequats.
Preguntes freqüents
Quina diferència hi ha entre un assistent basat en un model de llenguatge i un agent d'IA?
L'assistent respon al que se li demana i la seva capacitat depèn del que cap a la conversa. L'agent, a més de raonar, planifica, consulta coneixement propi de l'organització i fa servir eines per executar accions en altres sistemes, com registrar una sol·licitud a l'ERP o actualitzar el CRM.
Quan convé un sistema multiagent en lloc d'un únic agent?
Quan el procés abasta tasques diferents amb regles, dades i permisos diferents. Un agent per tasca, amb poques eines, és més fàcil de provar, corregir i auditar que un agent generalista que ho fa tot.
Què aporten MCP i A2A?
MCP (Model Context Protocol) estandarditza com es posen eines i context a disposició d'un agent. A2A (Agent-to-Agent) estandarditza la comunicació entre agents construïts en plataformes diferents. Amb tots dos, canviar de plataforma o de model no obliga a refer les integracions.
Cal començar amb low-code o amb pro-code?
Depèn del cas. El low-code permet validar ràpidament un flux conversacional; el pro-code dona més control per a la lògica crítica, les proves i el desplegament. Moltes arquitectures combinen tots dos: una capa conversacional àgil al davant i serveis desenvolupats al darrere.