Jeff Champagne, Field CTO på Cribl – Intervjuserie

Jeff Champagne, Field CTO på Cribl, har djup erfarenhet inom observability, företagsdata, produktstrategi och teknisk arkitektur. Innan han gick med i Cribl var han Director of Product Management på Databricks och tillbringade mer än sju år på Splunk i seniora roller inom fältprodukt, arkitektur och globala systemingenjörer. Hans bakgrund omfattar också ledarskap inom systemarkitektur på BNY ConvergEx, seniora ingenjörsarbeten på Premier Technology Solutions och tidiga ingenjörsledarroller på Assist-2-Sell, vilket ger honom en bred perspektiv på hur företag samlar in, hanterar, analyserar och agerar på operativa data i stor skala.

Cribl är ett företag inom telemetri som fokuserar på att hjälpa IT-, säkerhets-, SRE- och DevOps-team att samla in, bearbeta, dirigera, lagra och analysera observations- och säkerhetsdata utan att vara låsta till en enskild leverantör. Företaget positionerar sig som “AI-plattform för telemetri”, med produkter som Cribl Stream för insamling, reduktion, berikning och dirigeringsverktyg för telemetri i realtid; Cribl Edge för leverantörsneutral insamling av telemetri från slutpunkter; Cribl Search för sökning av data på plats; och Cribl Lake för lagring. Dess bredare uppdrag är att ge företag mer kontroll, flexibilitet och effektivitet när telemetridata växer och AI-drivna operationer kräver renare, mer tillgängliga data.

Du har arbetat på Splunk, Databricks och nu Cribl, vilket ger dig en sällsynt vy över företagsdata, observability och infrastruktur över flera tekniska cykler. Från det perspektivet, vad känns verkligen annorlunda om observability-utmaningen som skapas av agenter med AI?

I applikationsobservability har vi alltid hanterat komplexa, grenade exekveringsvägar, spårat förfrågningar genom mikrotjänster och korrelerat loggar över distribuerade system. I säkerhetsoperationer har vi hanterat högvolym, disparata datakällor för att upptäcka hot över system som, även om de är komplexa, fortfarande beter sig på förutsägbara sätt. Agenter med AI återuppfinnar inte något av dessa problem; de spränger dem samtidigt.

Agenter kedjar beslut, anropar externa verktyg och genererar underagenter dynamiskt på sätt som inte är förutbestämda vid skrivtid. Exekveringsgrafen är inte bara komplex, den kan vara vilt annorlunda varje gång, och volymen av telemetri som krävs för att rekonstruera vad som verkligen hände växer exponentiellt med varje hopp. Insamling av all telemetri som behövs för att göra agenter med AI observerbara måste vara både enkelt att instrumentera och kostnadseffektivt att driva i stor skala. Annars kommer företag att göra samma avvägning som de alltid har och minska synligheten för att kontrollera kostnader — exakt fel tid att bli blind.

När företag integrerar autonoma agenter i arbetsflöden, var är de största synligahetsgapen mellan vad en AI-agent blir ombedd att göra och vad som verkligen händer över de underliggande systemen?

Agenter slutför arbetsflöden som ser framgångsrika ut på ytan medan de tyst gör dåliga verktygsanrop, hallucinerar parametrar eller drar sig ifrån det ursprungliga målet. Konsekvenserna dyker ofta upp senare i ett annat system.

Frånkopplingen börjar vanligtvis vid tolkning: en liten tvetydighet i den ursprungliga instruktionen löses på olika sätt beroende på vad agenten hämtar från minnet, vilka verktyg som är tillgängliga just då eller hur en tidigare steg i kedjan formade dess sammanhang. Du måste också instrumentera de nedströms system som agenten är beroende av, eftersom en agent kan göra ett perfekt välformat databasanrop och fortfarande returnera ett felaktigt svar om den underliggande tabellen aldrig uppdaterades eftersom ett ETL-jobb misslyckades tyst uppströms.

Agenten gjorde exakt vad den blev ombedd att göra; de data den litade på var bara inaktuella.

Varför är traditionella observationsverktyg ofta otillräckliga för att övervaka agenter med AI?

För det första byggdes de runt rigida, proprietära scheman och förutsägbara dataformer. Agenter med AI följer inte dessa förväntningar — de är volymösa, mycket varierande i struktur och innehåller datatyper som fullständig prompttext, modellresonemangskedjor och verktygsanropsnyttolaster som äldre verktyg inte var utformade för att ta emot utan betydande omvandlingsarbete. Öppna standarder som OpenTelemetris GenAI-semantiska konventioner dyker upp för att hantera detta, men många äldre plattformar byggdes inte för att dra nytta av dem.

