Il mio agente di stato ha bisogno di osservabilità, non solo di metriche

Ciao a tutti, Chris Wade qui, di nuovo su agntlog.com. È marzo 2026 e, onestamente, se state ancora pensando di monitorare i vostri agenti nello stesso modo in cui lo facevamo cinque anni fa, state lasciando denaro, sanità mentale e forse anche il vostro lavoro sul tavolo. Il mondo è andato avanti, e anche la vostra strategia dovrebbe farlo. Oggi voglio parlare di qualcosa di specifico, qualcosa che mi ha dato molto fastidio (e mi ha salvato la pelle) ultimamente: Osservabilità per gli Stati degli Agenti, Non Solo Metriche.

So, “osservabilità” è un termine alla moda che viene usato come un frisbee a un picnic tecnologico. Ma ascoltatemi. Per noi, nel settore del monitoraggio degli agenti, non è solo una parola elegante; è un cambiamento fondamentale nel modo in cui comprendiamo i nostri sistemi. Non stiamo più solo guardando l’uso della CPU o il consumo di memoria. Stiamo cercando di capire lo *stato interno* dei nostri agenti, il loro percorso attraverso un flusso di lavoro, e i segnali sottili che ci indicano che qualcosa sta per andare storto – o che lo ha già fatto.

Il mio viaggio in questo è iniziato circa un anno e mezzo fa. Avevamo un nuovo cliente, una massiccia operazione di call center con migliaia di agenti che utilizzano la nostra integrazione CRM personalizzata. L’approccio di monitoraggio tradizionale stava fallendo in modo spettacolare. Avevamo cruscotti che brillavano di rosso per “alta CPU” o “spazio su disco basso” sui workstation degli agenti, ma il problema reale, quello che causava lamentele da parte dei clienti e SLA mancati, era più profondo. Gli agenti si bloccavano in uno stato di “chiusura post-chiamata” indefinitamente, o il loro CTI (Integrazione Telefonica Computerizzata) non registrava correttamente le chiamate in uscita. Le metriche tradizionali ci dicevano che le macchine erano a posto, ma gli *agenti* (e per estensione, il business) chiaramente non lo erano.

È allora che ho realizzato che dovevamo smettere di monitorare solo l’infrastruttura e iniziare a osservare il comportamento e le transizioni di stato degli agenti. Non basta sapere se l’applicazione di un agente è in esecuzione; dobbiamo sapere *cosa* quella applicazione pensa che l’agente stia facendo, e se questo è in linea con la realtà.

Il Problema con il Monitoraggio delle Metriche

Pensa alla tua auto. Se si accende la spia del motore, quella è una metrica. Ti dice che *qualcosa* non va. Ma non ti dice *cosa*. È il tappo del carburante allentato? Un sensore di ossigeno guasto? Un guasto catastrofico del motore? Hai bisogno di più contesto, di maggiore visibilità interna, per capire veramente il problema.

Il monitoraggio tradizionale è come quella spia del motore. Ti dice *se* una risorsa è vincolata o *se* un servizio è giù. Ma per agenti complessi e con stato, soprattutto quelli che interagiscono con più sistemi (CRM, telefonia, base di conoscenza, script personalizzati), una semplice metrica spesso non ti fornisce l’intero quadro. Un agente potrebbe essere “connesso” (secondo il tuo monitoraggio di presenza di base) ma effettivamente bloccato, incapace di svolgere qualsiasi azione, a causa di un sottile deadlock nella macchina dello stato della loro applicazione.

Abbiamo visto questo in modo vivido con il nostro cliente del call center. Il nostro monitoraggio di base mostrava che gli agenti erano collegati al CRM. La loro connettività di rete era a posto. La CPU era normale. Eppure, le chiamate non venivano elaborate. Approfondendo, abbiamo scoperto che una specifica sequenza di azioni (trasferire una chiamata, poi provare immediatamente ad accedere alla cronologia pagamenti di un cliente) stava facendo sì che lo stato interno del CRM per quell’agente si bloccasse in un ciclo di “in attesa di risposta del servizio esterno”, anche dopo che il servizio esterno aveva risposto. L’applicazione non stava andando in crash; era semplicemente bloccata in uno stato non reattivo dalla prospettiva dell’agente. Nessuna metrica avrebbe individuato ciò.

Osservabilità per gli Stati degli Agenti: Cosa Significa

Per me, osservabilità in questo contesto significa dotare le applicazioni e i flussi di lavoro degli agenti di strumenti per emettere dati dettagliati e strutturati sui loro cambiamenti di stato interno, eventi e contesto. Si tratta di chiedersi:

