Jeff Champagne, Field CTO at Cribl – Intervista della serie

Jeff Champagne, Field CTO at Cribl, porta una profonda esperienza in materia di osservabilità, dati aziendali, strategia di prodotto e architettura tecnica. Prima di unirsi a Cribl, ha ricoperto il ruolo di Direttore del Product Management presso Databricks e ha trascorso più di sette anni presso Splunk in ruoli di senior field product, architettura e ingegneria dei sistemi globali. La sua esperienza include anche la leadership dell’architettura dei sistemi presso BNY ConvergEx, il lavoro di ingegneria senior presso Premier Technology Solutions e la leadership di ingegneria iniziale presso Assist-2-Sell, dandogli una prospettiva ampia su come le aziende raccolgono, gestiscono, analizzano e agiscono sui dati operativi su larga scala.

Cribl è un’azienda di telemetria aziendale che si concentra sull’aiutare i team IT, di sicurezza, SRE e DevOps a raccogliere, elaborare, instradare, archiviare e analizzare i dati di osservabilità e sicurezza senza essere bloccati da un singolo fornitore. L’azienda si posiziona come la “piattaforma AI per la telemetria”, con prodotti come Cribl Stream per la raccolta di telemetria in tempo reale, riduzione, arricchimento e instradamento; Cribl Edge per la raccolta di telemetria dei punti finali vendor-neutral; Cribl Search per la ricerca dei dati in loco; e Cribl Lake per l’archiviazione. La sua missione più ampia è quella di dare alle aziende più controllo, flessibilità ed efficienza mentre i volumi di telemetria crescono e le operazioni guidate dall’AI richiedono dati più puliti e accessibili.

Ha lavorato in Splunk, Databricks e ora Cribl, dandole una visione rara dei dati aziendali, dell’osservabilità e dell’infrastruttura su più cicli tecnologici. Da questa prospettiva, cosa sembra realmente diverso nella sfida di osservabilità creata dall’AI agente?

Nell’osservabilità delle applicazioni, abbiamo sempre avuto a che fare con percorsi di esecuzione complessi e ramificati, tracciando le richieste attraverso i microservizi e correlando i log attraverso sistemi distribuiti. Nelle operazioni di sicurezza, abbiamo affrontato fonti di dati ad alto volume e disparate per rilevare le minacce attraverso sistemi che, sebbene complessi, si comportano in larga misura in modi prevedibili. L’AI agente non reinventa nessuno di questi problemi; li fa esplodere simultaneamente.

Gli agenti concatenano decisioni, invocano strumenti esterni e generano sottogenti in modo dinamico in modi che non sono predefiniti al momento della scrittura. Il grafico di esecuzione non è solo complesso, può essere drasticamente diverso ogni volta, e il volume di telemetria richiesto per ricostruire cosa è effettivamente accaduto cresce esponenzialmente con ogni salto. La raccolta di tutta la telemetria necessaria per rendere i sistemi agente osservabili deve essere sia facile da strumentare che efficiente dal punto di vista dei costi per operare su larga scala. Altrimenti, le aziende faranno lo stesso compromesso che hanno sempre fatto e ridurranno la visibilità per controllare i costi — proprio nel momento sbagliato per diventare ciechi.

Quando le aziende incorporano agenti autonomi nei flussi di lavoro, quali sono le lacune di visibilità più grandi tra ciò che un agente AI è stato chiesto di fare e ciò che effettivamente accade attraverso i sistemi sottostanti?

Gli agenti completano i flussi di lavoro che appaiono di successo in superficie mentre silenziosamente fanno chiamate di strumenti errate, allucinazioni di parametri o si allontanano dall’obiettivo originale. Le conseguenze spesso si manifestano ore dopo in un altro sistema.

La disconnessione di solito inizia nell’interpretazione: una leggera ambiguità nell’istruzione originale viene risolta in modo diverso a seconda di ciò che l’agente recupera dalla memoria, quali strumenti sono disponibili in quel momento o come un passaggio precedente nella catena ha plasmato il suo contesto. Devi anche strumentare i sistemi a valle di cui l’agente dipende, perché un agente può fare una chiamata di database perfettamente formata e comunque restituire una risposta errata se la tabella sottostante non è stata aggiornata perché un lavoro ETL è fallito silenziosamente a monte.

