AI agentica in azienda: perché l'orchestrazione è il problema più difficile di cui nessuno parla

La distanza tra demo e realtà

Apri il pitch deck di un qualsiasi fornitore di AI nel 2026 e troverai sempre la stessa slide: un bel diagramma in cui l'Agente A passa con eleganza la conversazione all'Agente B, che si coordina con l'Agente C, e il cliente vive un'esperienza perfetta. Il CEO in sala annuisce soddisfatto. "Facciamolo."

Progetto questo tipo di architetture per un sistema che gestisce decine di migliaia di conversazioni al giorno. E posso dirti esattamente che aspetto ha quel bel diagramma in produzione: un groviglio di casi limite, catene di fallback e problemi di gestione dello stato che nessuno disegna mai su una slide.

Gli agenti in sé, cioè gli LLM, i modelli con fine-tuning, le pipeline RAG, sono la parte facile. È nell'orchestrazione tra di loro che un sistema sopravvive o muore.

Cosa significa davvero orchestrare

Orchestrare vuol dire rispondere a queste domande in tempo reale, migliaia di volte all'ora:

Quale agente gestisce questa richiesta?
E se la richiesta è ambigua?
Quale contesto deve seguire la richiesta da un agente all'altro?
Cosa succede se un agente si blocca a metà conversazione?
Quando l'AI si arrende e passa la conversazione a una persona?
Come fa l'operatore a sapere cosa è successo prima del suo arrivo?

Ognuna di queste domande ha una risposta semplice in teoria e una complicata in produzione.

I quattro problemi difficili

1. Le decisioni di routing

"Manda le domande sulla fatturazione all'agente billing e quelle tecniche all'agente di supporto." Semplice, no?

Adesso gestisci questa: "Mi avete addebitato qualcosa che non funziona." È fatturazione o un problema tecnico? Entrambe le cose. Nessuna delle due. La logica di routing per le richieste ambigue è spesso più complessa degli agenti stessi.

