Orchestrazione agenti AI: guida per i team di assistenza

L’orchestrazione degli agenti AI è il coordinamento di più agenti AI specializzati, e delle persone che stanno dietro di loro, in modo che una richiesta del cliente arrivi all’agente giusto, al momento giusto e con il contesto giusto. Un orchestratore, che può essere un agente principale o il codice attorno agli agenti, decide chi agisce dopo, che cosa viene trasmesso e quando il lavoro è concluso.

In breve

L’orchestrazione decide quale agente gestisce ogni passaggio di una conversazione, quale contesto riceve e quando subentra una persona.
La maggior parte delle configurazioni di assistenza combina pochi modelli: un router o un supervisore all’ingresso, passaggi in sequenza per le azioni regolamentate e passaggi di consegne tra agenti e verso le persone.
Le conversazioni multi-agente si rompono nei punti di giunzione: contesto perso in un passaggio, loop tra agenti, l’agente sbagliato che agisce e conversazioni chiuse prima che il lavoro sia finito.
Le dashboard per singolo agente nascondono questi errori, perché ogni agente può sembrare a posto mentre il percorso del cliente fallisce.
Faccia il controllo qualità del percorso, non del singolo turno: riunisca ogni segmento di agenti e persone in un unico record, valuti i punti di giunzione e attribuisca ogni errore al segmento che lo ha causato.

Che cos’è l’orchestrazione degli agenti AI?

L’orchestrazione degli agenti AI è il livello che coordina più agenti AI dentro un unico sistema. IBM la descrive come il coordinamento di agenti specializzati verso obiettivi comuni, con un orchestratore che può essere un agente centrale o un framework. Nel servizio clienti trasforma un bot di smistamento, un agente per la fatturazione, un agente per i resi e il suo team di operatori in un’unica esperienza.

Un agente AI (in inglese) è un modello con istruzioni e strumenti, che lavora verso un obiettivo. L’orchestrazione è il controllo del traffico tra più agenti, e a ogni turno risponde a quattro domande:

Chi agisce dopo? Un agente di smistamento, uno specialista, una persona o nessuno (la conversazione è conclusa).
Che cosa riceve? La trascrizione completa, un riepilogo o solo i campi che gli servono.
Che cosa può fare? Leggere dati, modificare un ordine, emettere un rimborso o solo rispondere.
Quando si ferma? L’obiettivo è raggiunto, si arriva a un limite di turni o serve l’approvazione di una persona.

Anthropic chiama workflow i sistemi in cui LLM e strumenti sono orchestrati attraverso percorsi di codice predefiniti, e agenti i sistemi in cui i modelli dirigono in modo dinamico i propri processi e l’uso degli strumenti. La maggior parte dell’orchestrazione nell’assistenza combina le due cose: percorsi fissi per rimborsi e verifiche d’identità, giudizio dell’agente per le domande aperte. La nostra guida su che cos’è l’IA agentica (in inglese) tratta la categoria più ampia.

Chi è un orchestratore AI? Dal punto di vista tecnico, il componente (un agente principale o un framework) che smista il lavoro. Dal punto di vista organizzativo, la persona o il team responsabile di come agenti e persone si dividono il lavoro: regole di smistamento, segnali di escalation e lo standard di qualità per l’intero percorso.

Quali sono i principali modelli di orchestrazione degli agenti AI?

Pochi modelli coprono quasi tutte le configurazioni di assistenza: un router che manda ogni richiesta a un solo specialista, un supervisore che mantiene il controllo e richiama gli specialisti come strumenti, una sequenza fissa di passaggi, agenti in parallelo sullo stesso input, una gerarchia di supervisori, passaggi di consegne tra agenti e verso le persone, e un ciclo maker-checker. Le implementazioni reali li combinano.

