Perché il tuo agente IA a contatto con i clienti ha bisogno di un modello di fallback

Un agente IA a contatto con i clienti ha bisogno di un modello di fallback perché prima o poi ogni modello fallisce nel momento peggiore: il provider ha un’interruzione, il tuo account raggiunge un limite di frequenza, una richiesta va in timeout oppure una conversazione insolita consuma più token del previsto. Senza fallback l’agente resta muto e il cliente aspetta. Con un fallback, un secondo modello subentra e la conversazione prosegue. In Agent Harness di MonoChat, ogni nodo Agente IA ha un modello principale, un modello di fallback e un modello veloce, oltre a un limite di budget per esecuzione.

Questo articolo spiega perché i guasti dei modelli contano più nella messaggistica con i clienti che altrove, come funziona il fallback, come scegliere un modello di fallback e come si integra con modelli veloci, budget e passaggio a un operatore.

Perché i guasti dei modelli fanno più danni nelle conversazioni con i clienti

In uno strumento interno, una richiesta IA fallita è un fastidio: clicchi su riprova. In una conversazione con un cliente su WhatsApp è una promessa non mantenuta. Il cliente ha fatto una domanda, ha visto la doppia spunta blu e aspetta una risposta.

Alcuni fattori rendono la messaggistica con i clienti particolarmente delicata:

• I clienti non riprovano. Scrivono di nuovo, più irritati, oppure se ne vanno.
• Il traffico è a picchi. Una campagna, un ritardo nelle consegne o una promozione possono moltiplicare le conversazioni in pochi minuti, ed è proprio allora che i limiti di frequenza si fanno sentire.
• Gli agenti fanno molte chiamate. Un agent harness esegue il modello in un ciclo, spesso più volte per ogni messaggio del cliente. Una sola chiamata fallita può bloccare l’intera esecuzione.
• I tempi contano su WhatsApp. Le risposte libere sono consentite solo entro 24 ore dall’ultimo messaggio del cliente. Uno stallo prolungato può spingere una risposta fuori dalla finestra, dove servirebbe un template approvato.

Nulla di tutto questo dipende dal fatto che un provider in particolare sia inaffidabile. Ogni provider ha incidenti, manutenzioni e limiti di capacità. La questione è solo se il tuo agente ha un piano per affrontarli.

Cosa può andare storto

Interruzioni del provider. Parziali o totali, brevi o lunghe. Anche una disponibilità mensile del 99,9% ammette più di 40 minuti di inattività.

Limiti di frequenza. Il tuo account può consentire un certo numero di richieste o token al minuto. Un’ora di punta può raggiungere quel tetto anche quando il provider funziona regolarmente.

Timeout e risposte lente. Un modello che di solito risponde in due secondi può impiegarne venti sotto carico. Per un cliente al telefono è come se non succedesse nulla.

Esecuzioni fuori controllo. Un agente che va in loop su una richiesta confusa, o una conversazione che continua a crescere, può consumare molto più di un’esecuzione normale.

Cambi di modello. I provider aggiornano e ritirano i modelli. Un comportamento su cui contavi può cambiare con poco preavviso.

Come funziona il fallback in un agente

L’idea è semplice: quando il modello principale non riesce a portare a termine il lavoro, subentra un secondo modello. In MonoChat il modello di fallback subentra dopo un limite soft o quando il modello principale fallisce. La conversazione, gli strumenti e le istruzioni restano gli stessi; cambia solo il modello che svolge il lavoro.

In ogni nodo Agente IA collaborano tre ruoli:

Ruolo	Cosa fa
Modello principale	Ragiona, decide e scrive le risposte
Modello di fallback	Subentra dopo un limite soft o un guasto
Modello veloce	Gestisce il lavoro in background

Oltre ai ruoli, un limite di budget per esecuzione fissa un tetto a ciò che una singola conversazione può spendere.

Come scegliere un modello di fallback

Preferisci un provider diverso

Un fallback dello stesso provider ti protegge se un singolo modello si comporta male, ma non da un incidente dell’intero provider o da un limite di frequenza sul tuo account presso quel provider. Un modello di un secondo provider copre entrambi i casi. MonoChat ti permette di collegare più provider tramite gli LLM personalizzati, quindi è una scelta di configurazione, non un progetto.

Scegline uno abbastanza valido, non identico

