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

Ciao a tutti, qui Chris Wade, di nuovo su agntlog.com. Siamo a 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 molte volte) ultimamente: l’osservabilità per gli stati degli agenti, non solo per le metriche.

Lo so, “osservabilità” è una parola alla moda lanciata 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 male – o lo è già.

Il mio cammino verso questo ha iniziato circa un anno e mezzo fa. Avevamo un nuovo cliente, un enorme centro di chiamate con migliaia di agenti che usano la nostra integrazione CRM personalizzata. Il vecchio approccio di monitoraggio falliva in modo spettacolare. Avevamo cruscotti che si illuminavano di rosso per “alto utilizzo della CPU” o “spazio su disco basso” sui computer degli agenti, ma il vero problema, quello che causava reclami dai clienti e SLA mancati, era più profondo. Gli agenti rimanevano bloccati in uno stato di “post-chiamata” indefinitamente o il loro CTI (Integrazione Telefonica Informatica) non registrava correttamente le chiamate in uscita. Le metriche tradizionali ci dicevano che le macchine andavano bene, ma gli *agenti* (e di riflesso, l’azienda) evidentemente non lo erano.

È stato allora che ho realizzato che dovevamo smettere di monitorare semplicemente l’infrastruttura e iniziare a osservare il comportamento degli agenti e le transizioni di stato. Non basta sapere se l’applicazione di un agente funziona; dobbiamo sapere *cosa* questa applicazione pensa che l’agente stia facendo, e se ciò corrisponde alla realtà.

Il Problema del Monitoraggio Unicamente delle Metriche

Pensate alla vostra auto. Se si accende la spia del motore, è una metrica. Questo vi dice che *qualcosa* non va. Ma non vi dice *cosa*. È un tappo del serbatoio del gas mal tolto? Un sensore dell’ossigeno difettoso? Un guasto catastrofico del motore? Avete 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 è 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 spesso non vi dà la panoramica. Un agente può essere “connesso” (secondo il monitoraggio di presenza di base), ma effettivamente bloccato, incapace di compiere azioni, a causa di un blocco sottile nella macchina di stato della sua applicazione.