I fornitori li chiamano in modi diversi. L’Azure Architecture Center di Microsoft elenca le orchestrazioni sequential, concurrent, group chat, handoff e magentic (in inglese) e osserva che l’handoff si chiama anche routing, triage, transfer, dispatch o delegation. L’OpenAI Agents SDK (in inglese) distingue gli “agenti come strumenti”, in cui un manager mantiene il controllo, dagli “handoff”, in cui lo specialista prende il comando. IBM aggiunge i modelli centralizzato, decentralizzato, gerarchico e federato. Le parole cambiano; le domande per l’assistenza no. La tabella qui sotto descrive ogni modello in termini di assistenza.

La distinzione più importante per chi guida l’assistenza è a chi appartiene il cliente dopo il passaggio. In una configurazione con supervisore, l’agente principale resta responsabile della risposta finale. In un handoff, l’agente che riceve la conversazione ne diventa pienamente responsabile, come spiega la documentazione di Microsoft sull’handoff (in inglese). Questo decide chi ne risponde quando il QA trova una risposta sbagliata.

La tabella dei modelli di orchestrazione: errori e verifiche per l’assistenza

Ogni modello di orchestrazione sbaglia a modo suo, quindi ognuno richiede la sua verifica. La tabella associa ogni modello a un esempio di assistenza, all’errore da aspettarsi e a che cosa guardare in revisione. La copi nel suo piano QA e tenga le righe che corrispondono a come sono collegati oggi i suoi agenti.

Modello	Come funziona	Esempio nell’assistenza	Errore tipico	Che cosa verificare
Router (smistamento)	Un agente di smistamento classifica la richiesta e la passa a un solo specialista	“Dov’è il mio rimborso?” va all’agente Fatturazione	Smistamento sbagliato: l’agente Ordini risponde con sicurezza a una domanda di fatturazione	Il primo smistamento era giusto? Lo specialista è rimasto nel suo perimetro?
Supervisore (manager)	Un agente principale mantiene la conversazione e richiama gli specialisti come strumenti	L’agente principale chiede all’agente Policy se un reso tardivo è consentito	Il principale ignora o riscrive la risposta dello specialista; il cliente riceve un misto delle due	La risposta finale corrisponde a ciò che lo specialista ha restituito?
Sequenziale (pipeline)	Passaggi fissi, ognuno usa l’output del precedente	Verificare l’identità, controllare i requisiti, emettere il rimborso, inviare il riepilogo	Un errore iniziale si propaga in ogni passaggio (un ID ordine sbagliato porta al rimborso sbagliato)	L’output di ogni passaggio è stato convalidato prima che il successivo lo usasse?
Concorrente (parallelo)	Più agenti lavorano contemporaneamente sullo stesso messaggio	La stesura della risposta e una verifica di policy procedono in parallelo	Risultati contraddittori uniti male; il cliente vede due risposte	Quando gli agenti non concordavano, quale ha prevalso, e la regola era giusta?
Gerarchico	Supervisori gestiscono team di agenti per dominio	Un supervisore logistica smista tra un agente tracking e un agente resi	Una richiesta cade tra due supervisori e nessuno ne è responsabile	C’è un unico responsabile per ogni percorso, a ogni livello?
Handoff tra agenti	Ogni agente decide quando passare la conversazione	L’agente Ordini passa un caso di articolo danneggiato all’agente Resi	Loop (da A a B ad A), contesto perso, il cliente deve ripetere due volte gli stessi dati	Quanti passaggi? Qualche agente è comparso due volte? Il cliente ha ripetuto informazioni?
Passaggio a una persona	Un agente passa la conversazione a una persona con un riepilogo	L’agente Resi passa a un operatore un addebito contestato	Escalation troppo tardiva, o senza riepilogo, quindi l’operatore riparte da zero	Segnale giusto, momento giusto, e l’operatore aveva il contesto che gli serviva?
Maker-checker	Un agente redige, un altro approva o rimanda indietro	Un agente redige un’offerta di cortesia; un controllore la verifica rispetto alla policy	Il controllore approva una bozza sbagliata, o il ciclo gira fino al limite e invia comunque l’ultima versione	Che cosa fa il controllore quando raggiunge il limite di iterazioni?

