Perché ho smesso di costruire “sciami” di agenti (almeno per ora)

Nel mondo dell’IA generativa, la parola d’ordine del momento è “Multi-Agent Systems”. Lo ammetto: anch’io mi sono fatto sedurre dall’idea di sciami di agenti autonomi che collaborano come una colonia di formiche. Poi ho provato a portarne uno in produzione, e la realtà mi ha rimesso i piedi per terra.

Quello che ho imparato, spesso a mie spese, è che serve un approccio radicalmente diverso dalle demo che vedi su Twitter: serve pragmatismo incrementale.

Ecco le lezioni che ho raccolto sul campo.

1. Ho iniziato con un “coltellino svizzero”, non con una squadra

Il mio errore iniziale è stato saltare direttamente all’orchestrazione complessa. Volevo subito tre agenti specializzati che si passavano i dati. Il risultato? Un sistema fragile e impossibile da debuggare.

La lezione più importante che ho imparato è semplice: parti con un unico agente capace. Dagli un set di strumenti ben fornito e fallo funzionare. Solo quando la complessità diventa davvero ingestibile ha senso procedere al refactoring verso un sistema multi-agente.

L’analogia che faccio sempre Immaginate di dover gestire una cucina. Non assumereste venti specialisti (un saucier, un pâtissier, un rotisseur) solo per preparare un panino. Partireste con un cuoco versatile e competente. Man mano che il menu si espande, aggiungerete stazioni dedicate. Fare il contrario significa creare una cucina dove si passa più tempo a gridare gli ordini (orchestrazione) che a cucinare. Ci sono passato, e non è divertente.

2. Quando ho capito che era ora di dividere

Con il tempo ho identificato tre segnali che mi dicono quando un singolo agente è diventato troppo grande:

• Confini di dominio chiari: Quando mi sono ritrovato con un agente che faceva sia analisi dei dati di marketing che operazioni di scrittura nel CRM, ho capito che era tempo di dividere. Come nella vita: l’idraulico non fa l’elettricista.
• Economia dei modelli: Mi sono accorto che una parte del task richiedeva “ragionamento profondo” (costoso e lento), mentre un’altra richiedeva solo velocità. Dividere gli agenti mi ha permesso di usare un modello economico per il triage veloce e un modello “SOTA” (State of the Art, cioè il più avanzato disponibile sul mercato in quel momento) solo per i passaggi complessi, risparmiando budget.
• Linee di governance: Questo è il punto che ho sottovalutato di più. Se una parte del processo accede a dati sensibili (es. stipendi HR) e l’altra no, separare gli agenti è l’unico modo per applicare il principio del “minimo privilegio”. L’ho capito dopo un audit di sicurezza che mi ha fatto sudare freddo.

3. I passaggi di consegne: il punto dove tutto si rompe

Passare al multi-agente ha introdotto un problema che non avevo previsto: ogni “handoff edge” (punto di passaggio tra agenti) è un potenziale punto di rottura. Non basta più testare se il singolo agente funziona: bisogna testare ogni passaggio di consegne.

Ho visto contesti persi, dati mal interpretati, risposte che arrivavano all’agente sbagliato. Che si scelga un orchestratore centrale o un pattern a sciame, la complessità esponenziale risiede nelle interazioni, non nei singoli nodi. L’ho imparato sulla mia pelle.

4. MCP: lo standard che mi ha semplificato la vita

Quando ho iniziato ad avere più agenti specializzati, il problema era farli parlare tra loro senza creare una Torre di Babele. La svolta è arrivata con il Model Context Protocol (MCP).

Invece di scrivere integrazioni custom per ogni coppia di agenti, l’MCP mi ha permesso di esporre le capacità e i dati in un formato che gli agenti possono “capire” nativamente. Per me è stato come passare da telefonate confuse a un’API universale per la collaborazione tra intelligenze artificiali.

Dopo mesi di tentativi, la mia conclusione è questa: l’architettura degli agenti non riguarda l’aggiunta di complessità, ma la sua gestione. L’obiettivo è costruire sistemi che automatizzino non solo i task, ma la conoscenza istituzionale e il giudizio esperto.

Il mio consiglio? Partite semplici, specializzate solo quando serve e costruite un telaio operativo robusto. È così che si passa dal prototipo alla produzione.