L’agente ha fatto esattamente ciò che gli è stato detto; i dati in cui si è fidato erano semplicemente obsoleti.

Perché gli strumenti di osservabilità tradizionali sono spesso insufficienti per il monitoraggio dei sistemi AI agente?

Innanzitutto, sono stati costruiti intorno a schemi rigidi e proprietari e forme di dati prevedibili. Le tracce agente non si conformano a queste aspettative — sono voluminose, altamente variabili nella struttura e includono tipi di dati come il testo di prompt completo, catene di ragionamento del modello e payload di chiamate di strumenti che gli strumenti legacy non sono stati progettati per ingerire senza un significativo lavoro di trasformazione. Le norme aperte come le convenzioni semantiche GenAI di OpenTelemetry stanno emergendo per affrontare questo, ma molte piattaforme legacy non sono state costruite per approfittarne.

In secondo luogo, l’equazione di scala e costo si rompe rapidamente. Un singolo agente che gestisce carichi di lavoro di produzione può generare più telemetria in un’ora di quanto un intero stack di applicazioni abbia prodotto in un giorno, e la maggior parte delle piattaforme tradizionali addebita in base al volume ingerito e archiviato. Ciò crea un compromesso impossibile — o strumenti tutto e affrontare costi fuori controllo, o ridurre la visibilità nei sistemi in cui ne hai più bisogno.

Quando un agente AI fallisce, come possono le organizzazioni determinare se la causa radice era il modello, il livello di recupero, una dipendenza API, un problema di autorizzazioni o un problema di infrastruttura a valle?

Isolare la causa radice in un fallimento agente è un processo di eliminazione attraverso i livelli. Funziona solo se la tua telemetria copre tutti loro in modo coerente. Segnali di latenza ed errore sulle span del modello indicano il modello LLM stesso. Le span di recupero ti dicono se il contesto restituito era rilevante o obsoleto. Le span di chiamata di strumenti espongono dipendenze API fallite o errori di autorizzazioni.

Come menzionato, hai anche bisogno di telemetria dai sistemi a valle di cui l’agente dipende, perché un agente può fare una chiamata perfettamente formata e comunque produrre una risposta errata se i dati in cui si è fidato non sono stati aggiornati. Nessun singolo segnale racconta tutta la storia, ed è per questo che la correlazione attraverso tutti quei livelli in un unico posto è ciò che separa i team che possono debuggere i fallimenti agente rapidamente da quelli che stanno ancora indovinando.

Quali tipi di dati di telemetria diventano più importanti quando le aziende cercano di comprendere il comportamento degli agenti su larga scala?

La base è ancora MELT — metriche, eventi, log e tracce — ma il peso si sposta notevolmente quando si entra nei sistemi agente. Le metriche ti dicono che qualcosa è sbagliato e i log ti danno il record grezzo di ciò che è accaduto, ma nessuno dei due può ricostruire la catena di ragionamento che un agente ha seguito per arrivare a una risposta errata. È lì che le tracce diventano il segnale più critico.

In un sistema distribuito tradizionale, una traccia ti mostra come una richiesta si è mossa attraverso i servizi. In un sistema agente, ti mostra come un modello ha ragionato su un problema, quali strumenti ha chiamato, quale contesto ha recuperato, dove si è ramificato e cosa ha deciso ad ogni passo. Senza quella traccia, stai guardando un output senza alcun modo per spiegare come ci sei arrivato.

I segnali MELT non scompaiono; le metriche sull’utilizzo del token e sulla latenza sono importanti per i costi e le prestazioni, e i log dai sistemi a valle rimangono essenziali. Ma le tracce sono ciò che rendono il comportamento dell’agente leggibile su larga scala.

