Ciao a tutti, Chris Wade qui, di nuovo su agntlog.com. È marzo 2026 e, onestamente, se stai ancora pensando di monitorare i tuoi agenti come facevamo cinque anni fa, stai lasciando soldi, sanità mentale e forse anche il tuo lavoro sul tavolo. Il mondo è andato avanti e anche la tua strategia dovrebbe. Oggi voglio parlare di qualcosa di specifico, qualcosa che mi ha dato fastidio (e salvato la pelle) ultimamente: Osservabilità per gli Stati degli Agenti, Non Solo Metriche.
Lo so, “osservabilità” è un termine di moda che viene usato come un frisbee a un picnic tecnologico. Ma ascoltami. Per noi, nel campo del monitoraggio degli agenti, non è solo un termine elegante; è un cambiamento fondamentale nel modo in cui comprendiamo i nostri sistemi. Non ci limitiamo più a guardare 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 dicono che qualcosa sta per andare storto – o che già lo è.
La mia avventura in questo campo è iniziata circa un anno e mezzo fa. Avevamo un nuovo cliente, un’enorme operazione di call center con migliaia di agenti che utilizzavano la nostra integrazione CRM personalizzata. L’approccio di monitoraggio precedente stava fallendo in modo spettacolare. Avevamo dashboard che lampeggiavano di rosso per “alta CPU” o “spazio su disco basso” sui posti di lavoro degli agenti, ma il vero problema, quello che causava lamentele da parte dei clienti e SLA mancati, era più profondo. Gli agenti rimanevano bloccati in uno stato di “chiusura post-chiamata” indefinitamente, o la loro CTI (Computer Telephony Integration) non registrava correttamente le chiamate in uscita. Le metriche tradizionali ci dicevano che le macchine stavano bene, ma gli *agenti* (e di conseguenza, il business) chiaramente no.
È stato allora che ho capito che dovevamo smettere di monitorare solo l’infrastruttura e iniziare a osservare il comportamento degli agenti e le transizioni di stato. Non basta sapere se l’applicazione di un agente è in esecuzione; dobbiamo sapere *cosa* quell’applicazione pensa che l’agente stia facendo e se questo corrisponde alla realtà.
Il Problema del Monitoraggio delle Sole 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*. È un tappo del carburante allentato? Un sensore dell’ossigeno che sta fallendo? Un guasto catastrofico del motore? Hai bisogno di più contesto, di maggiore visibilità interna, per comprendere davvero 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 dà il quadro completo. Un agente potrebbe essere “loggato” (secondo il tuo monitoraggio di presenza di base) ma effettivamente congelato, incapace di svolgere azioni, a causa di un sottile deadlock nella macchina a stati 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 loggati nel CRM. La loro connettività di rete funzionava bene. La CPU era normale. Eppure, le chiamate non venivano elaborate. Scavando più a fondo, abbiamo scoperto che una sequenza specifica di azioni (trasferire una chiamata, poi provare immediatamente ad accedere alla storia dei pagamenti di un cliente) stava causando lo stato interno del CRM per quell’agente a bloccarsi in un ciclo di “in attesa di risposta del servizio esterno”, anche dopo che il servizio esterno aveva risposto. L’applicazione non si stava bloccando; era semplicemente congelata in uno stato non responsivo dal punto di vista dell’agente. Nessuna metrica avrebbe catturato questo.
Osservabilità per gli Stati degli Agenti: Cosa Significa
Per me, l’osservabilità in questo contesto significa dotare le tue applicazioni e flussi di lavoro per agenti di strumenti per emettere dati dettagliati e strutturati sui loro cambiamenti di stato interno, eventi e contesto. Si tratta di chiedere:
- Qual è l’agente *attualmente impegnato* secondo l’applicazione? (es. “In Chiamata,” “Chiusura,” “Disponibile,” “Formazione,” “In Pausa”)
- Qual era lo *stato precedente*?
- Quali *eventi* hanno attivato il cambiamento di stato? (es. “Chiamata In Entrata,” “Chiamata Risposta,” “Pulsante di Pausa Manuale Cliccato”)
- Qual è il *contesto* associato a questo stato? (es. ID della chiamata, ID cliente, motivo della pausa, durata nello stato attuale)
Non si tratta solo di registrare errori; si tratta di registrare il *viaggio* di un agente attraverso la propria giornata lavorativa, passo dopo passo, con un ricco contesto.
Esempio 1: Monitoraggio degli Stati del Flusso di Lavoro degli Agenti
Immagina di avere un’applicazione desktop personalizzata per agenti. Invece di monitorare solo se il processo è in esecuzione, vuoi sapere il suo stato interno. Puoi emettere log strutturati o tracce ogni volta che cambia uno stato chiave.
// 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 un contesto ricco
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 utilizzo:
// 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: "Pausa", duration: 15 } });
Non è una scienza missilistica, giusto? Ma il potere arriva quando raccogli questi eventi in modo centrale. Puoi quindi costruire dashboard che mostrano gli stati reali degli agenti, identificare agenti bloccati in stati inaspettati e persino analizzare i modelli di transizione degli stati per individuare colli di bottiglia nei flussi di lavoro.
Costruire Osservabilità negli Strumenti dei Tuoi Agenti
Non si tratta solo di aggiungere alcune istruzioni di stampa. Richiede un approccio riflessivo all’istrumentazione. Ecco come ci siamo affrontati:
1. Definire Stati e Transizioni Chiave per gli 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 tra di essi. Questo diventerà la tua “verità fondamentale” su come appare un flusso di lavoro sano per un agente. Documenta questo in modo esplicito.
2. Istrumentare Tutto ciò che è Rilevante
Nelle tue applicazioni per agenti (desktop, web, servizi backend che supportano gli agenti), emetti log strutturati o tracce ad ogni cambiamento di stato significativo o evento. Concentrati su:
- Cambiamenti di Stato: Quando lo stato di un agente cambia (es. “Disponibile” a “In Chiamata”).
- Azioni Chiave: Quando un agente esegue un’azione critica (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. Utilizzare 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 successivamente. 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
Inviate tutti questi log a un sistema di logging centrale (Elasticsearch, Splunk, Loki, DataDog, ecc.). Qui è dove avviene la magia. Ora puoi:
- Costruire Dashboard in Tempo Reale: Visualizzare lo stato attuale di tutti gli agenti, identificare outlier (es. agenti bloccati in “Chiusura” per troppo tempo).
- Interrogare e Filtrare: Trovare rapidamente tutti gli eventi per un agente, cliente o ID chiamata specifici.
- Avvisare sulle Anomalie: Impostare avvisi per transizioni di stato inaspettate o durate (es. “Avvisa se un agente è nello stato ‘In Pausa’ per più di 30 minuti senza un codice motivo valido”).
- Tracciare Flussi di Lavoro: Seguire il viaggio di un agente attraverso un processo complesso collegando le voci di log correlate.
Esempio 2: Rilevare Agenti Bloccati con Analisi del 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 sono usciti da esso 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 registreresti 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 le problematiche prima che si aggravino.
I Miei Risultati e Passi Azionabili
Se gestisci agenti, siano essi umani o bot automatici, devi assolutamente superare il monitoraggio di base dell’uptime. Ecco cosa ti consiglio:
- Stop a Monitorare Solo Risorse, Inizia a Osservare Stati: Sposta il tuo focus da “La CPU è alta?” a “Cosa sta *facendo* l’applicazione dell’agente in questo momento, e va bene così?”
- Mappa i Workflow dei Tuoi Agenti: Documenta ogni stato significativo in cui un agente può trovarsi e le transizioni valide. Questo è il tuo schema per l’osservabilità.
- Strumenta le Tue Applicazioni Agente: Costruisci il logging strutturato o il tracciamento direttamente nei tuoi strumenti per agenti. Ogni cambiamento di stato critico o azione dovrebbe generare un evento dettagliato. Usa JSON.
- Centralizza i Tuoi Dati: Porta quegli eventi in un sistema in cui puoi interrogarli, visualizzarli e ricevere avvisi su di essi.
- Crea Allarmi 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, avvisa. Se un agente cerca di accettare una chiamata mentre è in stato “Paused”, avvisa.
- Educa i Tuoi Team: Mostra ai tuoi team di supporto, operazioni e prodotto come usare queste nuove dashboard e query. Più occhi sui dati, più velocemente individuerai i problemi.
Questo non è un progetto da fare una sola volta. È un processo continuo di affinamento della tua strumentazione, miglioramento delle tue dashboard e di porre domande più profonde sull’esperienza del tuo agente. Ma te lo prometto, l’investimento ripaga. Siamo passati dal combattere incendi in modo reattivo all’identificazione e risoluzione proattiva di problemi che impattano gli agenti in pochi minuti, a volte anche prima che l’agente stesso notasse un problema. Ha migliorato la conformità SLA dei nostri clienti, ridotto la frustrazione degli agenti e, francamente, ha reso il mio lavoro molto meno stressante. E questo, nel marzo 2026, è una vittoria nel mio libro.
Hai pensieri sull’osservabilità degli agenti? Scrivimi nei commenti qui sotto!
Articoli Correlati
- Sviluppo guidato dai log degli agenti AI
- La mia Strategia di Debugging: Dal Caos alla Calma
- Logging degli agenti AI in produzione
🕒 Published: