Ciao a tutti, qui è Chris Wade, di nuovo su agntlog.com. Siamo nel marzo 2026 e, onestamente, se pensate ancora di monitorare i vostri agenti come facevamo cinque anni fa, state lasciando soldi, salute mentale e forse anche il vostro lavoro sul tavolo. Il mondo è cambiato e anche la vostra strategia dovrebbe farlo. Oggi voglio parlare di qualcosa di specifico, qualcosa che mi preoccupa (e che mi ha salvato in molte occasioni) ultimamente: l’osservabilità per gli stati degli agenti, non solo per le metriche.
Lo so, “osservabilità” è un termine di moda lanciato come un frisbee durante un picnic tecnologico. Ma ascoltatemi. Per noi, nel campo del monitoraggio degli agenti, non è solo un termine di tendenza; è un cambiamento fondamentale nella nostra comprensione dei nostri sistemi. Non ci limitiamo più a guardare solo l’uso della CPU o il consumo di memoria. Cerchiamo di comprendere 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 lo è già.
Il mio viaggio verso questo è iniziato circa un anno e mezzo fa. Avevamo un nuovo cliente, un enorme call center con migliaia di agenti che utilizzavano la nostra integrazione CRM personalizzata. L’approccio di monitoraggio precedente falliva in modo spettacolare. Avevamo dashboard che si illuminavano di rosso per “alta utilizzo CPU” o “spazio su disco insufficiente” sui posti di lavoro degli agenti, ma il vero problema, quello che causava lamentele dai clienti e SLA non rispettati, era più profondo. Gli agenti si trovavano bloccati in uno stato di “post-chiamata” indefinitamente, o la loro CTI (Integrazione Telefono-Computer) non registrava correttamente le chiamate in uscita. Le metriche tradizionali ci dicevano che le macchine stavano andando bene, ma gli *agenti* (e per estensione, l’azienda) non stavano chiaramente affatto bene.
È allora che ho capito che dovevamo smettere di monitorare semplicemente l’infrastruttura e iniziare a osservare il comportamento degli agenti e le transizioni di stato. Non è sufficiente sapere se l’applicazione di un agente funziona; dobbiamo sapere *cosa* quell’applicazione pensa che l’agente stia facendo e se questo corrisponde alla realtà.
Il Problema della Sorveglianza Solo delle Metriche
Pensate alla vostra auto. Se si accende la spia del motore, questa è una metrica. Vi dice che *qualcosa* non va. Ma non vi dice *cosa*. È un tappo della benzina mal fissato? Un sensore di ossigeno difettoso? Un guasto catastrofico del motore? Avete bisogno di più contesto, di maggiore visibilità interna, per comprendere veramente il problema.
Il monitoraggio tradizionale è come quella spia del motore. Vi dice *se* una risorsa è sovraccarica o *se* un servizio è offline. Ma per agenti complessi e con stato, in particolare quelli che interagiscono con più sistemi (CRM, telefonia, base di conoscenza, script personalizzati), una semplice metrica non vi fornisce spesso la visione d’insieme. Un agente può essere “connesso” (secondo il vostro monitoraggio di presenza di base) ma effettivamente bloccato, incapace di compiere azioni, a causa di un blocco sottile nella macchina a stati della sua applicazione.
Abbiamo visto questo in modo spettacolare con il nostro cliente del call center. Il nostro monitoraggio di base mostrava che gli agenti erano connessi al CRM. La loro connettività di rete era corretta. La CPU era normale. Tuttavia, le chiamate non venivano elaborate. Approfondendo, abbiamo scoperto che una sequenza specifica di azioni (trasferire una chiamata, poi cercare immediatamente di accedere alla cronologia dei pagamenti di un cliente) faceva sì che lo stato interno del CRM per quell’agente rimanesse bloccato in un ciclo di “attesa risposta da un servizio esterno”, anche dopo che il servizio esterno aveva risposto. L’applicazione non si era bloccata; era semplicemente congelata in uno stato non reattivo dal punto di vista dell’agente. Nessuna metrica avrebbe potuto individuare questo.
Osservabilità per gli Stati degli Agenti: Cosa Significa
Per me, l’osservabilità in questo contesto significa dotare le vostre applicazioni e flussi di lavoro degli agenti di emettere dati dettagliati e strutturati sui loro cambiamenti di stato interni, eventi e contesto. È chiedere:
- Cosa sta facendo l’agente *attualmente* secondo l’applicazione? (ad esempio, “In chiamata”, “In riassunto”, “Disponibile”, “Formazione”, “In pausa”)
- Qual era lo *stato precedente*?
- Quali *eventi* hanno innescato il cambiamento di stato? (ad esempio, “Chiamata in entrata”, “Chiamata risposta”, “Pulsante di pausa manuale cliccato”)
- Quale *contesto* è associato a questo stato? (ad esempio, ID chiamata, ID cliente, motivo della pausa, durata nello stato attuale)
Non si tratta solo di registrare errori; si tratta di documentare il *percorso* di un agente attraverso la sua giornata lavorativa, passo dopo passo, con un contesto ricco.
Esempio 1: Monitoraggio degli Stati di Flusso di Lavoro degli Agenti
Diciamo che avete un’applicazione desktop personalizzata per agenti. Invece di monitorare semplicemente se il processo funziona, volete conoscere il suo stato interno. Potete emettere log strutturati o tracce ogni volta che un stato chiave cambia.
// Nella vostra 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(); // Ottenere dal contesto dell'applicazione
const sessionId = getCurrentSessionId(); // Ottenere dal contesto dell'applicazione
// Registrare 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 d'uso :
// Quando un agente risponde a una chiamata :
transitionState(AgentState.OnCall, { type: "CALL_ANSWERED", data: { callId: "12345", customerId: "98765" } });
// Quando un agente passa in riassunto :
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 } });
Non è scienza missilistica, vero? Ma la potenza risiede nella raccolta di questi eventi in modo centralizzato. Potete quindi costruire dashboard che mostrano gli stati degli agenti in tempo reale, identificare agenti bloccati in stati inaspettati e persino analizzare i modelli di transizione di stato per individuare i colli di bottiglia nei flussi di lavoro.
Integrare l’Osservabilità nel Vostro Strumento di Gestione degli Agenti
Non si tratta semplicemente di aggiungere qualche istruzione di stampa. Richiede un approccio riflessivo all’implementazione. Ecco come abbiamo affrontato la cosa:
1. Definire gli Stati e le Transizioni Chiave degli Agenti
Prima di scrivere codice, sedetevi con i vostri product manager, i vostri responsabili di team e anche alcuni agenti. Mappate gli stati critici in cui può trovarsi un agente e i modi legittimi in cui può passare da uno stato all’altro. Questo diventa la vostra “verità fondamentale” su come appare un flusso di lavoro sano per un agente. Documentate questo esplicitamente.
2. Strumentare Tutto ciò che È Rilevante
Nelle vostre applicazioni per agenti (desktop, web, servizi backend che supportano gli agenti), emettete log strutturati o tracce ad ogni cambiamento di stato significativo o evento. Concentratevi su:
- Cambiamenti di Stato: Quando lo stato di un agente cambia (ad esempio, “Disponibile” a “In chiamata”).
- Azioni Chiave: Quando un agente compie un’azione critica (ad esempio, “Trasferire la chiamata”, “Aggiornare la scheda del cliente”, “Inviare il modulo”).
- Interazioni con Sistemi Esterni: Quando l’applicazione dell’agente interagisce con un CRM, un sistema di telefonia o un database. Registrate la richiesta, la risposta e ogni errore.
3. Utilizzare Log Strutturati
JSON è il vostro amico qui. Non limitatevi a scaricare testo non strutturato. I log strutturati facilitano enormemente l’analisi, il filtraggio e la comprensione dei vostri dati in seguito. Includete 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
Inviare tutti questi log a un sistema di logging centralizzato (Elasticsearch, Splunk, Loki, DataDog, ecc.). Qui è dove avviene la magia. Ora potete:
- Costruire Dashboard in Tempo Reale: Visualizza lo stato attuale di tutti gli agenti, identifica i valori anomali (ad esempio, agenti bloccati in “Riepilogo” troppo a lungo).
- Interrogare e Filtrare: Trova rapidamente tutti gli eventi per un agente, un cliente o un ID di chiamata specifico.
- Avvisare su Anomalie: Imposta avvisi per transizioni di stato o durate inaspettate (ad esempio, “Avvisa se un agente è in stato di ‘In Attesa’ da più di 30 minuti senza un codice motivo valido”).
- Monitorare i Flussi di Lavoro: Segui il percorso di un agente attraverso un processo complesso collegando le voci di log correlate.
Esempio 2: Rilevare Agenti Bloccati con l’Analisi dei Log
Utilizzando un sistema di logging come Elasticsearch con Kibana, potresti configurare una query per trovare agenti bloccati in uno stato indesiderato. Immagina di cercare agenti che sono entrati nello stato “Riepilogo” ma non ne sono usciti da 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 stiate registrando un evento "nextState" o "transitionedOut"
]
}
},
"aggs": {
"stuck_agents": {
"terms": {
"field": "agentId.keyword",
"size": 100
}
}
}
}
Questa query ti darebbe un elenco di ID agenti che sono entrati nello stato “Riepilogo” più di 5 minuti fa e che non hanno avuto eventi di cambio di stato registrati successivamente. È un modo molto potente per identificare e affrontare proattivamente i problemi prima che si aggravino.
I Miei Feedback e Passi Azionabili
Se gestisci agenti, siano essi umani o bot automatizzati, devi assolutamente andare oltre una semplice supervisione del tempo di attività. Ecco cosa consiglio:
- Smetti di monitorare semplicemente le risorse, inizia a osservare gli stati: Cambia il tuo focus da “La CPU è alta?” a “Cosa sta facendo esattamente l’applicazione dell’agente in questo momento, ed è corretto?”
- Mappa i tuoi flussi di lavoro degli agenti: Documenta ogni stato significativo in cui un agente può trovarsi e le transizioni valide. Questo è il tuo piano per l’osservabilità.
- Strumenta le tue applicazioni di agente: Integra un logging strutturato o un tracciamento direttamente nei tuoi strumenti di agente. Ogni cambiamento di stato critico o azione deve emettere un evento dettagliato. Usa JSON.
- Centrali i tuoi dati: Invia questi eventi in un sistema dove puoi interrogare, visualizzare e allertarti.
- Stabilisci avvisi proattivi: Non aspettare che gli agenti si lamentino. Configura avvisi per durate di stato inattese o transizioni invalide. 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 “In Attesa”, avvisa.
- Forma le tue squadre: Mostra ai tuoi team di supporto, operazioni e prodotto come usare questi nuovi dashboard e query. Più occhi ci sono sui dati, più velocemente individuerai i problemi.
Non è un progetto una tantum. È un processo continuo di affinamento della tua strumentazione, miglioramento dei tuoi dashboard e approfondimento dell’esperienza dei tuoi agenti. Ma ti prometto, l’investimento ne vale la pena. Siamo passati da una lotta reattiva a un’identificazione e risoluzione proattive dei problemi che impattano sugli agenti in pochi minuti, a volte anche prima che l’agente stesso noti un problema. Questo ha migliorato il rispetto degli SLA dei nostri clienti, ha ridotto la frustrazione degli agenti e, francamente, ha reso il mio lavoro molto meno stressante. E questo, a marzo 2026, è una vittoria ai miei occhi.
Hai pensieri sull’osservabilità degli agenti? Fammi sapere nei commenti qui sotto!
Articoli Correlati
- Sviluppo guidato dai log degli agenti AI
- La mia strategia di debug: Dal caos alla calma
- Logging degli agenti AI in produzione
🕒 Published: