Jeff Champagne, Field CTO hos Cribl – Interviewserie

Jeff Champagne, Field CTO hos Cribl, har dyb erfaring på tværs af observability, enterprise data, produktstrategi og teknisk arkitektur. Før han kom til Cribl, var han direktør for produktledelse hos Databricks og tilbragte mere end syv år hos Splunk i senior feltprodukt-, arkitektur- og globale systemingeniørroller. Hans baggrund omfatter også ledelse af systemarkitektur hos BNY ConvergEx, senior ingeniørarbejde hos Premier Technology Solutions og tidlig ingeniørledelse hos Assist-2-Sell, hvilket giver ham en bred perspektiv på, hvordan virksomheder indsamler, administrerer, analyserer og handler på operationelle data i stor målestok.

Cribl er et enterprise-telemetri-virksomhed, der fokuserer på at hjælpe IT-, sikkerheds-, SRE- og DevOps-hold med at indsamle, behandle, lede, gemme og analysere observability- og sikkerhedsdata uden at være låst til en enkelt leverandør. Virksomheden positionerer sig som “AI-platformen for telemetri” med produkter som Cribl Stream til realtids-telemetriindsamling, reduktion, berigelse og routing; Cribl Edge til vendor-neutral endpoint-telemetriindsamling; Cribl Search til søgning af data på stedet; og Cribl Lake til lagring. Dens bredere mission er at give virksomheder mere kontrol, fleksibilitet og effektivitet, da telemetrimængder vokser og AI-drevne operationer kræver renere, mere tilgængelige data.

DU har arbejdet på tværs af Splunk, Databricks og nu Cribl, hvilket giver dig en sjælden indsigt i enterprise-data, observability og infrastruktur over flere teknologicykler. Fra det perspektiv, hvad føles virkelig anderledes om observability-udfordringen skabt af agentic AI?

I application-observability har vi altid haft at gøre med komplekse, forgrenede eksekveringsveje, sporing af anmodninger gennem mikrotjenester og korrelation af logfiler på tværs af distribuerede systemer. I sikkerhedsoperationer har vi tacklet højvolumen, forskellige datakilder for at opdage trusler på tværs af systemer, der, selvom de er komplekse, stadig opfører sig på en overordnet måde. Agentic AI genopfinder ikke disse problemer; det eksploderer dem samtidigt.

Agenter kæder beslutninger, kalder eksterne værktøjer og genererer underagenter dynamisk på måder, der ikke er forudbestemt på skrive tid. Eksekveringsgrafikken er ikke bare kompleks, men kan være vildt forskellig hver gang, og mængden af telemetri, der kræves for at genskabe, hvad der faktisk skete, vokser eksponentielt med hver hop. Indsamling af alle telemetri-data, der er nødvendige for at gøre agentic systemer observerbare, må være både let at instrumentere og omkostnings-effektivt at operere i stor målestok. Ellers vil virksomhederne gøre den samme kompromis, de altid har gjort, og reducere synligheden for at kontrollere omkostningerne – præcis det forkerte tidspunkt at blive blind.

Når virksomheder integrerer autonome agenter i arbejdsgange, hvor er de største synligheds-gabler mellem, hvad en AI-agent bliver bedt om at gøre, og hvad der faktisk sker på tværs af de underliggende systemer?

Agenter fuldfører arbejdsgange, der ser ud til at være succesfulde på overfladen, mens de stille og roligt laver dårlige værktøj-kald, hallucinerer parametre eller drifter fra den oprindelige mål. Konsekvenserne dukker ofte op timer senere i et andet system.

Afbruddet begynder normalt ved fortolkning: en lille tvivl i den oprindelige instruks kan løses forskelligt afhængigt af, hvad agenten henter fra hukommelsen, hvilke værktøjer der er tilgængelige på det tidspunkt, eller hvordan en tidligere trin i kæden formede dens kontekst. Du skal også instrumentere de underliggende systemer, som agenten afhænger af, fordi en agent kan lave et perfekt dannet database-kald og stadig returnere et forkert svar, hvis den underliggende tabel aldrig blev opdateret, fordi en ETL-job aldrig blev udført.

Agenten gjorde præcis, hvad den blev bedt om; data, den stolede på, var bare forældet.

Hvorfor er traditionelle observability-værktøjer ofte utilstrækkelige til overvågning af agentic AI-systemer?

Først og fremmest blev de bygget op omkring stive, proprietære skemaer og forudsigelige dataformer. Agentic spor konformerer sig ikke til disse forventninger – de er voluminøse, højst variable i struktur og indeholder data typer som fuld prompt-tekst, model-ræsoneringskæder og værktøj-kald-nyttilægg, som legacy-værktøjer ikke var designet til at indtage uden betydelig transformationsarbejde. Åbne standarder som OpenTelemetris GenAI-semantiske konventioner er under udvikling for at løse dette problem, men mange legacy-platforme blev ikke bygget til at udnytte dem.