För det andra bryts skalekvationen och kostnaden snabbt. En enda agent som hanterar produktionsarbetsbelastningar kan generera mer telemetri på en timme än en hel applikationsstack producerade på en dag, och de flesta traditionella plattformar tar betalt per volym som tas emot och lagras. Det skapar en omöjlig avvägning — antingen instrumenterar du allt och står inför springande kostnader, eller minskar du synligheten i systemen där du behöver den mest.

När en AI-agent misslyckas, hur kan organisationer avgöra om roten till problemet var modellen, återställningsskiktet, ett API-beroende, ett behörighetsproblem eller ett nedströms infrastrukturproblem?

Att isolera roten till problemet i ett agenter-fejl är en process för att utesluta lager. Det fungerar bara om din telemetri omfattar alla lager konsekvent. Latens- och felssignaler på modellspannen pekar på LLM själv. Återställningsspann berättar om kontexten som returnerades var relevant eller inaktuell. Verktygsanropsspann avslöjar misslyckade API-beroenden eller behörighetsfel.

Som nämnts tidigare behöver du också telemetri från de nedströms system som agenten är beroende av, eftersom en agent kan göra ett perfekt välformat anrop och fortfarande producera ett felaktigt svar om de data den litade på aldrig uppdaterades. Inget enskilt signal berättar hela historien, vilket är varför korrelering över alla dessa lager på en plats är vad skiljer team som kan felsöka agenter snabbt från de som fortfarande gissar.

Vilken typ av telemetri-data blir mest viktig när företag försöker förstå agentbeteende i stor skala?

Grundvalen är fortfarande MELT — mått, händelser, loggar och spår — men tyngdpunkten skiftar avsevärt när du flyttar in i agenter med AI. Mått berättar om att något är fel och loggar ger dig den råa posten om vad som hände, men ingen av dem kan rekonstruera kedjan av resonemang som en agent följde för att komma till ett felaktigt svar. Det är där spår blir den mest kritiska signalen.

I ett traditionellt distribuerat system visar ett spår hur en förfrågan flyttade genom tjänster. I ett system med agenter visar det hur en modell resonerade genom ett problem, vilka verktyg den anropade, vilken kontext den hämtade, var den grenade och vad den beslutade vid varje steg. Utan det spåret tittar du på en utdata utan att kunna förklara hur du kom dit.

De andra MELT-signalerna försvinner inte; mått på tokenanvändning och latens är viktiga för kostnad och prestanda, och loggar från nedströms system förblir avgörande. Men spår är vad som gör agentbeteende läsbart i stor skala.

Många AI-diskussioner fokuserar fortfarande tungt på hallucinationer. Underskattar företag operativa fel som dåliga återställningar, trasiga integrationer, latenshopp eller saknad kontext?

De flesta hallucinationer i produktion är inte modellfel; de är operativa fel i förklädnad. Dåliga återställningar returnerar inaktuella eller ofullständiga kontexter, och modellen fyller luckan med något som låter trovärdigt. En trasig integration betyder att agenten aldrig fick de data den behövde för att resonera korrekt från början. Saknad kontext från ett misslyckat ETL-jobb ser ut som en hallucination men är egentligen ett infrastrukturproblem.

När team inte kan se skillnaden, defaultar de till vad de kan kontrollera, vilket vanligtvis är modellen själv. De itererar på systemprompt, lägger till skydd och förfinar utvärderingsramverk, och medan dessa tekniker har verklig värde, behandlar de ett symptom snarare än orsaken. I min erfarenhet är den högsta vinsten nästan alltid datakvalitet och färskhet i återställningsskiktet. En välgrundad agent med ren, aktuell data kommer att prestera bättre än en tungt prompt-engineerad som arbetar från inaktuell eller ofullständig kontext.

När agenter blir mer autonoma, vad bör företagsgrupper logga, spåra eller övervaka för att upprätthålla ansvar utan att överväldigas av brus?

Grundvalen är fortfarande MELT, men ansvar för agenter med AI kräver lagring av en utvärderingsram ovanpå traditionell telemetri. Mått, händelser och loggar ytan infrastrukturproblem och trasiga integrationer som kan korrumpera agentbeteende innan modellen svarar; spår ger dig kedjan av resonemang för att förstå varför den kom till ett visst svar. Men ingen av dem berättar om svaret verkligen var korrekt, och det är där LLM som-domare-utvärdering fyller gapet. Samma AI-kapaciteter som driver agenter kan användas för att bedöma dem, poängsätta utdata för noggrannhet, grund och uppgiftsslutförande i en skala som ingen mänsklig granskningsprocess kan matcha.

Före produktion fungerar det som en kvalitetsgrind, som fångar regressioner innan de når användare. I produktion blir det en kontinuerlig övervakare, som sampar live-trafik och flaggar svar som ligger utanför acceptabla trösklar. Nyckeln till att undvika brus är att inse att inte alla agentarbetsflöden bär samma risk, vilket innebär att man flyttar bort från enhetlig övervakning mot något som branschen börjar kalla human-on-the-loop-styrning. Du definierar beteendebaslinjer och förtroendetrösklar i förväg, låter agenter operera dem och reserverar mänskligt ingripande för undantag.

