Hai messo insieme tre agenti: uno raccoglie dati, uno li analizza, uno scrive il report. In sandbox funziona. In produzione, dopo due settimane, il sistema si inceppa su un input leggermente fuori norma e non riesci a capire dove. Questo è il problema reale dei workflow multi-agente: non è difficile farli partire, è difficile farli reggere.
Lavorando su integrazioni AI per PMI e team marketing, ho visto questa dinamica ripetersi. L'architettura sembrava pulita sulla carta. Poi il contesto si accumula, gli agenti si parlano in loop, i costi esplodono e il risultato finale è meno affidabile di uno script Python scritto in un pomeriggio. Vale la pena capire perché succede e come evitarlo.
La trappola dell'orchestrazione troppo ambiziosa
Il pattern più comune che collassa è quello che chiamo "catena senza controllo": agente A passa output ad agente B che passa ad agente C, senza nessun checkpoint intermedio. Funziona benissimo quando tutti gli step vanno a buon fine. Basta un'allucinazione al primo passaggio per contaminare ogni step successivo, e l'errore arriva a destinazione confezionato come verità.
Framework come CrewAI incoraggiano proprio questo modello sequenziale perché è semplice da configurare. Il problema non è il framework in sé: è che la semplicità di configurazione nasconde la complessità dei failure mode. Quando un agente "manager" delega a un agente "worker" senza validare l'output intermedio, stai costruendo un sistema di amplificazione degli errori, non di riduzione.
La prima regola pratica: ogni handoff tra agenti è un punto di rischio. Se non hai un meccanismo esplicito di validazione in quel punto, hai un debito tecnico nascosto.
LangGraph e la gestione dello stato: potente ma esigente
LangGraph risolve un problema che CrewAI in configurazione base non affronta: la gestione esplicita dello stato condiviso tra agenti. Con un grafo orientato puoi definire nodi, transizioni e condizioni di uscita in modo strutturato. È un approccio molto più vicino all'ingegneria del software classica.
Il punto di rottura che ho osservato con LangGraph non è nella libreria: è nella gestione del contesto cumulativo. Ogni agente che aggiunge informazioni allo stato condiviso incrementa la dimensione del contesto passato al prossimo nodo. Su conversazioni o pipeline lunghe, arrivi velocemente a finestre di contesto sature. Il modello inizia a perdere informazioni delle prime iterazioni, il comportamento diventa imprevedibile, e il debugging è una sofferenza.
Due soluzioni concrete che funzionano:
- Stato compresso: ogni agente non appende il suo output grezzo allo stato, ma produce un sommario strutturato. Si perde granularità, si guadagna stabilità.
- Stato a livelli: separi il contesto a lungo termine (obiettivo, vincoli, output finali attesi) da quello a breve termine (step corrente, dati dell'iterazione). Solo il secondo viene passato integralmente tra agenti adiacenti.
Nessuna delle due è gratis in termini di complessità di design. Ma è complessità esplicita, non nascosta.
Architetture custom: quando ha senso e quando è overengineering
C'è una tendenza, soprattutto in team con sviluppatori senior, a scartare i framework esistenti e costruire tutto da zero. L'argomento è che i framework aggiungono overhead e oscurano il comportamento del sistema. È un argomento valido, ma porta facilmente a reinventare soluzioni peggiori di quelle già disponibili.
Un'architettura custom ha senso quando:
1. Il tuo caso d'uso ha requisiti di latenza o costo che i framework non possono rispettare per design.
2. Hai bisogno di integrare sistemi legacy che non parlano bene con le astrazioni dei framework standard.
3. Il team ha già esperienza nella gestione di sistemi distribuiti e capisce i failure mode prima di costruire.
Ha poco senso quando il vero problema è che nessuno in team ha letto la documentazione del framework scelto. Ho visto architetture custom che replicavano esattamente LangGraph, ma con meno test e nessuna community a supporto.
Il consiglio è di partire da framework consolidati, portarli al limite in un contesto controllato, e solo a quel punto valutare cosa sostituire con codice custom. Non il contrario.
I tre punti di rottura più frequenti in produzione
Dopo diversi progetti, i failure ricorrenti si concentrano in tre aree:
Loop non terminanti. Due agenti si passano un task avanti e indietro perché nessuno dei due ha criteri di uscita sufficientemente precisi. In LangGraph puoi gestirlo con condizioni esplicite sul grafo. In sistemi più informali, spesso manca qualsiasi limite sul numero di iterazioni. Il sistema gira, consuma token, non produce nulla.
Allucinazioni propagate. Un agente genera un'informazione errata con alta confidenza. Gli agenti successivi la usano come fatto accertato. Il sistema non ha nessun meccanismo di verifica esterna. Il risultato finale è coerente internamente ma sbagliato nel merito. Questo problema è particolarmente insidioso nei workflow di ricerca o di generazione contenuti su dati fattuali.
Costi fuori controllo. I workflow multi-agente moltiplicano le chiamate API. Un pipeline che chiama GPT-4o su tre agenti con contesti ampi può costare dieci volte quello che ti aspetti, specialmente se ci sono loop o retry automatici. Senza logging granulare per agente e per step, è impossibile ottimizzare. Il monitoraggio dei costi non è un dettaglio operativo: è parte dell'architettura.
Cosa distingue un'architettura che regge
Le architetture multi-agente che ho visto funzionare in produzione condividono alcune caratteristiche strutturali, indipendentemente dal framework usato.
Ogni agente ha un perimetro di responsabilità stretto e ben definito. Non "analizza i dati e proponi azioni", ma "classifica questo testo in una di queste cinque categorie e restituisci la categoria con un livello di confidenza". Meno ambiguità nel prompt di sistema, meno varianza nell'output.
Esistono nodi di validazione espliciti tra agenti critici. Non necessariamente un altro LLM: a volte basta uno schema JSON con validazione Pydantic o una semplice funzione Python che verifica condizioni minime sull'output prima di procedere.
C'è un sistema di osservabilità prima ancora che il sistema vada in produzione. LangSmith per chi usa LangChain/LangGraph, o soluzioni custom con logging strutturato. Senza visibilità su cosa fa ogni agente ad ogni step, il debugging su sistemi complessi diventa indovinare.
Infine, il sistema degrada in modo controllato. Se un agente fallisce, il workflow sa cosa fare: ritentare, saltare lo step, escalare all'umano, restituire un output parziale. Un sistema che si blocca senza output è quasi sempre peggio di uno che restituisce un risultato incompleto con un flag esplicito di incertezza.
La mossa concreta da fare domani mattina
Se stai progettando o revisionando un workflow multi-agente, prendi il diagramma dell'architettura e identifica ogni freccia che connette due agenti. Per ognuna, rispondi a questa domanda: cosa succede se l'agente di partenza restituisce un output malformato o semanticamente sbagliato? Se la risposta è "non lo so" o "non può succedere", hai trovato il tuo punto di rottura. Inizia da lì, prima di aggiungere qualsiasi altro agente al sistema.