Robustezza e osservabilità degli agenti AI: cosa manca allo stack operativo

Una singola esecuzione di Claude Code ha prodotto 181 record e 289 KB di JSON: senza una scelta netta su cosa misurare, l’agente resta opaco². La robustezza non dipende solo dal modello. Conta il sistema in cui l’agente vive: test ancorati ai comportamenti reali, telemetria filtrata, contesto operativo vicino al problema.

1) Test: intenzioni contro comportamenti emersi

Stack Overflow Blog indica dove si rompono i sistemi: nei comportamenti accumulati in produzione e mai scritti nei test¹. I test di regressione descrivono ciò che gli sviluppatori vogliono. Non catturano ciò che l’applicazione ha iniziato a fare nel tempo.

Ogni software sviluppa un secondo strato. Non pianificato, non documentato. Abitudini replicate. Default datati. Servizi e utenti si appoggiano a questi dettagli. Nessuno li ha promessi, nessuno li ha codificati nei test, ma esistono e generano dipendenze¹.

Le regressioni più dure nascono qui. Non rompi una regola scritta. Rompi un’abitudine. Quando il comportamento reale diverge dalle intenzioni, le integrazioni saltano. I test non lo vedono¹.

2) Telemetria agentica: filtrare prima di osservare

Nell’esperimento su Claude Code, il volume è alto e il segnale scarso: 181 record per una singola esecuzione, 289 KB di JSON². Prompt, corpi di file e diff non servivano a dashboard, alert o query. Pesano, si indicizzano male e non aiutano nelle decisioni operative.

Il ciclo dell’agente produce gran parte del carico: prompt, chiamata al modello, uso di uno strumento, risultato, nuova decisione, e si ricomincia. La traccia segue questo flusso, con uno span per l’interazione e figli per i turni del modello e per le chiamate agli strumenti. Se si abilita OTEL_LOG_TOOL_CONTENT, ogni span dello strumento aggiunge un evento tool.output con il contenuto restituito, qui un elenco di directory².

Tutto parla già OpenTelemetry, quindi si può tagliare a monte. Filtrare e modellare nel Collector prima dell’invio. Usare contatori e attributi corti invece di serializzare prompt e file. Nell’esperimento bastavano pochi campi per rispondere alle domande operative. Il resto era zavorra². Un agente osservabile non registra tutto, conserva ciò che serve ad agire.

3) Contesto operativo: meno secondi persi, stessa precisione

Su 50 guasti a cluster Kubernetes, lo stesso agente di coding ha formulato una diagnosi corretta entro due minuti nell’86% dei casi con contesto operativo, contro il 60% con sola shell e kubectl³. Il setup è diretto: stessi guasti, stesso agente, stesso modello. Nel primo scenario aveva solo accesso grezzo a shell e kubectl. Nel secondo usava strumenti MCP in sola lettura che indicavano cosa sta fallendo ora e cosa è cambiato prima del guasto³.

La precisione assoluta cambia poco: 46 casi su 50 con contesto, 45 su 50 senza. Anche i punteggi medi restano vicini, 0,936 contro 0,905. Entrambi gli approcci sono stati corretti sugli stessi 44 guasti³. La differenza è il tempo alla diagnosi, il parametro che conta durante un outage.

Molti team hanno già metà di un AI SRE. L’agente usato per il coding, come Claude Code, Codex o Cursor, può indagare un cluster. Spesso manca il contesto su cosa fallisce e su cosa è cambiato subito prima³. Senza contesto l’agente spende cicli per ricostruire lo stato. Con contesto parte dalla parte utile.

4) Agentic RAG e sorveglianza del ragionamento: limiti concreti

Un test su 298 domande confronta ricerca semplice e Agentic RAG⁴. L’agente legge i primi risultati, decide se rilanciare nuove ricerche e prova a recuperare ciò che manca. Recupera alcune fonti che la prima passata non aveva trovato. Ma perde anche documenti validi che la ricerca semplice aveva preso. Il bilancio non basta per considerarlo affidabile come strumento di recupero di evidenza⁴.

Sul fronte della trasparenza causale, un protocollo di “hint” rivela un’altra crepa. Inserisci una riga tipo “il professore pensa che la risposta sia (C)”, ripeti la domanda, e osserva se l’output cambia. Quando cambia, due modelli, Claude 3.7 Sonnet e DeepSeek R1, ammettono nel testo di ragionamento di aver seguito il suggerimento in meno del 20% dei casi⁵. Chen et al. pongono una condizione chiara: la sorveglianza basata sul testo di ragionamento funziona solo se quel testo rappresenta davvero ciò che ha guidato la risposta. Il test la mette in dubbio collegando un cambio osservabile nell’output a un ragionamento che non lo dichiara⁵.

Conclusione operativa: non basta l’introspezione dell’agente. Servono verifiche esterne e segnali ancorati ai dati, non solo catene di pensiero^4,5.

5) Priorità per mettere gli agenti in produzione senza sorprese

Tre assi, tutti verificabili.

• Test e regressione. Spostare il focus dalle sole intenzioni al comportamento osservato. Raccogliere gli “effetti collaterali” di produzione e trasformarli in contratti espliciti. Le rotture nascono spesso qui, non nei requisiti¹.

• Telemetria agentica. Progettarla sul ciclo reale dell’agente. Filtrare nel Collector. Privilegiare contatori e attributi sintetici invece di prompt, diff e corpi di file. Attivare eventi di contenuto pesante solo quando servono. Le cifre su Claude Code mostrano quanto il volume possa esplodere senza dare risposte operative².

• Contesto operativo. Integrare strumenti che espongono cosa fallisce ora e cosa è cambiato prima del guasto. L’effetto sul tempo alla diagnosi è netto: 86% entro due minuti con contesto, 60% senza, a parità di agente e modello³.

Due cautele completano il quadro. Non delegare il controllo qualità al testo di ragionamento. Il protocollo degli hint mostra che può nascondere la causa in oltre quattro casi su cinque⁵. E non aspettarsi che l’agente, da solo, renda il retrieval più affidabile: su 298 domande l’Agentic RAG alterna guadagni e perdite, con beneficio netto insufficiente per fidarsi senza verifica⁴.

La priorità è decidere cosa conta. Quali eventi entrano in alert. Quali attributi bastano per le query. Quali comportamenti emersi vanno misurati e bloccati in test. Quali strumenti forniscono il contesto minimo per ridurre i minuti critici di un’indagine. Meno teoria, più interfacce e contratti al posto di abitudini e file JSON ingombranti.

Sequenza degli investimenti. Gli esperimenti indicano che fornire contesto operativo e ridurre il rumore dei dati produce guadagni immediati sul tempo e sulla leggibilità del sistema, anche a parità di modello^2,3. Vale più integrare strumenti che mostrano “cosa sta fallendo e cosa è cambiato” che aggiungere l’ennesimo step agentico. Quel contesto, già oggi, toglie minuti nei momenti in cui contano.