Osservabilità per agent AI: allineare costi, segnali e responsabilità operative

Budget sotto pressione, volumi di telemetria in crescita, agenti che dipendono da servizi esterni: la gestione operativa regge solo se si paga per i dati che servono davvero, si automatizza il presidio e si conserva la storia per indagare senza buchi^1,2,5.

1) Volumi in salita, budget fissi: il rischio è perdere proprio i dati che servono

La spesa di osservabilità cresce con log, metriche e tracce. Ogni chiamata e ogni agente aggiungono segnali. I budget non seguono lo stesso ritmo¹. Molti team reagiscono tagliando retention e campionando in modo grossolano. Il costo scende, ma nella crisi mancano i dati chiave¹.

Questo problema pesa di più quando un agente si appoggia a modelli, API e contenuti fuori controllo diretto. Può rompersi senza un cambio di codice: il provider del modello ritira una versione, un alias punta altrove, un’API rinomina un campo, i documenti cambiano struttura. L’errore compare in produzione, davanti all’utente, non in code review⁵.

2) Allineare costo e valore: cosa cambia con Adaptive Telemetry

Adaptive Telemetry propone di selezionare e mantenere ciò che serve nelle indagini e nel lavoro quotidiano, scartando il resto. L’obiettivo è spezzare il legame tra costo e quantità ingerita e legarlo invece all’utilità operativa dei dati conservati¹.

L’esperienza di Rapid7 è concreta. Carl Eastman riassume il passaggio a Grafana Cloud con Adaptive Telemetry così: il risparmio sulle metriche ha finanziato log e tracce. Più visibilità, costi più bassi, query più veloci, meno rumore¹. La conseguenza operativa è chiara: non serve amputare segnali per rientrare nel budget. Si tiene ciò che nutre diagnosi e automazioni, senza subire aumenti lineari di spesa al crescere dei volumi¹.

Per chi gestisce agenti, questo approccio evita il paradosso del risparmio miope. Una metrica storica che dimostra l’effetto di un cambio di modello o di un alias vale più di cento eventi minori. Pagare per valore permette di preservare proprio quei segnali, e di ridurre il rischio di indagini al buio¹.

3) Automatizzare il presidio e conservare la freccia del tempo

Ridurre i costi non basta. Serve ridurre anche il tempo di presidio e mantenere il contesto. Grafana ha portato in disponibilità generale Assistant Watchers su Grafana Cloud. Watchers osserva in continuo le condizioni definite dal team e segnala quando un cambiamento conta. L’annuncio arriva a ObservabilityCON 2026 a San Francisco, insieme a un set di capacità AI per rendere le operazioni più autonome. Assistant Investigations è in disponibilità generale da fine luglio².

I ruoli sono distinti. Watchers funge da sentinella: monitora i segnali scelti, filtra il rumore e avvisa al momento giusto². Investigations prende in carico un alert o un incidente, raccoglie le prove di cosa è cambiato e mantiene il contesto in un unico flusso. Si lavora dove il team già opera: nella piattaforma Grafana Cloud, in Slack, attraverso il Grafana Cloud MCP server o con gcx².

Queste funzioni hanno un presupposto: lo storico conta. Senza storia, l’analisi perde direzione. Estela lo mostra con un caso pratico. Claude Code espone una percentuale di utilizzo della finestra di 5 ore come valore live. Non tiene memoria. Non dice se il consumo cresce piano o arriva con un picco dopo un file grande. La differenza guida l’azione. Per evitare buchi, Estela registra in locale la percentuale in un file JSONL. Gli autori lo hanno aggiunto per ricostruire ore fatturabili a partire dalle sessioni con agenti di coding⁴.

Lo stesso principio vale per gli incidenti. Un alert che innesca un’investigazione ha bisogno di prove ancorate al tempo: quando è cambiato un alias di modello, quando una latenza ha superato una soglia, quando un campo di un’API è sparito. Senza quella traccia, l’indagine si affida a intuizioni e chat interne. Con storia e automazione, si riduce il tempo a trovare la causa e a ristabilire il servizio^2,4.

4) Pratiche operative: runbook ed evaluation set di proprietà

Strumenti e piattaforme non sostituiscono le pratiche. Un agente funziona alla consegna, poi l’ambiente cambia. Serve un corredo operativo che accompagni il codice⁵.

Primo, un runbook. Deve dire cosa l’agente può fare, cosa non deve mai fare, su quali sistemi può scrivere e cosa fare quando si comporta in modo strano. Va scritto per chi è di turno, non per chi ha costruito l’agente⁵.

Secondo, un evaluation set di proprietà del cliente. Domande e risposte attese non devono dipendere da servizi esterni. Servono per verificare regressioni e comportamenti attesi nel tempo. Quando cambia un modello, un alias o un’API, il set consente di misurare l’impatto in modo ripetibile e indipendente⁵.

Queste pratiche chiudono il cerchio con telemetria selettiva e automazione. Adaptive Telemetry aiuta a conservare i segnali che sostengono diagnosi e automazioni pagando per valore, non per volume¹. Watchers e Investigations trasformano variazioni e allarmi in flussi di lavoro tracciati dove il team già lavora². Lo storico locale di segnali che non lo offrono di default, come la percentuale di utilizzo dell’IDE AI, evita buchi di contesto nelle analisi e nella rendicontazione⁴. Runbook ed evaluation set mettono nelle mani di chi risponde le istruzioni per agire e la base per misurare, anche quando cambia qualcosa a monte⁵.

5) Cosa cambia nel ciclo di vita degli agenti

Per chi costruisce agenti su grafi di stato con strumenti come LangGraph, ogni passo è esplicito, anche quando un LLM decide il prossimo in base al contesto. Le chiamate a API esterne entrano come nodi del grafo³. Questa chiarezza interna aiuta. Ma la resilienza nasce da decisioni fuori dal grafo: quali segnali conservare, come sorvegliarli, dove tenere la storia e come reagire ai cambiamenti esterni.

Tre mosse danno effetti cumulativi. Allineare il budget al valore dei dati conservati, così l’indagine non parte zoppa¹. Automatizzare la sorveglianza e l’investigazione, così il team interviene su cambiamenti che contano e documenta le prove nel flusso di lavoro esistente². Possedere runbook, evaluation set e storia operativa, così si misura e si corregge con indipendenza^4,5.

Chiusura operativa: questi elementi spostano la discussione dai “costi della telemetria” al “costo per incidente risolto”. Con segnali selezionati, storia disponibile e indagini automatizzate, il costo unitario dell’analisi scende e la prevedibilità sale. È il terreno su cui un pilota che funziona diventa un servizio che regge a incidenti, alias che cambiano e finestre di utilizzo che si riempiono quando nessuno sta guardando^1,2,4,5.