Jeff Champagne, Field CTO i Cribl – Intervju-serie

Jeff Champagne, Field CTO i Cribl, bringer dypt erfaring fra overvåkning, bedriftsdata, produktstrategi og teknisk arkitektur. Før han ble med i Cribl, var han direktør for produktledelse i Databricks og tilbrakte mer enn syv år i Splunk i senior stillinger innen produktledelse, arkitektur og globale systemer. Hans bakgrunn inkluderer også ledelse av systemarkitektur i BNY ConvergEx, senior ingeniørarbeid i Premier Technology Solutions og tidlig ingeniørledelse i Assist-2-Sell, noe som gir ham en bred perspektiv på hvordan bedrifter samler inn, behandler, analyserer og handler på operasjonelle data i stor skala.

Cribl er et bedrifts-telemetri-selskap som fokuserer på å hjelpe IT, sikkerhet, SRE og DevOps-team med å samle inn, prosessere, dirigere, lagre og analysere overvåkings- og sikkerhetsdata uten å bli låst til en enkelt leverandør. Selskapet stiller seg selv som “AI-plattform for telemetri”, med produkter som Cribl Stream for sanntids-telemetri-samling, reduksjon, beriking og dirigering; Cribl Edge for leverandør-uavhengig endpoint-telemetri-samling; Cribl Search for søking av data på plass; og Cribl Lake for lagring. Dets bredere mål er å gi bedriftene mer kontroll, fleksibilitet og effisiens ettersom telemetri-volumer vokser og AI-drevne operasjoner krever renere, mer tilgjengelige data.

Du har arbeidet i Splunk, Databricks og nå Cribl, noe som gir deg en sjelden oversikt over bedriftsdata, overvåkning og infrastruktur over flere tekniske sykluser. Fra dette perspektivet, hva føles egentlig annerledes om overvåkningsutfordringen skapt av agens-ai?

I applikasjons-overvåkning har vi alltid håndtert komplekse, forgrenede eksekveringsbaner, sporingsforespørsler gjennom mikrotjenester og korrelasjon av logger over distribuerte systemer. I sikkerhetsoperasjoner har vi taklet høyt-volum, ulike datakilder for å detektere trusler over systemer som, selv om de er komplekse, likevel oppfører seg på en forutsigbar måte. Agens-ai gjør ikke om disse problemene; det eksploderer dem samtidig.

Agenter kjeder beslutninger, invoker eksterne verktøy og genererer under-agenter dynamisk på måter som ikke er forhåndsbestemt på skrive-tid. Eksekverings-grafen er ikke bare kompleks, men kan også være veldig annerledes hver gang, og volumet av telemetri som kreves for å rekonstruere hva som faktisk skjedde, øker eksponentielt med hver hop. Samling av all telemetri som trengs for å gjøre agens-systemer overvåkbare, må være både enkelt å instrumentere og kostnadseffektivt å operere i stor skala. Ellers vil bedriftene gjøre samme valg som de alltid har gjort, og redusere synlighet for å kontrollere kostnadene — akkurat feil tid å bli blind.

Når bedrifter integrerer autonome agenter i arbeidsflyter, hvor er de største synlighetsgapene mellom hva en ai-agent blir bedt om å gjøre og hva som faktisk skjer over underliggende systemer?

Agenter fullfører arbeidsflyter som ser suksessfulle ut på overflaten, mens de stille gjør dårlige verktøy-kall, hallucinerer parametre eller drifter fra den opprinnelige målet. Konsekvensene dukker ofte opp timer senere i et annet system.

Disconnecten starter vanligvis med tolkning: en liten tvetydighet i den opprinnelige instruksjonen løses annerledes avhengig av hva agenten henter fra minne, hva verktøy som er tilgjengelige på det tidspunktet eller hvordan en tidligere trinn i kjeden formet dens kontekst. Du må også instrumentere de underliggende systemene som agenten er avhengig av, fordi en agent kan gjøre et fullstendig godt database-kall og likevel returnere et feil svar hvis den underliggende tabellen aldri ble oppdatert fordi en ETL-jobb feilet stille.

Agenten gjorde akkurat hva den ble bedt om å gjøre; data den stole på var bare utdatert.

Hvorfor er tradisjonelle overvåkningsverktøy ofte utilstrekkelige for å overvåke agens-ai-systemer?

Først og fremst ble de bygget rundt stive, proprietære skjemaer og forutsigbare data-former. Agens-sporene konformerer seg ikke til disse forventningene — de er voluminøse, høyt variable i struktur og inkluderer data-typer som fullt prompt-tekst, modell-resonans-kjeder og verktøy-kall-nyttestoffer som legacy-verktøy ikke var designet til å inngå uten betydelig transformasjonsarbeid. Åpne standarder som OpenTelemetris GenAI-semantiske konvensjoner dukker opp for å løse dette problemet, men mange legacy-plattformer ble ikke bygget for å dra nytte av dem.