Gli handoff tra agenti hanno il rischio più alto di loop e contesto perso, e i passaggi alle persone sono il punto in cui i clienti notano per primi l’errore. La nostra guida su come valutare il passaggio tra AI e operatore approfondisce quella riga.

Dove si rompono le conversazioni di assistenza multi-agente?

Le conversazioni di assistenza multi-agente si rompono nei punti di giunzione tra gli agenti, non al loro interno. I quattro errori che contano di più sono il contesto perso in un passaggio, i loop tra agenti, l’agente sbagliato che agisce su una richiesta e una conversazione chiusa prima che il problema sia risolto. Ognuno può verificarsi mentre ogni singolo agente sembra corretto.

Contesto perso. I passaggi trasmettono meno di quanto la maggior parte dei team immagini. Nell’orchestrazione handoff di Microsoft Agent Framework, i messaggi dell’utente e degli agenti vengono sincronizzati tra gli agenti, ma i contenuti legati agli strumenti non vengono diffusi. L’agente successivo vede ciò che è stato detto, non necessariamente ciò che l’agente precedente ha cercato o fatto. Se l’agente Fatturazione non vede l’ordine recuperato dall’agente Ordini, chiede di nuovo al cliente, oppure lavora su un’ipotesi.

Loop. Due agenti possono rimandarsi una richiesta a vicenda, o un agente può ripetere lo stesso passaggio. La guida all’architettura di Microsoft indica i loop di handoff infiniti tra le insidie del modello handoff e raccomanda limiti di iterazione per i cicli. In modalità autonoma, il suo framework di handoff consente per impostazione predefinita a ogni agente fino a 50 turni prima di richiedere un input dell’utente, molto più di quanto qualsiasi cliente sopporterà.

L’agente sbagliato che agisce. Una richiesta smistata male arriva a un agente che risponde con sicurezza fuori dal suo dominio. La risposta è fluida, quindi nessuno se ne accorge a meno che qualcuno non la confronti con la policy giusta.

Chiusa troppo presto. Gli agenti possono fermarsi prima che il lavoro sia finito, o non sapere affatto quando hanno finito.

La ricerca lo conferma. Un articolo scientifico del 2025, Why Do Multi-Agent LLM Systems Fail? (in inglese), ha annotato 1.642 tracce di esecuzione di sette framework e ha individuato 14 modalità di errore. La ripetizione di passaggi compariva nel 15,7% delle tracce, il mancato riconoscimento del completamento del task nel 12,4% e la perdita di contesto nel 2,8%. Gli autori hanno anche rilevato che le esecuzioni riuscite non sono prive di errori. Le tracce venivano da task di programmazione, matematica e di tipo generale, non dal servizio clienti, quindi tratti queste quote come un avvertimento, non come un benchmark. La lezione vale comunque: un esito “risolto” può nascondere errori lungo il percorso, come mostra il nostro articolo sugli errori silenziosi degli agenti AI.

Che cosa monitorare in un’assistenza orchestrata?

Monitori il percorso, non solo ogni agente. I punteggi per agente mostrano se l’agente Fatturazione risponde bene alle domande di fatturazione, non che i clienti sono rimbalzati tra tre agenti prima di arrivarci. Segua invece un piccolo insieme di segnali sul percorso: passaggi, loop, dati del cliente ripetuti, accuratezza del primo smistamento, escalation con contesto e la differenza tra risoluzione a livello di agente e a livello di percorso.

Le regole di partenza qui sotto sono nostre, non uno standard di settore: misuri il suo livello di riferimento per quattro settimane, poi le adatti.

