Come Progettare Percorsi di Escalation per Agenti AI

Un agente AI dovrebbe escalare a un essere umano ogni volta che supera un limite di confidenza predefinito, interagisce con denaro o azioni irreversibili, oppure riceve un pattern di input al di fuori di quelli per cui è stato progettato. Se non si pianifica questo momento prima del rilascio, lo si scoprirà attraverso le lamentele di un cliente arrabbiato.

Perché "renderlo più preciso" non è la soluzione

La maggior parte dei team tratta l'escalation come un modo di fallire da eliminare, piuttosto che come una funzionalità da costruire. L'istinto è: se l'agente sbaglia a volte, aggiungiamo più esempi di addestramento, ottimizziamo il prompt, aggiungiamo un altro retry. Funziona fino a un certo punto, poi si raggiungono i rendimenti decrescenti, perché una certa quota di input reali è genuinamente ambigua. Una richiesta di rimborso che cita un'eccezione di policy. Un messaggio di supporto in un dialetto che il modello gestisce male. Un lead commerciale la cui intenzione non corrisponde ad alcuna delle categorie di qualificazione.

Nessuna ottimizzazione del prompt elimina l'ambiguità dal mondo. Ciò che si può controllare è il comportamento dell'agente quando la incontra: procedere per tentativi sperando nel meglio, oppure fermarsi e chiedere.

Procedere per tentativi è economico finché non va storto. E il problema si amplifica se l'agente opera in una catena, poiché un'ipotesi errata a metà percorso può compromettere tutto ciò che viene a valle (si veda agenti AI vs. workflow per capire perché le catene falliscono diversamente dai sistemi a singola chiamata). Un agente che escala invece di fare ipotesi costa una piccola latenza aggiuntiva sui casi difficili, e nulla su quelli facili.

Cosa attiva davvero una buona escalation

Tre segnali meritano di essere modellati, e sono meccanicamente distinti tra loro:

• Soglia di confidenza. Un segnale di confidenza non deve necessariamente essere un punteggio di probabilità che il modello riporta su sé stesso. Può essere qualcosa calcolato esternamente, come il numero di fatti concreti che l'agente ha effettivamente estratto prima di agire. Questo è esattamente il meccanismo del gate dell'agente di outreach descritto più avanti: non "il modello è sicuro", ma "ha abbastanza materiale su cui lavorare". Al di sotto della soglia stabilita, si interrompe e si instrada a un essere umano invece di restituire la risposta più probabile.
• Classificazione per impatto. Categorizzare le azioni per raggio d'impatto prima che l'agente le esegua, non dopo. Inviare un'email basata su template è a basso rischio. Emettere un rimborso su una richiesta che cita un'eccezione di policy, o messaggiare un cliente su qualcosa con implicazioni legali, è ad alto rischio. Le azioni ad alto rischio hanno una soglia di autonomia più bassa indipendentemente dalla confidenza, perché avere il 90% di certezza non è sufficiente quando il 10% di fallimento è costoso o irreversibile.
• Rilevamento out-of-distribution. Tracciare ciò che l'agente ha effettivamente incontrato in produzione. Un messaggio di supporto in un dialetto su cui il modello non è stato ottimizzato, o un lead commerciale la cui intenzione non corrisponde ad alcuna categoria di qualificazione, sono entrambi out-of-distribution nello stesso modo: l'input non somiglia affatto al set di addestramento o di valutazione, e questo è un segnale indipendente da quanto il modello dichiari di essere sicuro della propria risposta.

Nulla di tutto ciò richiede un team di ricerca. Richiede di decidere, in anticipo, come appare "non lo so" per il proprio agente specifico, e di costruire un percorso che non sia un messaggio di errore generico.

Costruire la coda prima di averne bisogno

L'errore più comune che osserviamo, nelle agenzie e nei team interni, è costruire prima il percorso ottimale e aggiungere l'escalation solo dopo che un incidente lo impone. A quel punto è reattiva: un essere umano sta gestendo le conseguenze di un problema invece di intercettarlo al momento della decisione.

Costruire la superficie di escalation come parte dello scope iniziale:

1. Un luogo dove i casi segnalati possano atterrare. Può essere semplice quanto un canale Slack con il contesto completo: l'input grezzo (la richiesta di rimborso con la sua citazione di policy, il messaggio in dialetto, il lead fuori tassonomia), ciò che l'agente ha tentato di fare e perché ha segnalato invece di agire. Non si deve costringere un essere umano a scavare nei log per ricostruire cosa è successo.
2. Un percorso di risoluzione chiaro. Qualcuno deve farsi carico di rispondere alle escalation entro una finestra temporale definita, altrimenti la coda diventa un cimitero e le segnalazioni dell'agente diventano inutili. Se nessuno risponde, l'esperienza del cliente è peggiore di quanto sarebbe stata se l'agente avesse semplicemente fatto un'ipotesi.
3. Un ciclo di feedback verso l'agente. Ogni risoluzione umana è un dato di addestramento. Se la stessa categoria di casi continua a escalare — lo stesso dialetto, lo stesso tipo di lead fuori tassonomia — è un segnale per espandere il perimetro dell'agente su quella categoria, oppure per accettare che richiederà sempre un essere umano e progettare la UX di conseguenza in modo permanente.

Un pattern dal nostro lavoro con gli agenti

Utilizziamo internamente un agente di outreach che analizza il sito di ciascun prospect e redige un'email personalizzata per ogni azienda. Le prime versioni cercavano sempre di produrre una bozza, anche quando la pagina analizzata aveva pochissimo contenuto utile — un sito "coming soon" scarno, o una pagina composta quasi interamente da navigazione senza alcuna descrizione del business. Forzare una bozza da contenuti poveri produceva email generiche e palesemente standardizzate, che nuocevano più di quanto aiutassero.

La soluzione non era un prompt migliore. Era aggiungere un controllo: se i fatti estratti scendevano al di sotto di una soglia minima di specificità, l'agente saltava la bozza e segnalava l'azienda a un essere umano, affinché la ricercasse manualmente o la eliminasse dalla lista. Questo unico gate ha migliorato la qualità media di ciò che veniva effettivamente inviato, perché l'agente ha smesso di forzare output nei casi in cui non aveva nulla di valido da dire. La lezione è generalizzabile: un agente capace di dire "non ho abbastanza materiale su cui lavorare" è più utile di uno che produce sempre qualcosa.

Come questo si inserisce nel perimetro di un progetto

Se si sta valutando un vendor o pianificando uno sviluppo interno, il design dell'escalation dovrebbe emergere nella discussione architetturale iniziale, non come richiesta di modifica dopo il lancio. Chiedete a qualsiasi agenzia che vi propone un agente: cosa succede quando sbaglia, e come lo sa? Se la risposta è "lo monitoreremo e risolveremo i problemi man mano che si presentano", si sta accettando un costo di manutenzione indefinito (si veda la nostra analisi dei costi di manutenzione degli agenti AI). Se la risposta include un meccanismo di confidenza specifico e un handoff umano definito, si tratta di un team che ha ragionato sul fallimento, non solo sulla demo.

Vale anche la pena di verificarlo in relazione al proprio profilo di rischio complessivo. Il design dell'escalation si sovrappone alle stesse domande trattate in una checklist di sicurezza per agenti AI: cosa può fare questo sistema senza un essere umano nel processo decisionale, e chi è responsabile quando compie qualcosa di sbagliato.

In sintesi

L'escalation non è un fallback da aggiungere quando le cose si rompono. È il meccanismo che impedisce alle cose di rompersi in primo luogo, offrendo all'agente una legittima terza opzione oltre a "riuscire" o "fallire in silenzio". Progettarla nello stesso momento in cui si progetta il percorso ottimale, collegarla a trigger concreti (confidenza, impatto, distribuzione degli input), e presidiare la coda come se avesse importanza — perché i casi che vi atterrano sono, per definizione, quelli che il vostro agente non è riuscito a gestire da solo.

Se state definendo il perimetro di un sistema agentivo e volete un secondo parere su dove collocare i confini dell'escalation, parliamone.