Molte discussioni sull’AI si concentrano ancora pesantemente sulle allucinazioni. Le aziende sottovalutano i fallimenti operativi come recupero errato, integrazioni rotte, picchi di latenza o contesto mancante?

La maggior parte delle allucinazioni in produzione non sono fallimenti del modello; sono fallimenti operativi mascherati. Il recupero errato restituisce un contesto obsoleto o incompleto, e il modello riempie il divario con qualcosa di plausibile. Un’integrazione rotta significa che l’agente non ha mai ottenuto i dati di cui aveva bisogno per ragionare correttamente in primo luogo. Il contesto mancante da un lavoro ETL fallito sembra un’allucinazione ma è in realtà un problema di infrastruttura.

Quando i team non possono vedere la differenza, ricorrono a ciò che possono controllare, che è di solito il modello stesso. Iterano sui prompt di sistema, aggiungono guardrail e raffinano i framework di valutazione, e sebbene queste tecniche abbiano un valore reale, stanno trattando un sintomo piuttosto che la causa. Nella mia esperienza, l’investimento ad alto rendimento è quasi sempre la qualità dei dati e la freschezza nel livello di recupero. Un agente ben fondato con dati puliti e aggiornati supererà un agente progettato con prompt ingegnerizzati che lavora con un contesto obsoleto o incompleto.

Man mano che gli agenti diventano più autonomi, cosa dovrebbero registrare, tracciare o monitorare i team aziendali per mantenere la responsabilità senza sopraffarsi con il rumore?

La base è ancora MELT, ma la responsabilità per i sistemi agente richiede la sovrapposizione di un framework di valutazione sulla telemetria tradizionale. Le metriche, gli eventi e i log espongono fallimenti di infrastruttura e integrazioni rotte che possono corrompere il comportamento dell’agente prima che il modello risponda; le tracce ti danno la catena di ragionamento per capire perché è arrivato a una particolare risposta. Ma nessuno dei due ti dice se la risposta era effettivamente corretta, ed è lì che la valutazione LLM-as-judge riempie il divario. Le stesse capacità AI che alimentano gli agenti possono essere utilizzate per valutarli, valutando gli output per accuratezza, basi e completamento del compito su una scala che nessun processo di revisione umana può eguagliare.

Pre-produzione, agisce come una porta di qualità, catturando regressioni prima che raggiungano gli utenti. In produzione, diventa un monitor continuo, campionando il traffico live e segnalando risposte che cadono al di fuori dei limiti accettabili. La chiave per evitare il rumore è riconoscere che non ogni flusso di lavoro agente porta lo stesso rischio, il che significa allontanarsi dal monitoraggio uniforme verso qualcosa che l’industria sta iniziando a chiamare governance human-on-the-loop. Definisci i criteri di comportamento e i limiti di confidenza in anticipo, lascia che gli agenti operino e riserva l’intervento umano per le eccezioni.

Qual è il ruolo che i flussi di telemetria possono svolgere nell’aiutare i team di sicurezza, SRE, dati e AI a lavorare da una visione condivisa del comportamento degli agenti?

I team di sicurezza, SRE, ingegneri dei dati e team AI stanno guardando diverse fette dello stesso problema attraverso strumenti diversi, e nessuno di loro ha l’intero quadro. Il motivo per cui i flussi di telemetria sono diventati una parte standard dell’architettura dei dati aziendali moderna è che risolvono esattamente questo problema: un flusso di telemetria ben governato a monte di tutti gli strumenti garantisce che ogni team lavori con gli stessi dati normalizzati e arricchiti senza agenti e collector personalizzati distribuiti per ogni team.

Questa flessibilità è importante a due livelli. Il primo è la tiering dei dati. Un flusso di telemetria ben progettato ti consente di abbinare i dati alla giusta strategia di archiviazione e analisi in modo da non pagare prezzi di analisi per i dati di cui hai bisogno solo per la conservazione a lungo termine. Il secondo è l’opzionalità mentre il paesaggio degli strumenti AI continua a evolversi rapidamente. Le aziende che costruiscono la loro strategia di osservabilità intorno all’ecosistema di un singolo fornitore affronteranno costosi progetti di migrazione ogni volta che emerge uno strumento migliore.