Il nostro livello di routing usa un classificatore leggero (non l'LLM completo, che sarebbe troppo lento) per prendere la prima decisione di instradamento in meno di 50 ms. Ma abbiamo anche un meccanismo di re-routing: se a metà conversazione un agente capisce che la richiesta va gestita altrove, può trasferirla insieme al contesto. Progettare quel protocollo di trasferimento ha richiesto più tempo che costruire gli agenti.

La sfumatura che quasi tutti si perdono: il routing non è una decisione che si prende una volta sola. In una conversazione di 5 minuti il cliente può partire da una domanda sulla bolletta, passare a un problema tecnico e chiudere con un reclamo. L'orchestratore deve gestire queste transizioni senza costringere il cliente a ripetersi.

2. La gestione dello stato

Il cliente comunica il numero di conto all'Agente A. L'Agente A lo instrada all'Agente B per una richiesta specialistica. L'Agente B chiede di nuovo il numero di conto.

Sembra una banalità. Non lo è.

Gestire lo stato tra più agenti significa:

Definire uno schema di contesto condiviso che tutti gli agenti possano leggere e scrivere
Gestire i conflitti (l'Agente A dice che il cliente è arrabbiato, l'analisi del tono dell'Agente B dice che è neutro: chi ha ragione?)
Decidere quale parte dello stato sopravvive a un trasferimento e quale viene scartata
Gestire lo stato tra stack tecnologici diversi (l'agente di autenticazione può essere codice deterministico, quello delle FAQ un LLM, quello dei reclami un altro LLM con prompt diversi)

Usiamo uno store centralizzato dello stato della conversazione, con versioning. Ogni agente legge e scrive sullo stesso oggetto di stato, ma ha accesso solo ai campi che gli servono: nessun agente vede il quadro completo. È insieme una misura di sicurezza e un modo per ridurre la complessità.

3. Il passaggio dall'AI all'operatore

La transizione più difficile non è AI→AI. È AI→persona.

Quando il nostro assistente digitale passa la conversazione a un operatore, quella persona deve capire cosa è successo. E le serve in un formato che si legge in 3 secondi: non la trascrizione completa, non un log grezzo, non "il cliente chiedeva della fatturazione".

Generiamo un riepilogo di passaggio strutturato:

Intento del cliente: cosa sta cercando di fare (1 frase)
Cosa ha provato l'AI: i passi compiuti fin qui
Perché passa all'operatore: cosa è andato storto o cosa l'AI non può fare
Sentiment del cliente: calmo / frustrato / arrabbiato
Contesto del conto: i dati rilevanti già verificati

Il riepilogo viene generato da una chiamata LLM separata, tarata apposta per questo tipo di sintesi. Aggiunge circa 200 ms al trasferimento, ma fa risparmiare all'operatore 2-3 minuti di "mi faccia capire cosa sta succedendo".

4. Le catene di fallback

Quando l'agente GenAI non riesce a gestire qualcosa, ripiega su regole deterministiche. Quando anche queste falliscono, passa la conversazione a una persona. È nella progettazione di questi percorsi di fallback che l'architettura vive o muore.

La nostra catena di fallback:

Agente GenAI primario: gestisce la richiesta in modo generativo
Controllo di confidenza: se la confidenza interna dell'agente è sotto soglia, la risposta viene segnalata per una verifica
Fallback deterministico: le risposte segnalate vengono confrontate con un sistema a regole
Degradazione controllata: se nemmeno le regole trovano una corrispondenza, al cliente vengono offerte opzioni limitate ("Posso aiutarla con X, Y o Z, oppure metterla in contatto con uno specialista")
Passaggio all'operatore: se il cliente insiste o il sistema ha fallito due volte, trasferimento immediato

La decisione di design cruciale: dove fissi la soglia di confidenza? Troppo alta e passa tutto all'operatore (vanificando lo scopo dell'AI). Troppo bassa e le allucinazioni arrivano ai clienti. Noi la ritariamo ogni settimana sulla base dei dati di produzione.

L'architettura che uso davvero

Livello 1: Router deterministico
├── Flussi di autenticazione (hard-coded)
├── Flussi transazionali (hard-coded)
└── Controlli di sicurezza (a regole)

Livello 2: Agente GenAI di triage
├── Comprende la richiesta
├── Instrada all'agente specialista
└── Gestisce direttamente le richieste semplici

Livello 3: Agenti specialisti
├── Agente FAQ (basato su RAG)
├── Agente troubleshooting (diagnosi guidata)
├── Agente reclami (empatico, strutturato)
└── Agente vendite (raccomandazioni di prodotto)

Livello 4: Passaggio all'operatore
├── Riepilogo del contesto generato dall'AI
├── Instradamento prioritario in base al sentiment
└── Storico completo della conversazione disponibile

Ogni livello ha criteri di ingresso e uscita chiari. Nessun agente può scavalcare il livello deterministico di sicurezza. Ogni agente può passare al Livello 4. L'orchestratore gestisce le transizioni tra tutti i livelli.

Perché non dovresti ancora andare full agentic

Il mio consiglio sincero: parti con un agente GenAI che sostituisce un solo flusso. Dimostra che funziona. Misuralo come si deve. Poi aggiungi un secondo agente. Poi aggiungi l'orchestrazione tra i due.

L'approccio "costruiamo una flotta di 10 agenti specializzati" fallisce perché non puoi fare debug di 10 agenti contemporaneamente. Quando qualcosa va storto in una conversazione multi-agente, e qualcosa va sempre storto, devi ripercorrere ogni decisione di routing, ogni modifica dello stato, ogni risposta degli agenti. Con 10 agenti, la superficie di debug cresce in modo esponenziale.

Noi siamo partiti con 1. Oggi ne abbiamo 4 in produzione. Aggiungere il quinto ha richiesto la metà del tempo che ci era servito per il secondo, perché avevamo già costruito i pattern di orchestrazione. Ma non avremmo mai potuto partire da 5.

La verità scomoda

Tutti parlano di agenti. I palchi delle conferenze sono pieni di slide sulle architetture multi-agente. LinkedIn è pieno di post su "l'AI agentica è il futuro".

Nessuno parla di cosa succede quando l'Agente 3 ha un'allucinazione e l'Agente 4 si fida di quell'allucinazione. O quando il livello di routing manda un reclamo all'agente vendite. O quando lo store dello stato perde il contesto a metà trasferimento e il cliente deve ripetere tutto da capo.

Questa è l'orchestrazione. Questa è la parte difficile. Ed è la parte che separa i sistemi in produzione dalle demo.

Stai costruendo un sistema multi-agente? Dai un'occhiata ai miei prodotti digitali per le organizzazioni che portano l'AI conversazionale su larga scala. Facciamo in modo che il tuo livello di orchestrazione non diventi il tuo single point of failure.