Segnale	Come misurarlo	Regola di partenza
Passaggi per conversazione	Conti i cambi di agente nel log della conversazione	Riveda ogni conversazione con più di 3 passaggi
Agente ripetuto (loop)	Lo stesso agente compare due volte in una conversazione, con un altro agente in mezzo	Le riveda tutte; ogni tendenza in crescita è un bug di smistamento
Tasso di nuove richieste	Il cliente fornisce due volte lo stesso identificativo (numero d’ordine, email)	Indaghi se supera il 5% delle conversazioni multi-agente
Accuratezza del primo smistamento	Quota dei primi smistamenti che un revisore giudica corretti	Indaghi sul router se è sotto il 90%
Escalation con contesto	Quota dei passaggi a una persona in cui l’operatore non ha dovuto chiedere di nuovo	Punti al 95% o più
Divario di risoluzione	Tasso di “risolto” per agente meno il tasso di risolto correttamente a livello di percorso	Un divario sopra i 5 punti significa che gli errori si nascondono tra gli agenti
Limite di turni o iterazioni raggiunto	Conversazioni terminate perché è stato raggiunto un limite	Le riveda tutte; sono loop bloccati

Le indicazioni di Microsoft dicono la stessa cosa dal lato ingegneristico: strumentare tutte le operazioni degli agenti e tutti i passaggi, e usare rubriche di valutazione o la valutazione con un modello come giudice invece dei test a corrispondenza esatta, perché gli output degli agenti variano. Per dashboard e allerte, veda la nostra guida sul monitoraggio degli agenti AI.

Come si fa il controllo qualità di un percorso che attraversa più agenti e persone?

Per fare il controllo qualità di un percorso multi-agente, renda l’intera conversazione l’unità di revisione. Riunisca ogni segmento di agenti e persone in un unico record, valuti ogni segmento rispetto al suo compito, valuti i punti di giunzione con criteri di percorso e attribuisca ogni errore al segmento che lo ha causato. Poi corregga quella parte e rivaluti.

Passo 1: ricomporre il percorso. Un unico ID di conversazione segue il cliente attraverso ogni agente e ogni persona. Se i suoi agenti registrano i dati in posti diversi, il primo compito del QA è portare la trascrizione completa, con il nome dell’agente su ogni turno, nell’helpdesk o in un’unica coda di revisione.

Passo 2: valutare ogni segmento rispetto al suo compito. Accuratezza della fatturazione per l’agente Fatturazione, smistamento per l’agente di smistamento, risoluzione per l’operatore. Un nucleo comune di criteri mantiene confrontabili i segmenti umani e quelli dell’AI; la nostra guida su un’unica scheda di valutazione per operatori e agenti AI mostra come costruirla.

Passo 3: aggiungere i criteri di percorso. Sono le domande a cui nessun singolo segmento può rispondere:

Il primo smistamento era corretto?
Il cliente ha dovuto ripetere qualche dato?
Qualche agente è comparso due volte, o la conversazione è andata in loop?
Ogni passaggio ha trasmesso i dati di cui l’agente successivo aveva bisogno?
Se è subentrata una persona, l’escalation è avvenuta sul segnale giusto, con un riepilogo utilizzabile?
Alla fine il problema reale del cliente era risolto, chiunque lo abbia risolto?

Passo 4: attribuire l’errore. Ogni percorso fallito riceve un unico segmento causa: il router, uno specialista, il meccanismo di passaggio o l’operatore. Senza attribuzione, un errore di percorso è un problema di tutti e una correzione di nessuno.

Passo 5: correggere e rivalutare. Mandi quanto emerso al responsabile di quella parte (prompt, regola di smistamento, articolo della knowledge base, segnale di escalation), poi rivaluti lo stesso tipo di percorso per confermare che la correzione regge. Testi le modifiche prima che vadano in produzione; veda la nostra guida sui test degli agenti AI.

Un esempio concreto (illustrazione, numeri inventati per mostrare il calcolo)

Un team di assistenza gestisce 40.000 conversazioni al mese con un agente di smistamento, tre agenti specialisti e un team di operatori:

26.000 conversazioni (65%) passano dallo smistamento a un solo specialista e si chiudono lì.
10.000 (25%) attraversano due o più agenti AI.
4.000 (10%) si chiudono con un operatore.