For det andre, skjer kostnads- og skala-ligningen raskt. En enkelt agent som håndterer produksjonsarbeidsflyter kan generere mer telemetri på en time enn en hel applikasjonsstakk produserte på en dag, og de fleste tradisjonelle plattformer fakturerer etter volum og lagring. Det skaper en umulig avveiing — enten instrumenterer du alt og møter løpende kostnader, eller reduserer du synlighet inn i systemene hvor du trenger det mest.

Når en ai-agent feiler, hvordan kan organisasjoner bestemme om roten til feilen var modellen, innhenting-laget, en api-avhengighet, en tillatelsesproblematikk eller et nedstrøms-infrastrukturproblem?

Isolasjon av roten til feilen i en agens-feil er en prosess med eliminering over lag. Det fungerer bare hvis din telemetri dekker alle lagene jevnt. Latens- og feil-signaler på modell-sporene peker mot LLM selv. Innhentings-sporene forteller deg om konteksten som ble returnert var relevant eller utdatert. Verktøy-kall-sporene avdekker feilte api-avhengigheter eller tillatelsesfeil.

Som nevnt, trenger du også telemetri fra de underliggende systemene som agenten er avhengig av, fordi en agent kan gjøre et fullstendig godt kall og likevel produsere et feil svar hvis data den stole på aldri ble oppdatert. Ingen enkelt signal forteller hele historien, noe som er grunnen til at korrelasjon over alle disse lagene på ett sted er hva skiller teamene som kan feilsøke agens-feil raskt fra de som fortsatt gjetter.

Hva slags telemetri-data blir mest viktig når bedrifter prøver å forstå agent-atferd i stor skala?

Grunnlaget er fortsatt MELT — målinger, hendelser, logger og sporene — men vekten skifter betraktelig når du går inn i agens-systemer. Målinger forteller deg at noe er galt og logger gir deg den rå rekorden av hva skjedde, men ingen av dem kan rekonstruere beslutnings-kjeden en agent fulgte for å nå et feil svar. Det er der sporene blir det mest kritiske signalet.

I et tradisjonelt distribuert system viser en spor hvordan en forespørsel beveget seg gjennom tjenester. I et agens-system viser det hvordan en modell resonnerte gjennom et problem, hvilke verktøy den kalte, hva kontekst den hentet, hvor den grenset og hva den bestemte på hvert trinn. Uten den sporen er du bare å se på en utgang uten å kunne forklare hvordan du kom dit.

De andre MELT-signalene forsvinner ikke; målinger på token-bruk og latens er viktige for kostnad og ytelse, og logger fra nedstrøms-systemer er fortsatt essensielle. Men sporene er hva gjør agent-atferd leselig i stor skala.

Mange ai-diskusjoner fokuserer fortsatt tungt på hallucinasjoner. Undervurderer bedrifter operasjonelle feil som dårlige innhentinger, brutte integrasjoner, latens-spor eller manglende kontekst?

De fleste hallucinasjoner i produksjon er ikke modell-feil; de er operasjonelle feil i forkledning. Dårlig innhenting returnerer utdatert eller ufullstendig kontekst, og modellen fyller gapet med noe som høres plausibelt ut. En brutt integrasjon betyr at agenten aldri fikk data den trengte for å resonnere riktig fra begynnelsen av. Manglende kontekst fra en feilet ETL-jobb ser ut som en hallucinasjon, men er egentlig et infrastruktur-problem.

Når teamene ikke kan se forskjellen, faller de tilbake til hva de kan kontrollere, som vanligvis er modellen selv. De itererer på system-prompter, legger til sikkerhetsskranke og finjusterer evaluering-rammeverk, og selv om disse teknikkene har virkelig verdi, behandler de et symptom i stedet for årsaken. I min erfaring er den høyest-leverende investeringen nesten alltid data-kvalitet og ferskhet i innhentings-laget. En godt-grunnlagt agent med ren, oppdatert data vil overgå en tungt prompt-engineert en som arbeider fra utdatert eller ufullstendig kontekst hver gang.

Når agenter blir mer autonome, hva bør bedrifts-team logge, spor eller overvåke for å opprettholde ansvar uten å overvelde seg selv med støy?

Grunnlaget er fortsatt MELT, men ansvar for agens-systemer krever lagring av en evaluering-rammeverk på toppen av tradisjonell telemetri. Målinger, hendelser og logger avdekker infrastruktur-feil og brutte integrasjoner som kan forurense agent-atferd før modellen responderer; sporene gir deg beslutnings-kjeden for å forstå hvorfor den nådde et bestemt svar. Men ingen av dem forteller deg om svaret faktisk var riktig, og det er der LLM- som-dommer-evaluering fyller gapet. De samme ai-kapasiteter som driver agenter kan brukes til å vurdere dem, scoring utganger for nøyaktighet, grunnlag og oppgave-fullføring på en skala ingen menneskelig gjennomgangsprosess kan matche.

Før produksjon, fungerer det som en kvalitetsport, fanger regressioner før de når brukerne. I produksjon blir det en kontinuerlig overvåker, sampling live-trafikk og flagging svar som faller utenfor akseptable terskler. Nøkkelen til å unngå støy er å erkjenne at ikke alle agent-arbeidsflyter bærer samme risiko, noe som betyr å gå bort fra uniform overvåking mot noe bransjen begynner å kalle human-on-the-loop-styring. Du definerer atferds-baselinjer og tillits-terskler på forhånd, lar agenter operere dem og reserverer menneskelig inngripen for unntak.