For det andet bryder skala- og omkostnings-ligningen sammen hurtigt. En enkelt agent, der håndterer produktions-arbejdsgange, kan generere mere telemetri på en time end en hel applikationsstak producerede på en dag, og de fleste traditionelle platforme fakturerer efter volumen indtaget og gemt. Det skaber en umulig kompromis – enten instrumenterer du alt og står over for løbende omkostninger, eller reducerer du synligheden i de systemer, hvor du har mest brug for det.

Når en AI-agent fejler, hvordan kan organisationer afgøre, om rodårsagen var modellen, den indhentningslag, en API-afhængighed, et tilladelsesproblem eller et underliggende infrastrukturproblem?

At isolere rodårsagen i en agentic fejl er en proces for udelukkelse på tværs af lag. Det fungerer kun, hvis din telemetri dækker alle lag konsekvent. Latens- og fejl-signaler på model-lagene peger på LLM selv. Indhentnings-lag fortæller, om konteksten, der returneredes, var relevant eller forældet. Værktøj-kald-lag afslører fejlede API-afhængigheder eller tilladelsesfejl.

Som nævnt tidligere har du også brug for telemetri fra de underliggende systemer, som agenten afhænger af, fordi en agent kan lave et perfekt dannet kald og stadig producere et forkert svar, hvis data, den stolede på, aldrig blev opdateret. Ingen enkelt signal fortæller hele historien, hvilket er grunden til, at korrelation på tværs af alle disse lag på et sted er, hvad der adskiller hold, der kan fejlfinde agentic fejl hurtigt, fra dem, der stadig gætter.

Hvilke typer telemetri-data bliver mest vigtige, når virksomheder forsøger at forstå agent-adfærd i stor målestok?

Grundlaget er stadig MELT – målinger, begivenheder, logfiler og spor – men vægten skifter betydeligt, når du går ind i agentic systemer. Målinger fortæller dig, om noget er galt, og logfiler giver dig den rå optegnelse over, hvad der skete, men ingen af dem kan genskabe den kæde af ræsonnement, en agent fulgte for at nå et forkert svar. Det er, hvor spor bliver det mest kritiske signal.

I et traditionelt distribueret system viser et spor, hvordan en anmodning bevægede sig gennem tjenester. I et agentic system viser det, hvordan en model ræsonnerede gennem et problem, hvilke værktøjer den kaldte, hvilken kontekst den hentede, hvor den grene og hvad den besluttede på hvert trin. Uden det spor er du ved at se på en output uden nogen måde at forklare, hvordan du kom dertil.

De andre MELT-signaler forsvinder ikke; målinger på token-brug og latens er vigtige for omkostninger og ydeevne, og logfiler fra underliggende systemer forbliver essentielle. Men spor er, hvad der gør agent-adfærd læselig i stor målestok.

Mange AI-diskussioner fokuserer stadig tungt på hallucinationer. Underestimerer virksomheder operationelle fejl som dårlige indhentninger, ødelagte integrationer, latens-spring eller manglende kontekst?

De fleste hallucinationer i produktion er ikke model-fejl; de er operationelle fejl i forklædning. Dårlige indhentninger returnerer forældede eller ufuldstændige kontekst, og modellen udfylder hullerne med noget, der lyder plausibelt. En ødelagt integration betyder, at agenten aldrig fik de data, den havde brug for for at ræsonnere korrekt fra starten. Manglende kontekst fra en fejlet ETL-job ser ud som en hallucination, men er i virkeligheden et infrastrukturproblem.

Når hold ikke kan se forskellen, falder de tilbage til, hvad de kan kontrollere, som normalt er modellen selv. De itererer på system-prompts, tilføjer vagtler og forfiner evalueringsskemaer, og selvom disse teknikker har reel værdi, behandler de et symptom i stedet for årsagen. I min erfaring er den højeste gevinst altid datakvalitet og friskhed i indhentningslaget. En velbegrundet agent med ren, aktuel data vil overgå en tungt prompt-ingeniøreret en, der arbejder fra forældede eller ufuldstændige kontekst.

Når agenter bliver mere autonome, hvad skal virksomhedshold logge, spore eller overvåge for at fastholde ansvarlighed uden at overvælde sig selv med støj?

Grundlaget er stadig MELT, men ansvarlighed for agentic systemer kræver lagning af en evalueringsramme oven på traditionel telemetri. Målinger, begivenheder og logfiler afslører infrastrukturfejl og ødelagte integrationer, der kan korrumperere agent-adfærd, før modellen responderer; spor giver dig ræsoneringskæden for at forstå, hvorfor den nåede et bestemt svar. Men ingen af dem fortæller, om svaret faktisk var korrekt, og det er, hvor LLM- som-dommer-evaluering fylder hullet. De samme AI-kapaciteter, der driver agenter, kan bruges til at evaluere dem, og score outputs for nøjagtighed, grundlæggelse og opgave-gennemførelse på en skala, som ingen menneskelig gennemgangsproces kan matche.

Præ-produktion fungerer det som en kvalitetsport, der fanger regressioner, før de når brugere. I produktion bliver det en kontinuerlig overvåger, der sampler live-trafik og flagger svar, der falder uden for acceptable grænser. Nøglen til at undgå støj er at erkende, at ikke alle agent-arbejdsgange medfører den samme risiko, hvilket betyder, at man bevæger sig væk fra uniform overvågning mod noget, som industrien er begyndt at kalde human-on-the-loop-styring. Du definerer adfærds-mæssige grundlinjer og tillidsgrænser på forhånd, lader agenter operere dem, og reserverer menneskelig intervention for undtagelser.