Le dashboard per agente sembrano in salute: ogni specialista supera oltre il 90% dei propri criteri. Poi il responsabile QA valuta un campione casuale di 200 percorsi multi-agente con i criteri di percorso descritti sopra. 34 non li superano (17%): 14 clienti hanno ripetuto il numero d’ordine, 9 conversazioni sono tornate allo smistamento, 6 hanno ricevuto risposta dallo specialista sbagliato e 5 sono state chiuse prima che il rimborso fosse confermato.

Su scala, il 17% di 10.000 corrisponde a circa 1.700 percorsi falliti al mese. Se i percorsi con un solo agente falliscono al 5%, sono 1.300 errori su 26.000. Il quarto di conversazioni che attraversa più agenti produce più errori dei due terzi che non lo fanno.

Il campione mostra anche i limiti del campionamento. Con 200 conversazioni e un tasso di errore del 17%, il margine di errore al 95% è di circa più o meno 5,2 punti (1,96 × √(0,17 × 0,83 / 200)). L’intervallo al 95% va da circa 1.200 a 2.200 percorsi falliti. E le 14 nuove richieste indicano un’unica correzione: il risultato della ricerca dell’agente Ordini non arriva all’agente Fatturazione nel passaggio.

Lo veda sulle sue conversazioni. Kaizo valuta il 100% delle sue conversazioni di assistenza, di operatori e agenti AI, con la sua scheda di valutazione e collega ogni punteggio alle prove nella conversazione. Prenoti una demo.

Quale framework o piattaforma di orchestrazione degli agenti AI scegliere?

Il miglior framework di orchestrazione degli agenti AI è quello che il fornitore dei suoi agenti o il suo team di sviluppo supporta già bene; chi guida l’assistenza raramente lo sceglie da solo. Ciò che deve fissare sono i requisiti: smistamento visibile per conversazione, contesto trasmesso nei passaggi, limiti di turni, escalation verso una persona con riepilogo e trascrizioni che arrivano dove lavora il suo team QA.

Le opzioni rientrano in tre gruppi:

Integrata nella sua piattaforma di agenti AI. Le piattaforme di agenti per il servizio clienti smistano tra i propri agenti e verso il suo team di operatori. Meno lavoro, meno controllo.
Framework per sviluppatori. Microsoft Agent Framework, l’OpenAI Agents SDK, LangChain e CrewAI, tra gli altri. Controllo completo, e ogni regola è a carico dei suoi ingegneri.
Livelli di orchestrazione enterprise. Prodotti come IBM watsonx Orchestrate coordinano agenti, strumenti e workflow da un unico livello centrale per tutta l’azienda.

In qualunque gruppo si trovi, ponga cinque domande prima della messa in produzione:

Possiamo vedere, per ogni conversazione, quale agente ha agito a ogni turno e perché ha passato la conversazione?
Che cosa viene trasmesso esattamente in un passaggio: la trascrizione, un riepilogo, i risultati degli strumenti, i dati del cliente?
Quali sono i limiti di turni e di iterazioni, e che cosa succede quando se ne raggiunge uno?
Come subentra una persona, e che cosa vede per prima cosa?
Dove finisce la trascrizione completa, e il nostro team QA può valutarla lì?

Se la risposta è “non possiamo mostrarvelo”, non potrà fare nemmeno il controllo qualità del percorso.

Quando l’orchestrazione multi-agente non fa per lei?

L’orchestrazione multi-agente non fa per lei quando un solo agente AI ben delimitato, con gli strumenti giusti e un percorso di escalation chiaro, può gestire il suo volume. Le indicazioni di Microsoft dicono di usare il livello di complessità più basso che soddisfa in modo affidabile i requisiti, e considerano un singolo agente con strumenti spesso la scelta predefinita giusta per i casi d’uso enterprise. Ogni agente in più aggiunge passaggi, latenza, costi e modalità di errore.