Hva slags rolle kan telemetri-pipelines spille i å hjelpe sikkerhets-, SRE-, data- og ai-team å arbeide fra en felles visning av agent-atferd?

Sikkerhets-team, SRE-er, data-ingeniører og ai-team ser alle på ulike deler av samme problemet gjennom ulike verktøy, og ingen av dem har det fullstendige bildet på egen hånd. Grunnen til at telemetri-pipelines har blitt en standard-del av moderne bedrifts-data-arkitektur er at de løser nettopp dette problemet: en enkelt, godt styrt pipeline oppstrøms av alle dine verktøy sikrer at alle team arbeider fra samme normaliserte, berikede data uten å måtte deploye spesifikke agenter og samler for hvert team.

Denne fleksibiliteten er viktig på to nivåer. Først og fremst er det data-nivå. En godt designet telemetri-pipeline lar deg matche data med riktig lagrings- og analyse-strategi, så du ikke betaler analytics-nivå-priser for data du bare trenger for langtids-kompatibilitets-lagring. For det andre er det valgmulighet når ai-verktøy-landskapet fortsetter å utvikle seg raskt. Bedrifter som bygger sin overvåknings-strategi rundt en enkelt leverandørs økosystem vil møte dyre migreringsprosjekter hver gang et bedre verktøy dukker opp.

Hva feil ser du bedrifter gjøre når de prøver å tilpasse eksisterende overvåknings-praksis til agens-ai-utsteder?

Den vanligste feilen jeg ser er å nå etter eksisterende premium-overvåknings-plattformer for å samle inn agent-sporene uten å tenke gjennom kostnads-implikasjonene først. Agens-sporene er store, variable og voluminøse på måter som tradisjonell applikasjons-telemetri ikke er. De fleste premium-plattformer fakturerer etter inntak og lagring. Regningen kan bli et alvorlig problem før teamene engang innser hva som skjer, og den typiske responsen er å redusere hva de samler inn. Resultatet er det verste av begge verdener: høye kostnader og ufullstendig synlighet.

Den andre feilen er å bruke feil mentalt modell til hva overvåking er ment å svare på. Tradisjonell infrastruktur-overvåking spør “er systemet opp?” og gir varsler når det ikke er det. Den spørsmålet er nødvendig, men langt ifra tilstrekkelig for agens-systemer, hvor infrastrukturen kan være fullstendig sunn mens agenten stille gjør dårlige beslutninger, henter utdatert data eller drifter fra den opprinnelige målet. Teamene som tilpasser eksisterende dashboards og varsling-terskler til agent-arbeidsflyter, overtaler ofte seg selv om at de har dekning når de faktisk bare ser på rørene.

Den tredje feilen er å behandle instrumentering som en ettertanke. Bedrifter som tester agenter raskt og går til produksjon uten å tenke gjennom overvåkning, ender opp i dyre remedierings-sykluser, gjenbygger data-samling-arkitektur etter den første betydelige produksjons-feilen. Teamene som skalerer agent-utsteder mest suksessfullt, instrumenterer tidlig, etablerer baselinjer mens trafikken er lav og atferden er forutsigbar, og bygger sin evaluering-rammeverk før de trenger det, i stedet for etter at noe går galt.

Ser fremover, vil infrastruktur-synlighet bli en forutsetning for bedrifts-ai-tilpasning på samme måte som sky-overvåkning ble essensiell for stor-skala sky-migrering?

Parallellen til skyen er ekstremt lik. Det viktigste jeg forteller kundene når de flytter infrastruktur til skyen, er at de ikke løfter og flytter. De deployer en helt ny arkitektur med nye kapasiteter. Alt dette må instrumenteres og overvåkes på måter tidligere verktøy ikke var satt opp for. Bedriftene som hoppet over dette steget, møtte påkjedende feil de ikke kunne diagnostisere, spiralerende kostnader de ikke kunne forklare og nedtider de ikke kunne forhindre. Overvåkning ble grunnlaget for tillit som gjorde sky-skala mulig, og samme mønster spiller nå ut med agens-ai, som beveger seg raskere og med høyere innsats.

Den primære grunnen agenter vil trenge denne type tilsyn uendelig, er at de er ikke-deterministiske av design, deres atferd oppstår på kjøretid og deres effektive kapasitet øker hver gang du kobler til et nytt verktøy. Statisk forhånds-sertifisering kan ikke dekke et system hvis handlingsoverflate endrer seg med hver integrasjon. Agenter vil operere innenfor definerte grenser av tillit, og disse grensene vil utvides over tid ettersom overvåkning, politikk og evaluering-infrastruktur modnes. Grensene selv vil aldri forsvinne, og det er ikke en feil-tilstand. Det er hvordan hver konsekvens-automatisk system i verden allerede fungerer.

Takk for det flotte intervjuet, lesere som ønsker å lære mer, bør besøke Cribl.