Quali errori sta vedendo le aziende fare quando cercano di adattare le pratiche di monitoraggio esistenti alle distribuzioni di AI agente?

L’errore più comune che vedo è quello di ricorrere alle piattaforme di osservabilità premium esistenti per raccogliere le tracce degli agenti senza pensare alle implicazioni dei costi in primo luogo. Le tracce agente sono grandi, variabili e voluminose in modi in cui la telemetria delle applicazioni tradizionali non lo è, e la maggior parte delle piattaforme premium addebita in base all’ingestione e all’archiviazione. La bolletta può diventare un problema serio prima che i team si rendano conto di cosa sta accadendo, e la risposta tipica è ridurre ciò che raccolgono. Il risultato è il peggio di entrambi i mondi: costo elevato e visibilità incompleta.

Il secondo errore è applicare il modello mentale sbagliato a ciò che il monitoraggio è destinato a rispondere. Il monitoraggio dell’infrastruttura tradizionale chiede “il sistema è up?” e solleva avvisi quando non lo è. Quella domanda è necessaria ma non è nemmeno lontanamente sufficiente per i sistemi agente, dove l’infrastruttura può essere perfettamente sana mentre l’agente sta silenziosamente prendendo decisioni scadenti, recuperando dati obsoleti o allontanandosi dal suo obiettivo originale. I team che adattano i dashboard esistenti e le soglie di allarme ai flussi di lavoro degli agenti spesso si convincono di avere una copertura quando in realtà stanno solo guardando la tubazione.

Il terzo errore è trattare la strumentazione come un ripensamento. Le aziende che pilotano rapidamente gli agenti e si spostano in produzione senza pensare all’osservabilità finiscono in costosi cicli di rimedio, ricostruendo l’architettura di raccolta dei dati dopo il primo fallimento di produzione significativo. I team che scalano le distribuzioni degli agenti con più successo strumentano in anticipo, stabiliscono basi mentre il traffico è basso e il comportamento è prevedibile, e costruiscono il loro framework di valutazione prima di averne bisogno piuttosto che dopo che qualcosa va storto.

Guardando avanti, l’infrastruttura della visibilità diventerà una condizione preliminare per l’adozione dell’AI aziendale allo stesso modo in cui l’osservabilità del cloud è diventata essenziale per la migrazione del cloud su larga scala?

Il parallelo con il cloud è estremamente simile. La cosa più importante che dico ai clienti quando spostano l’infrastruttura nel cloud è che non stanno sollevando e spostando. Stanno distribuendo una nuova architettura con nuove capacità. Tutto ciò deve essere strumentato e monitorato in modi in cui gli strumenti precedenti non erano probabilmente stati impostati. Le aziende che hanno saltato questo passaggio si sono imbattute in fallimenti a catena che non potevano diagnosticare, costi incontrollabili che non potevano spiegare e interruzioni che non potevano prevenire. L’osservabilità è diventata la base della fiducia che ha reso possibile la scala del cloud, e lo stesso modello si sta svolgendo ora con l’AI agente, muovendosi più velocemente e con poste in gioco più elevate.

Il motivo principale per cui gli agenti avranno bisogno di questo tipo di supervisione indefinitamente è che sono progettati per essere non deterministici, il loro comportamento emerge al runtime e la loro capacità effettiva cresce ogni volta che si connette un nuovo strumento. La certificazione statica pre-distribuzione non può coprire un sistema il cui livello di azione cambia con ogni integrazione. Gli agenti opereranno all’interno di confini di fiducia definiti, e quei confini si espanderanno nel tempo man mano che l’infrastruttura di osservabilità, politica e valutazione matura. I confini stessi non scompariranno mai, e ciò non è uno stato di fallimento. È così che ogni sistema autonomo conseguente nel mondo funziona già.

Grazie per la grande intervista, i lettori che desiderano saperne di più possono visitare Cribl.