Vilken roll kan telemetri-pipelines spela för att hjälpa säkerhets-, SRE-, data- och AI-team att arbeta från en gemensam vy av agentbeteende?

Säkerhetsteam, SRE:er, dataingenjörer och AI-team tittar alla på olika skivor av samma problem genom olika verktyg, och ingen av dem har den fulla bilden på egen hand. Anledningen till att telemetri-pipelines har blivit en standarddel av modern företagsdataarkitektur är att de löser exakt detta problem: en enda, välstyrda pipeline uppströms om alla dina verktyg säkerställer att varje team arbetar från samma normaliserade, berikade data utan skräddarsydda agenter och samlare som distribueras för varje team.

Den flexibiliteten är viktig på två nivåer. Den första är datatiering. En välutformad telemetri-pipeline låter dig matcha data till rätt lagrings- och analysstrategi så att du inte betalar analytics-nivåpriser för data som du bara behöver för långsiktig efterlevnad. Den andra är valfrihet när AI-verktygslandskapet fortsätter att utvecklas snabbt. Företag som bygger sin observationsstrategi runt en enskild leverantörs ekosystem kommer att stå inför dyra migrationsprojekt varje gång ett bättre verktyg dyker upp.

Vilka misstag ser du att företag gör när de försöker återanvända befintliga övervakningspraxis på agenter med AI?

Det vanligaste misstaget jag ser är att sträcka sig efter befintliga premium-observationsplattformar för att samla in agent-spår utan att tänka igenom kostnadseffekterna först. Agenter med AI-spår är stora, varierande och volymösa på sätt som traditionell applikationstelemetri inte är, och de flesta premiumplattformar tar betalt per insamling och lagring. Notan kan bli ett allvarligt problem innan team ens inser vad som händer, och det typiska svaret är att minska vad de samlar in. Resultatet är värsta möjliga värld: höga kostnader och ofullständig synlighet.

Det andra misstaget är att applicera fel mental modell på vad övervakning är tänkt att besvara. Traditionell infrastrukturovervakning frågar “är systemet uppe?” och höjer larm när det inte är det. Den frågan är nödvändig men långt ifrån tillräcklig för agenter med AI, där infrastrukturen kan vara perfekt frisk medan agenten tyst gör dåliga beslut, hämtar inaktuella data eller drar sig ifrån sitt ursprungliga mål. Team som återanvänder befintliga instrumentpaneler och larmtrösklar på agentarbetsflöden övertygar ofta sig själva om att de har täckning när de i själva verket bara tittar på rörledningen.

Det tredje misstaget är att behandla instrumentering som en eftertanke. Företag som piloterar agenter snabbt och flyttar till produktion utan att tänka igenom observationsbarheten hamnar i dyra felsökningscykler, bygger om datainsamlingarkitektur efter den första betydande produktionsfelet. Team som skalar agentdistributioner mest framgångsrikt instrumenterar tidigt, etablerar baslinjer medan trafik är låg och beteende är förutsägbart, och bygger sin utvärderingsram innan de behöver den snarare än efter att något gått fel.

Om man tittar framåt, kommer infrastruktur synlighet att bli ett krav för företags AI-antagande på samma sätt som molnobservationsbarhet blev avgörande för stor skala molnmigration?

Parallellen till molnet är extremt liknande. Det viktigaste jag berättar för kunder när de flyttar infrastruktur till molnet är att de inte lyfter och flyttar. De distribuerar en helt ny arkitektur med nya förmågor. Allt detta måste instrumenteras och övervakas på sätt som tidigare verktyg troligen inte var utformade för. Företag som hoppade över det steget stötte på kaskaderande fel som de inte kunde diagnostisera, spiralerande kostnader som de inte kunde förklara och driftstopp som de inte kunde förhindra. Observability blev grunden för tillit som gjorde molnskala möjlig, och samma mönster utspelar sig nu med agenter med AI, som flyttar snabbare och med högre insatser.

Den primära anledningen till att agenter kommer att behöva den här typen av tillsyn på obestämd tid är att de är icke-deterministiska av design, deras beteende uppstår vid körning och deras effektiva förmåga växer varje gång du ansluter ett nytt verktyg. Statisk förkörningscertifiering kan inte täcka ett system vars aktionsyta förändras med varje integration. Agenter kommer att operera inom definierade gränser för tillit, och dessa gränser kommer att expandera över tid när observations-, policy- och utvärderingsinfrastruktur mognar. Gränserna i sig kommer aldrig att försvinna, och det är inte ett felaktigt tillstånd. Det är hur varje betydande autonomt system i världen redan fungerar.

Tack för den underbara intervjun, läsare som vill lära sig mer bör besöka Cribl.