Chi lavora nel customer success lo dice in modo simile nei forum di settore: i risultati arrivano di solito da un agente AI che gestisce bene un insieme ristretto di domande, non da uno che cerca di coprire tutto. Se il suo agente AI gestisce qualche centinaio di conversazioni al mese in un solo dominio, lasci perdere l’orchestrazione, legga le trascrizioni ogni settimana e dedichi l’impegno alla knowledge base e al segnale di escalation.

Lo smistamento in sé arriva dalla sua piattaforma di agenti o da uno dei framework citati sopra. Il ruolo di Kaizo inizia dopo la conversazione: valuta le conversazioni risolte da Zendesk o Salesforce con la sua scheda di valutazione.

Come iniziare questa settimana

Può iniziare a rivedere i percorsi orchestrati questa settimana senza nuovi strumenti: disegni come sono collegati i suoi agenti, poi valuti un piccolo insieme di percorsi multi-agente con i criteri di percorso. L’obiettivo della prima settimana non è una dashboard; è trovare il punto di giunzione che si rompe più spesso.

Disegni i collegamenti. Elenchi ogni agente AI, chi può passare la conversazione a chi e dove intervengono le persone, con il modello corrispondente nella tabella qui sopra.
Prenda 30 percorsi multi-agente, più 10 che si sono chiusi con un operatore.
Li valuti con i sei criteri di percorso, annotando il segmento causa per ogni errore.
Scelga il punto di giunzione peggiore. Di solito un passaggio che perde il contesto o una regola di smistamento che sbaglia.
Nomini un responsabile per ogni agente e ogni regola di passaggio.

Quando la revisione manuale conferma lo schema, la automatizzi. Il controllo qualità degli agenti AI di Kaizo valuta le conversazioni degli agenti AI con la stessa scheda di valutazione del suo team, compresi i criteri sui passaggi, come il fatto che l’agente abbia passato la conversazione sul segnale giusto e trasmesso il contesto, e AutoPilot valuta ogni conversazione nel momento in cui viene risolta. Per il quadro più ampio, parta dalla nostra guida sull’assistenza clienti agentica; per le regole che quegli agenti seguono, veda la governance degli agenti AI.

Domande frequenti

ChatGPT è un agente o un LLM?

ChatGPT è un prodotto costruito su modelli linguistici di grandi dimensioni (LLM). Quando risponde a una singola domanda, si comporta come un’interfaccia di chat verso un LLM. Quando usa strumenti, naviga sul web o porta avanti da solo un task in più passaggi, si comporta come un agente. La differenza sta in ciò che il sistema può fare, non nel modello.

Qual è la differenza tra un sistema multi-agente e l’IA agentica?

L’IA agentica descrive un’AI che agisce verso un obiettivo con una certa autonomia. Un sistema multi-agente è un modo per costruirla: più agenti specializzati, coordinati dall’orchestrazione, invece di un solo agente che fa tutto. Anche un singolo agente può essere agentico; un sistema multi-agente aggiunge i passaggi, e con loro i punti di giunzione da verificare.

Kubernetes è uno strumento di orchestrazione?

Sì, ma per i container, non per gli agenti AI. Kubernetes pianifica e scala il software che fa funzionare i suoi servizi. L’orchestrazione degli agenti AI decide quale agente gestisce quale parte di una conversazione e quale contesto riceve. Un sistema di agenti può girare su Kubernetes, ma Kubernetes non smista le richieste tra gli agenti.

Che cos’è un livello di orchestrazione degli agenti AI?

Il livello di orchestrazione sta sopra i singoli agenti e decide smistamento, trasmissione del contesto, permessi e regole di arresto. Può essere un agente principale, un framework nel suo codice o un prodotto centrale. Per il QA, dovrebbe fornire anche la registrazione di chi ha agito e perché.

Come si valuta un sistema multi-agente per il servizio clienti?

Lo valuti su due livelli: ogni agente rispetto al suo compito, e l’intero percorso rispetto a criteri come primo smistamento corretto, nessun dato ripetuto, nessun loop ed esito finale corretto. La nostra guida sulla valutazione degli agenti AI tratta i metodi, dai set di test alla valutazione delle conversazioni reali.