Il fallback non deve essere il miglior modello disponibile. Deve seguire le tue istruzioni, chiamare correttamente i tuoi strumenti e scrivere una risposta dignitosa. Provalo da solo sulle tue conversazioni reali, come se fosse il modello principale, prima di affidarti a lui.

Verifica che gestisca i tuoi strumenti

Gli agenti dipendono dalle chiamate agli strumenti: cercare un ordine, controllare uno slot, creare un ticket. Alcuni modelli sono molto più bravi di altri nelle chiamate strutturate. Un fallback che scrive testi bellissimi ma chiama male gli strumenti è peggio di nessun fallback.

Considera le lingue che servi

Se i tuoi clienti scrivono in turco, arabo o spagnolo, assicurati che il fallback scriva quelle lingue bene quanto il modello principale. Un cambio improvviso di qualità o di tono si nota.

Valuta il costo in entrambe le direzioni

Un fallback più economico riduce il costo delle esecuzioni lunghe o insolite che superano un limite soft. Un fallback più costoso può andare bene se gestisce solo guasti rari. Decidi quale compito vuoi che svolga il fallback.

Il modello veloce: l’altra metà dell’affidabilità

Non ogni passaggio richiede il tuo modello migliore. Il lavoro in background, cioè le attività attorno alla conversazione e non la risposta in sé, può girare su un modello più piccolo e rapido. Così si riservano la capacità e il budget del modello principale a ciò che il cliente vede davvero, e si riduce la probabilità di raggiungere un limite di frequenza sul modello principale nelle ore di punta.

In pratica: usa il tuo modello di ragionamento più forte come principale, un modello solido di un secondo provider come fallback e un modello veloce ed economico per il lavoro in background.

Budget: la rete di sicurezza sotto la rete di sicurezza

Il fallback mantiene l’agente al lavoro. I budget lo mantengono sostenibile. Un limite di budget per esecuzione significa che nessuna conversazione, per quanto strana, può spendere più di quanto hai previsto. Combinato con un limite soft oltre il quale subentra il fallback, ottieni uno schema prevedibile: le conversazioni normali girano sul modello principale, quelle lunghe proseguono sul fallback e nulla sfugge di mano.

Con le chiavi dei tuoi provider, MonoChat non aggiunge alcun ricarico sull’IA, quindi ciò che metti a budget è ciò che i tuoi provider addebitano.

Il fallback non è il passaggio a un operatore

È facile considerare un modello di fallback la risposta a ogni problema. Non lo è. Un fallback risolve i guasti tecnici: il modello è fuori servizio, lento o senza budget. Il passaggio a un operatore risolve i problemi di discernimento: un reclamo, una questione legale, un rimborso oltre il tuo limite o un cliente che semplicemente chiede una persona.

In MonoChat l’agente gira all’interno di un flusso, quindi il passaggio all’inbox condivisa del tuo team con tutta la cronologia è sempre disponibile. WhatsApp si aspetta inoltre che le risposte automatiche offrano una via chiara verso una persona. Progetta entrambi i percorsi:

1. Il modello principale fallisce o raggiunge un limite soft → il modello di fallback prosegue.
2. Il caso richiede una persona → passaggio al team giusto con la cronologia della conversazione.
3. Falliscono entrambi → il flusso dice al cliente che una persona risponderà e instrada la conversazione all’inbox.

Una semplice checklist

• Modello principale scelto per qualità sulle tue conversazioni reali.
• Modello di fallback di un secondo provider, provato da solo con i tuoi strumenti e le tue lingue.
• Modello veloce per il lavoro in background.
• Limite di budget per esecuzione in linea con il costo di una conversazione normale, con un certo margine.
• Regole chiare di passaggio a un operatore nelle istruzioni dell’agente e nel flusso.
• Una revisione di un campione di conversazioni dopo la prima settimana, comprese quelle gestite dal fallback.

Configuralo una volta, per ogni canale

Poiché il nodo Agente IA vive in un flusso MonoChat, gli stessi modelli principale, di fallback e veloce proteggono il tuo agente su WhatsApp, Instagram, Messenger, TikTok, Telegram, chat web, SMS e voce. E poiché Agent Harness ti permette di scegliere il framework, lo stesso approccio funziona sia che il tuo agente giri sull’harness integrato di MonoChat, su Claude Agent SDK, su OpenAI Agents SDK, su Pi o sul tuo framework.

Scopri come si combinano i ruoli dei modelli nella pagina Agent Harness.