Hvad kan telemetri-rørledninger spille for en rolle i at hjælpe sikkerheds-, SRE-, data- og AI-hold med at arbejde fra en fælles visning af agent-adfærd?

Sikkerheds-hold, SRE’er, data-ingeniører og AI-hold kigger alle på forskellige skiver af det samme problem gennem forskellige værktøjer, og ingen af dem har det fulde billede på egen hånd. Grunden til, at telemetri-rørledninger er blevet en standarddel af moderne enterprise-data-arkitektur, er, at de løser præcis dette problem: en enkelt, godt styret rørledning oven for alle dine værktøjer sikrer, at hvert hold arbejder med de samme normaliserede, berigede data uden specialbyggede agenter og samler, der er installeret til hvert hold.

Denne fleksibilitet er vigtig på to niveauer. Først og fremmest er det data-niveauer. En godt designed telemetri-rørledning låser data til den rette lagrings- og analysestrategi, så du ikke betaler analytics-niveau-priser for data, du kun har brug for til langsigtede overholdelses-opbevaring. Det andet er valgfrihed, da AI-værktøjslandskabet udvikler sig hurtigt. Virksomheder, der bygger deres observability-strategi omkring en enkelt leverandørs økosystem, vil stå over for dyre migrationsprojekter hver gang, en bedre værktøj dukker op.

Hvilke fejl ser du, at virksomheder begår, når de forsøger at tilpasse eksisterende overvågningspraksis til agentic AI-udrulninger?

Den mest almindelige fejl, jeg ser, er, at man griber efter eksisterende premium-observability-platforme til at indsamle agent-spor uden at tænke igennem omkostnings-implikationerne først. Agentic spor er store, variable og voluminøse på måder, som traditionel applikations-telemetri ikke er, og de fleste premium-platforme fakturerer efter indtag og lagring. Regningen kan blive et alvorligt problem, før holdene overhovedet når at opdage, hvad der sker, og den typiske reaktion er at reducere, hvad de indsamler. Resultatet er det værste af begge verdener: høje omkostninger og ufuldstændig synlighed.

Den anden fejl er at anvende den forkerte mentale model til, hvad overvågning skal svare på. Traditionel infrastruktur-overvågning spørger “er systemet oppe?” og udløser alarmsignaler, når det ikke er. Det spørgsmål er nødvendigt, men langt fra tilstrækkeligt for agentic systemer, hvor infrastrukturen kan være helt sund, mens agenten stille og roligt tager dårlige beslutninger, henter forældede data eller drifter fra sin oprindelige mål. Hold, der tilpasser eksisterende dashboards og alarmgrænser til agent-arbejdsgange, overbeviser ofte sig selv om, at de har dækningsområde, når de i virkeligheden kun ser på røret.

Den tredje fejl er at behandle instrumentation som en eftertanke. Virksomheder, der afprøver agenter hurtigt og flytter til produktion uden at tænke igennem observability, ender i dyre remedierings-cykler, hvor de genopbygger dataindsamling-arkitektur efter den første betydelige produktionsfejl. De hold, der skalere agent-udrulninger mest succesfuldt, instrumenterer tidligt, etablerer grundlinjer, mens trafikken er lav og adfærden er forudsigelig, og bygger deres evalueringsramme, før de har brug for den, snarere end efter noget går galt.

Settende fremad, vil infrastruktur-synlighed blive en forudsætning for virksomheds-AI-adopteringsmulighed på samme måde, som cloud-observability blev essentiel for storstilede cloud-migrationer?

Parallellen til cloud er ekstremt lignende. Det vigtigste, jeg fortæller kunder, når de flytter infrastruktur til cloud, er, at de ikke løfter og flytter. De implementerer en helt ny arkitektur med nye kapaciteter. Alt dette skal instrumenteres og overvåges på måder, som tidligere værktøjer sandsynligvis ikke var indstillet til. Observability blev grundlaget for tillid, der gjorde cloud-skala mulig, og samme mønster udspiller sig nu med agentic AI, der flytter hurtigere og med højere indsats.

Den primære grund til, at agenter vil have brug for denne type overvågning uafbrudt, er, at de er ikke-deterministiske af design, deres adfærd opstår på køre-tid, og deres effektive kapacitet vokser hver gang, du tilslutter et nyt værktøj. Statisk forud-for-udrulning-godkendelse kan ikke dække et system, hvis handlings-overflade ændrer sig med hver integration. Agenter vil operere inden for definerede grænser for tillid, og disse grænser vil udvide sig over tid, efterhånden som observability-, politik- og evaluerings-infrastruktur modnes. Grænserne selv vil aldrig forsvinde, og det er ikke en fejltilstand. Det er, hvordan hver konsekvensfuld autonom system i verden allerede fungerer.

Tak for det store interview, læsere, der ønsker at lære mere, skal besøge Cribl.