• Cosa sta *facendo attualmente* l’agente secondo l’applicazione? (ad es., “In Chiamata,” “Chiusura,” “Disponibile,” “Formazione,” “In Pausa”)
• Qual era lo *stato precedente*?
• Quali *eventi* hanno attivato il cambiamento di stato? (ad es., “Chiamata in Arrivo,” “Chiamata Risposta,” “Pulsante di Pausa Manuale Cliccato”)
• Quale *contesto* è associato a questo stato? (ad es., ID chiamata, ID cliente, motivo della pausa, durata nello stato attuale)

Questo non è solo registrare errori; è registrare il *viaggio* di un agente attraverso la propria giornata lavorativa, passo dopo passo, con ricco contesto.

Esempio 1: Monitoraggio degli Stati del Flusso di Lavoro degli Agenti

Immagina di avere un’applicazione desktop per agenti personalizzata. Invece di monitorare solo se il processo è in esecuzione, vuoi sapere il suo stato interno. Puoi emettere log strutturati o tracce ogni volta che uno stato chiave cambia.

// All'interno della tua applicazione desktop per agenti (pseudo-codice)

enum AgentState {
 LoggedIn,
 Available,
 OnCall,
 WrapUp,
 Paused,
 Offline
}

currentAgentState = AgentState.Offline;

function transitionState(newState, eventDetails = {}) {
 const timestamp = new Date().toISOString();
 const agentId = getAgentId(); // Ottieni dal contesto dell'applicazione
 const sessionId = getCurrentSessionId(); // Ottieni dal contesto dell'applicazione

 // Registra la transizione di stato con ricco contesto
 console.log(JSON.stringify({
 timestamp: timestamp,
 agentId: agentId,
 sessionId: sessionId,
 oldState: currentAgentState.toString(),
 newState: newState.toString(),
 eventType: eventDetails.type || "STATE_CHANGE",
 eventData: eventDetails.data || {}
 }));

 currentAgentState = newState;
}

// Esempio di uso:
// Quando un agente risponde a una chiamata:
transitionState(AgentState.OnCall, { type: "CALL_ANSWERED", data: { callId: "12345", customerId: "98765" } });

// Quando un agente va in chiusura:
transitionState(AgentState.WrapUp, { type: "CALL_ENDED", data: { callId: "12345", dispositionTime: 30 } });

// Quando un agente mette in pausa manualmente:
transitionState(AgentState.Paused, { type: "MANUAL_PAUSE", data: { reason: "Break", duration: 15 } });

Questo non è scienza missilistica, giusto? Ma la potenza arriva quando raccogli questi eventi centralmente. Puoi quindi costruire cruscotti che mostrano gli stati reali degli agenti, identificare gli agenti bloccati in stati inaspettati e persino analizzare i modelli di transizione di stato per individuare i colli di bottiglia nei flussi di lavoro.

Costruire Osservabilità nei Tuoi Strumenti per Agenti

Questo non riguarda solo l’aggiunta di alcune istruzioni di stampa. Richiede un approccio riflessivo all’istrumentazione. Ecco come abbiamo affrontato la cosa:

1. Definire Gli Stati e le Transizioni Chiave degli Agenti

Prima di scrivere qualsiasi codice, siediti con i tuoi product manager, team leader e anche alcuni agenti. Mappa gli stati critici in cui un agente può trovarsi e i modi legittimi in cui possono passare da uno stato all’altro. Questo diventa la tua “verità di base” su come appare un flusso di lavoro sano per gli agenti. Documentalo esplicitamente.

2. Istrumentare Tutto Ciò Che È Rilevante

Nelle tue applicazioni per agenti (desktop, web, servizi backend che supportano gli agenti), emetti log strutturati o tracce a ogni cambiamento significativo di stato o evento. Concentrati su:

• Cambiamenti di Stato: Quando lo stato di un agente cambia (ad es., “Disponibile” a “In Chiamata”).
• Azioni Chiave: Quando un agente compie un’azione critica (ad es., “Chiamata Trasferita,” “Record Cliente Aggiornato,” “Modulo Inviato”).
• Interazioni con Sistemi Esterni: Quando l’applicazione dell’agente interagisce con un CRM, un sistema di telefonia o un database. Registra la richiesta, la risposta e eventuali errori.

3. Usare il Logging Strutturato

JSON è il tuo amico qui. Non limitarti a scaricare testo semplice. I log strutturati rendono infinitamente più facile analizzare, filtrare e analizzare i tuoi dati in seguito. Includi attributi comuni in ogni voce di log (timestamp, ID agente, ID sessione, versione dell’applicazione) e attributi specifici per ogni tipo di evento.

4. Centralizzare e Analizzare