Abbiamo visto questa situazione in modo clamoroso con il nostro cliente del centro di chiamate. Il nostro monitoraggio di base mostrava che gli agenti erano connessi al CRM. La loro connettività di rete era corretta. La CPU era normale. Eppure, le chiamate non venivano elaborate. Approfondendo, abbiamo scoperto che una sequenza specifica di azioni (trasferire una chiamata, poi provare immediatamente ad 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 di risposta da un servizio esterno”, anche dopo che il servizio esterno aveva risposto. L’applicazione non si bloccava; era semplicemente congelata in uno stato non reattivo dal punto di vista dell’agente. Nessuna metrica avrebbe potuto rilevare 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 di agenti per emettere dati dettagliati e strutturati sui loro cambiamenti di stato interni, eventi e contesto. Si tratta di chiedere:

• Cosa sta facendo l’agente *attualmente* secondo l’applicazione? (ad esempio, “In chiamata”, “In riepilogo”, “Disponibile”, “Formazione”, “In pausa”)
• Qual era l’*stato precedente*?
• Quali *eventi* hanno innescato il cambiamento di stato? (ad esempio, “Chiamata entrante”, “Chiamata risposta”, “Pulsante di pausa manualmente 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

Supponiamo che abbiate un’applicazione desktop per agenti personalizzata. Invece di monitorare semplicemente se il processo funziona, volete conoscere il suo stato interno. Potete emettere registrazioni strutturate o tracce ogni volta che cambia uno stato chiave.

// 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 di utilizzo :
// Quando un agente risponde a una chiamata :
transitionState(AgentState.OnCall, { type: "CALL_ANSWERED", data: { callId: "12345", customerId: "98765" } });

// Quando un agente passa a riepilogo :
transitionState(AgentState.WrapUp, { type: "CALL_ENDED", data: { callId: "12345", dispositionTime: 30 } });

// Quando un agente mette manualmente in pausa :
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 poi costruire cruscotti che mostrano gli stati degli agenti in tempo reale, 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.

Integrare l’Osservabilità nel Vostro Strumento di Gestione degli Agenti

Non si tratta semplicemente di aggiungere alcune istruzioni di stampa. Richiede un approccio riflessivo all’implementazione. Ecco come abbiamo affrontato la questione:

1. Definire gli Stati e le Transizioni Chiave degli Agenti

Prima di scrivere il codice, sedetevi con i vostri manager di prodotto, i responsabili di team e anche alcuni agenti. Mappate gli stati critici in cui un agente può trovarsi e i legittimi modi in cui può passare da uno stato all’altro. Questo diventa la vostra “verità di base” su come appare un flusso di lavoro sano per un agente. Documentate tutto esplicitamente.

2. Instrumentare Tutto ciò che è Pertinente

Nelle vostre applicazioni per agenti (desktop, web, servizi backend che supportano gli agenti), emettete registrazioni strutturate o tracce a 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 il dossier del cliente”, “Inviare il modulo”).
• Interazioni con Sistemi Esterni: Quando l’applicazione dell’agente interagisce con un CRM, un sistema telefonico, o un database. Registrate la richiesta, la risposta e qualsiasi errore.

3. Utilizzare Registrazioni Strutturate

JSON è il vostro amico qui. Non limitatevi a versare del testo grezzo. Le registrazioni strutturate semplificano enormemente l’analisi, il filtraggio e la comprensione dei vostri dati successivamente. Includete attributi comuni in ogni voce di registro (timestamp, ID agente, ID sessione, versione dell’applicazione) e attributi specifici per ogni tipo di evento.

4. Centralizzare e Analizzare

Inviare tutte queste registrazioni a un sistema di registrazione centralizzato (Elasticsearch, Splunk, Loki, DataDog, ecc.). Qui è dove avviene la magia. Ora potete:

• Costruire Cruscotti 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.
• Allerta su Anomalie: Imposta avvisi per transizioni di stato o durate inattese (ad esempio, “Avvisa se un agente è in stato ‘In Pausa’ per più di 30 minuti senza codice motivo valido”).
• Segui 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 che 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 tu stia registrando un evento "nextState" o "transitionedOut"
 ]
 }
 },
 "aggs": {
 "stuck_agents": {
 "terms": {
 "field": "agentId.keyword",
 "size": 100
 }
 }
 }
}

Questa query ti fornirebbe un elenco di ID di 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 diventino più gravi.

Il Mio Feedback e Passi Azionabili

Se gestisci agenti, siano essi umani o bot automatizzati, è fondamentale andare oltre una semplice monitorizzazione del tempo di attività. Ecco cosa ti consiglio:

1. 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, e va bene?”.
2. Mappea i tuoi flussi di lavoro di agente: Documenta ogni stato significativo in cui un agente può trovarsi e le transizioni valide. Questo è il tuo piano per l’osservabilità.
3. 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 generare un evento dettagliato. Usa JSON.
4. Centralizza i tuoi dati: Invia questi eventi in un sistema dove puoi interrogarli, visualizzarli e ricevere avvisi.
5. Stabilisci avvisi proattivi: Non aspettare che gli agenti si lamentino. Configura avvisi per durate di stato inattese 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 “In Pausa”, avvisa.
6. Educa i tuoi team: Mostra ai tuoi team di supporto, operazioni e prodotti come utilizzare questi nuovi cruscotti e query. Più occhi ci sono sui dati, più velocemente riconoscerai i problemi.

Non è un progetto una tantum. È un processo continuo di affinamento della tua strumentazione, miglioramento dei tuoi cruscotti e interrogazione approfondita sull’esperienza dei tuoi agenti. Ma ti prometto che l’investimento ne vale la pena. Siamo passati da una lotta reattiva a un’identificazione e risoluzione proattiva dei problemi che influenzano gli 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.

Pensi 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: April 4, 2026