Quando si parla di agenti AI, la domanda viene spesso posta nel modo sbagliato: “Quale modello usate?”. Sembra naturale, ma riduce tutto a una classifica: il modello più nuovo, più potente, con più parametri o con benchmark migliori. È una logica comprensibile, ma poco adatta alla produzione. La domanda corretta non è quale sia il modello migliore in assoluto, ma quale sia il modello più equilibrato per quello specifico compito, in quello specifico punto della conversazione.
Una conversazione non è mai tutta uguale. Non ha sempre lo stesso livello di complessità, non tratta sempre gli stessi dati, non richiede sempre la stessa profondità di ragionamento e non ha sempre bisogno della stessa velocità di risposta. Un agente AI che accoglie un utente, capisce il motivo del contatto, raccoglie informazioni, consulta una knowledge base, propone una soluzione e valuta se coinvolgere una persona, non sta facendo una sola cosa. Sta attraversando fasi diverse. E ogni fase ha bisogno di capacità diverse.
Per questo, in Gruppo Trade, per gli agenti AIMOKA, ragioniamo sempre meno in termini di “un modello” e sempre più in termini di architettura conversazionale. Un agente non è un cervello unico che gestisce tutto dall’inizio alla fine. È un flusso composto da nodi: accoglienza, classificazione, raccolta dati, verifica delle informazioni, ricerca nella knowledge base, ragionamento sulla soluzione, eventuale passaggio a un operatore umano. Ogni nodo può avere regole diverse, fonti diverse, livelli di autonomia diversi. E può usare un modello diverso.
È questo che intendiamo quando parliamo di agenti AI multi-brain: non una somma casuale di modelli messi insieme, ma un’orchestrazione controllata di competenze diverse.
Pensiamo a una conversazione reale. Un utente scrive: “Buongiorno, ho un problema con la mia utenza”. In quel momento non serve attivare il modello più sofisticato disponibile. Serve una risposta rapida, naturale, educata. Serve capire il contesto, raccogliere le prime informazioni, non far percepire attrito o rigidità. È una fase delicata, non perché richieda reasoning profondo, ma perché definisce il tono della relazione.
Poi la conversazione cambia. L’utente aggiunge dettagli, eccezioni, vincoli. La richiesta può riguardare una procedura contrattuale, una configurazione tecnica, una policy interna o una casistica non standard. A quel punto l’agente deve correlare informazioni, consultare fonti, distinguere ciò che è certo da ciò che è probabile, verificare se ha abbastanza elementi per rispondere oppure se deve chiedere altro. Qui serve un modello più capace: non necessariamente il più costoso, ma quello più adatto a sostenere ragionamento, contesto e precisione.
Il multi-brain non nasce per usare modelli piccoli quando si vuole risparmiare e modelli grandi quando si vuole fare bella figura. Nasce per evitare sprechi e squilibri. Usare capacità avanzate dove non servono è inefficiente. Usare un modello troppo leggero dove serve ragionamento è pericoloso. Il punto è l’equilibrio.
Su volumi reali di call center, customer care, contact center o assistenza digitale, anche pochi centesimi per interazione diventano una voce rilevante. Se ogni saluto, ogni conferma, ogni domanda di chiarimento e ogni classificazione vengono gestiti dallo stesso modello usato per ragionare sui casi complessi, il conto cresce senza che aumenti davvero la qualità percepita.
Ma il tema non è solo economico. È anche ambientale. Ogni risposta generata da un modello ha un costo computazionale: energia, infrastruttura, raffreddamento, data center. I modelli più complessi, soprattutto quando fanno reasoning articolato o generano molte iterazioni interne, consumano di più rispetto a modelli più leggeri impiegati su compiti semplici. I consumi reali dipendono da moltissimi fattori, ma il principio resta chiaro: usare capacità computazionale avanzata quando non serve è uno spreco.
È un po’ come consumare litri d’acqua per dire “ciao”. La frase è volutamente provocatoria, ma rende l’idea: se l’agente deve solo accogliere l’utente, confermare una scelta o chiedere un dato mancante, non ha senso attivare una macchina progettata per ragionamenti complessi. La sostenibilità dell’AI passa anche da scelte architetturali più sobrie: non usare più intelligenza artificiale di quanta ne serva.
Un agente AI da produzione non deve solo rispondere correttamente. Deve rispondere correttamente, velocemente, con costi sostenibili, usando le fonti giuste, rispettando i vincoli di sicurezza e sapendo quando non deve rispondere. Ma deve anche sembrare naturale: nel ritmo, nella progressione della conversazione, nella capacità di non far sentire l’utente davanti a un modulo mascherato da chat.
La mancanza di naturalezza genera frizione. E la frizione genera handover. Quando un utente chiede di parlare con un operatore perché l’agente non capisce, risponde in modo rigido, fa domande già fatte, sembra non ricordare il contesto o non mostra empatia nel momento giusto, l’handover non è una semplice escalation. È una sconfitta. E se nasce non dalla complessità reale del caso, ma dalla scarsa qualità dell’esperienza conversazionale, è una doppia sconfitta: l’agente non ha fallito su un problema impossibile, ha fallito sulla relazione.
Anche qui il multi-brain aiuta, se progettato bene. Le fasi di accoglienza, chiarimento e accompagnamento possono privilegiare modelli più rapidi e naturali. Le fasi di analisi possono usare modelli più profondi. Le fasi di controllo possono essere più rigide e vincolate. Le fasi di escalation possono trasferire contesto in modo pulito all’operatore umano, senza costringere l’utente a ricominciare da capo. L’agente non deve avere sempre lo stesso tono, la stessa profondità e la stessa velocità. Deve adattarsi al momento.
Orchestrare più modelli dentro un unico flusso è più complesso che collegare un solo LLM (Large Language Model, il modello linguistico che genera le risposte) a una chat. Ogni nodo va progettato, ogni passaggio va testato, il contesto deve essere trasferito senza perdere informazioni, le fonti devono essere governate, le soglie di confidenza e le regole di escalation devono essere chiare.
È più semplice costruire un agente monolitico: un modello, un prompt, una knowledge base, una conversazione. Ma semplice da costruire non significa solido da gestire. La nostra scelta è sostenere la complessità a monte, in fase di progettazione, per ridurre inefficienze, costi, latenze e fragilità in produzione. La complessità architetturale la gestiamo noi. Il cliente non deve pagarla ogni giorno sotto forma di conversazioni lente, costose, innaturali o incapaci di reggere i volumi.
La differenza tra un agente che funziona in demo e un agente che funziona davvero sta spesso qui. In demo, un unico modello molto potente può impressionare. Ma quando aumentano i volumi, gli utenti, le eccezioni, i dati da proteggere, i costi da controllare e l’esigenza di continuità, non basta più che l’agente “risponda”. Deve reggere. Tutto questo funziona però solo se l’agente ha basi solide da cui attingere: una knowledge base certificata.
Deve essere veloce quando serve velocità, preciso quando serve precisione, sobrio quando il compito è semplice, profondo quando il caso è complesso, prudente quando non ha abbastanza informazioni, naturale quando l’utente ha bisogno di sentirsi accompagnato. Un agente conversazionale non dovrebbe essere pensato come un cervello solo. È un sistema.
Chiara, l’agente che stiamo costruendo, non ha un cervello solo. Ne ha molti. Ognuno al posto giusto