Invia tutti questi log a un sistema di logging centrale (Elasticsearch, Splunk, Loki, DataDog, ecc.). È qui che accade la magia. Ora puoi:

• Creare Cruscotti in Tempo Reale: Visualizzare lo stato attuale di tutti gli agenti, identificare anomalie (ad es., agenti bloccati in “Chiusura” per troppo tempo).
• Interrogare e Filtrare: Trovare rapidamente tutti gli eventi per un agente specifico, cliente o ID chiamata.
• Allerta su Anomalie: Impostare avvisi per transizioni di stato o durate inaspettate (ad es., “Avvisa se un agente è in stato ‘In Pausa’ per più di 30 minuti senza un codice di motivo valido”).
• Tracciare Flussi di Lavoro: Seguire il viaggio di un agente attraverso un processo complesso collegando voci di log correlate.

Esempio 2: Rilevamento di Agenti Bloccati con Analisi dei Log

Utilizzando un sistema di logging come Elasticsearch con Kibana, potresti impostare una query per trovare agenti bloccati in uno stato indesiderato. Immagina di cercare agenti che sono entrati nello stato “Chiusura” ma non hanno effettuato la transizione per più di 5 minuti.

// Query Elasticsearch (Kibana Discover o Dev Tools)

{
 "query": {
 "bool": {
 "must": [
 { "match": { "newState.keyword": "WrapUp" } },
 { "range": { "timestamp": { "lte": "now-5m" } } }
 ],
 "must_not": [
 { "exists": { "field": "nextState" } } // Supponendo che registrerei un evento "nextState" o "transitionedOut"
 ]
 }
 },
 "aggs": {
 "stuck_agents": {
 "terms": {
 "field": "agentId.keyword",
 "size": 100
 }
 }
 }
}

Questa query ti darebbe un elenco di ID agente che sono entrati nello stato “Chiusura” più di 5 minuti fa e non hanno avuto un evento di cambiamento di stato successivo registrato. Questo è un modo molto potente per identificare e affrontare proattivamente i problemi prima che escano dal controllo.

I Miei Riepiloghi e Passi Azionabili

Se stai gestendo agenti, siano essi umani o bot automatizzati, devi assolutamente andare oltre il monitoraggio di base della disponibilità. Ecco cosa ti consiglio:

1. Smetti di Monitorare Solo le Risorse, Inizia a Osservare gli Stati: Sposta la tua attenzione da “La CPU è alta?” a “Cosa sta *facendo* l’applicazione agente in questo momento, ed è corretto?”
2. Mappa i Tuoi Workflow degli Agenti: Documenta ogni stato significativo in cui un agente può trovarsi e le transizioni valide. Questo è il tuo piano per l’osservabilità.
3. Includi Strumenti di Logging nelle Tue Applicazioni Agente: Costruisci logging strutturato o tracing direttamente nei tuoi strumenti per agenti. Ogni cambiamento critico di stato o azione dovrebbe generare un evento dettagliato. Usa JSON.
4. Centrali i Tuoi Dati: Fai entrare quegli eventi in un sistema dove puoi interrogarli, visualizzarli e ricevere avvisi.
5. Crea Avvisi Proattivi: Non aspettare che gli agenti si lamentino. Imposta avvisi per durate di stato inaspettate o transizioni non valide. Ad esempio, se un agente rimane in “WrapUp” per più di 180 secondi in media, ricevi un avviso. Se un agente prova ad accettare una chiamata mentre è in stato “Paused”, ricevi un avviso.
6. Forma i Tuoi Team: Mostra ai tuoi team di supporto, operazioni e prodotto come utilizzare questi nuovi cruscotti e query. Più occhi sui dati, più velocemente noterai i problemi.

Non è un progetto una tantum. È un processo continuo di affinamento della tua strumentazione, miglioramento dei tuoi cruscotti e formulazione di domande più profonde sull’esperienza del tuo agente. Ma ti prometto che l’investimento ripaga. Siamo passati da un approccio reattivo a identificare e risolvere proattivamente i problemi che impattano gli agenti in pochi minuti, a volte anche prima che gli agenti stessi notassero un problema. Questo ha migliorato l’aderenza al SLA dei nostri clienti, ridotto la frustrazione degli agenti e, francamente, ha reso il mio lavoro molto meno stressante. E questo, a marzo 2026, è una vittoria per me.

Hai delle opinioni sull’osservabilità degli agenti? Scrivimi nei commenti qui sotto!

Articoli Correlati

• Sviluppo basato sul log degli agenti AI
• La mia Strategia di Debugging: Dal Caos alla Calma
• Logging degli agenti AI in produzione

🕒 Published: April 4, 2026