Jeff Champagne, Field CTO bij Cribl – Interview Serie

Jeff Champagne, Field CTO bij Cribl, heeft een diepe ervaring in observability, ondernemingsgegevens, productstrategie en technische architectuur. Voordat hij bij Cribl kwam, was hij directeur Product Management bij Databricks en werkte hij meer dan zeven jaar bij Splunk in senior field product-, architectuur- en globale systeemengineeringsrollen. Zijn achtergrond omvat ook systeemarchitectuurleiderschap bij BNY ConvergEx, senior engineeringwerk bij Premier Technology Solutions en vroeg engineeringleiderschap bij Assist-2-Sell, waardoor hij een breed perspectief heeft op hoe ondernemingen operationele gegevens op grote schaal verzamelen, beheren, analyseren en gebruiken.

Cribl is een ondernemingsbedrijf voor telemetrie dat zich richt op het helpen van IT-, beveiligings-, SRE- en DevOps-teams bij het verzamelen, verwerken, routeren, opslaan en analyseren van observability- en beveiligingsgegevens zonder vast te zitten aan één leverancier. Het bedrijf positioneert zichzelf als het “AI-platform voor telemetrie”, met producten zoals Cribl Stream voor real-time telemetrie-verzameling, reductie, verrijking en routering; Cribl Edge voor vendor-neutrale eindpunttelemetrie-verzameling; Cribl Search voor het zoeken van gegevens op de juiste plek; en Cribl Lake voor opslag. De bredere missie is om ondernemingen meer controle, flexibiliteit en efficiëntie te geven naarmate de telemetrie-volumes groeien en AI-gedreven operaties schone, toegankelijke gegevens vereisen.

U heeft gewerkt bij Splunk, Databricks en nu Cribl, waardoor u een zeldzame kijk heeft op ondernemingsgegevens, observability en infrastructuur over meerdere technologie-cycli. Vanuit dat perspectief, wat voelt echt anders aan de observability-uitdaging die wordt gecreëerd door agente AI?

Bij toepassingsobservability hebben we altijd te maken gehad met complexe, vertakte uitvoeringspaden, aanvragen traceren via microservices en logboeken correleren over gedistribueerde systemen. In beveiligingsoperaties hebben we te maken gehad met hoge-volumineuze, uiteenlopende gegevensbronnen om bedreigingen te detecteren over systemen die, hoewel complex, nog steeds op voorspelbare wijze werken. Agente AI vindt geen van deze problemen uit; het laat ze simultaan ontploffen.

Agenten ketenen beslissingen, roepen externe tools op en spawnen sub-agenten dynamisch op manieren die niet zijn voorbeschikt bij het schrijven. De uitvoeringsgrafiek is niet alleen complex, maar kan elke keer wild verschillend zijn, en het volume aan telemetrie dat nodig is om te reconstrueren wat er werkelijk gebeurde, groeit exponentieel met elke sprong. Het verzamelen van alle benodigde telemetrie om agente systemen observable te maken, moet zowel gemakkelijk zijn om te instrumenteren als kosteneffectief om te exploiteren op grote schaal. Anders zullen ondernemingen dezelfde afweging maken die ze altijd hebben gemaakt en zullen ze de zichtbaarheid verminderen om kosten te controleren – precies het verkeerde moment om blind te worden.

Waar zijn de grootste zichtbaarheidslacunes tussen wat een AI-agent wordt gevraagd te doen en wat er werkelijk gebeurt over de onderliggende systemen?

Agenten voltooien workflows die vanaf het oppervlak succesvol lijken, terwijl ze stilzwijgend slechte toolaanroepen maken, parameters hallucineren of afwijken van het oorspronkelijke doel. De gevolgen komen vaak pas uren later aan het licht in een ander systeem.

De disconnect begint meestal bij de interpretatie: een kleine ambiguïteit in het oorspronkelijke instructie wordt anders opgelost, afhankelijk van wat de agent uit het geheugen haalt, welke tools op dat moment beschikbaar zijn, of hoe een eerdere stap in de keten de context heeft gevormd. U moet ook de downstream-systemen instrumenteren waarop de agent afhankelijk is, omdat een agent een perfect gevormde database-aanroep kan maken en nog steeds een verkeerd antwoord kan retourneren als de onderliggende tabel nooit is bijgewerkt omdat een ETL-taak stilzwijgend is mislukt.

De agent deed precies wat hem werd opgedragen; de gegevens die hij vertrouwde, waren gewoon verouderd.

Waarom zijn traditionele observability-tools vaak onvoldoende voor het bewaken van agente AI-systemen?

Ten eerste zijn ze gebouwd rondom rigide, propriëtaire schema’s en voorspelbare gegevensvormen. Agente-sporen voldoen niet aan deze verwachtingen – ze zijn volumineus, sterk variabel in structuur en bevatten gegevenstypen zoals volledige prompt-tekst, model-redeneringsketens en toolaanroep-payloads die legacy-tools niet waren ontworpen om zonder significante transformatie-arbeid te verwerken. Open standaarden zoals OpenTelemetry’s GenAI-semantische conventies zijn in ontwikkeling om dit aan te pakken, maar veel legacy-platforms zijn niet gebouwd om daarvan te profiteren.

Ten tweede breekt de schaal- en kostenequatie snel af. Een enkele agent die productiewerklasten afhandelt, kan meer telemetrie genereren in een uur dan een hele toepassingsstack in een dag produceerde, en de meeste traditionele platforms berekenen kosten op basis van ingevoerde en opgeslagen volumes. Dat creëert een onmogelijke afweging – ofwel instrumenteert u alles en loopt u het risico van uit de hand lopende kosten, ofwel vermindert u de zichtbaarheid in de systemen waar u het meest behoefte aan heeft.

Wanneer een AI-agent faalt, hoe kunnen organisaties bepalen of de root cause het model, de ophaallayer, een API-afhankelijkheid, een machtigingsprobleem of een downstream-infrastructuurprobleem was?

Het isoleren van de root cause bij een agente-fout is een proces van eliminatie over lagen. Het werkt alleen als uw telemetrie alle lagen consistent beslaat. Latentie- en foutsignalen op het model-span wijzen op het LLM-zelf. Ophaal-sporen vertellen u of de geretourneerde context relevant of verouderd was. Toolaanroep-sporen onthullen mislukte API-afhankelijkheden of machtigingsfouten.

Zoals eerder vermeld, hebt u ook telemetrie nodig van de downstream-systemen waarop de agent afhankelijk is, omdat een agent een perfect gevormde aanroep kan maken en nog steeds een verkeerd antwoord kan produceren als de gegevens die hij vertrouwde nooit zijn bijgewerkt. Geen enkel signaal vertelt het hele verhaal, en dat is waarom correleren over al die lagen op één plek het onderscheid maakt tussen teams die agente-fouten snel kunnen debuggen en teams die nog steeds aan het raden zijn.

Welke soorten telemetriegegevens worden het meest belangrijk wanneer ondernemingen proberen om agent-gedrag op grote schaal te begrijpen?

De basis is nog steeds MELT – metrics, events, logs en traces – maar het gewicht verschuift aanzienlijk wanneer u overschakelt naar agente-systemen. Metrics vertellen u dat er iets mis is en logs geven u het ruwe record van wat er is gebeurd, maar geen van beiden kan de redeneringsketen reconstrueren die een agent heeft gevolgd om tot een verkeerd antwoord te komen. Dat is waar sporen het meest kritieke signaal worden.

In een traditioneel gedistribueerd systeem toont een spoor u hoe een aanvraag door services is gegaan. In een agente-systeem toont het u hoe een model een probleem heeft doorlopen, welke tools het heeft aangeroepen, welke context het heeft opgehaald, waar het heeft vertakt en wat het heeft besloten bij elke stap. Zonder dat spoor kijkt u naar een output zonder manier om uit te leggen hoe u daar bent gekomen.

De andere MELT-signalen gaan niet weg; metrics over token-gebruik en latentie zijn belangrijk voor kosten en prestaties, en logs van downstream-systemen blijven essentieel. Maar sporen zijn wat agent-gedrag leesbaar maakt op grote schaal.

Veel AI-discussies focussen nog steeds zwaar op hallucinaties. Onderschatten ondernemingen operationele fouten zoals slechte ophaalacties, gebroken integraties, latentie-sprongen of ontbrekende context?

De meeste hallucinaties in productie zijn geen model-fouten; het zijn operationele fouten in vermomming. Slechte ophaalacties retourneren verouderde of incomplete context, en het model vult de lacune op met iets plausibel klinkend. Een gebroken integratie betekent dat de agent nooit de gegevens kreeg die hij nodig had om correct te redeneren in de eerste plaats. Ontbrekende context van een mislukte ETL-taak lijkt op een hallucinatie, maar is eigenlijk een infrastructuurprobleem.

Wanneer teams het verschil niet kunnen zien, vallen ze terug op wat ze kunnen controleren, wat meestal het model zelf is. Ze itereren op systeemprompts, voegen beveiligingsmaatregelen toe en verfijnen evaluatiekaders, en hoewel deze technieken waardevol zijn, behandelen ze een symptoom in plaats van de oorzaak. In mijn ervaring is de meest rendabele investering bijna altijd gegevenskwaliteit en -versheid in de ophaallayer. Een goed gefundeerde agent met schone, actuele gegevens zal een zwaar prompt-geëngineerde agent die werkt met verouderde of incomplete context altijd overtreffen.

Terwijl agenten meer autonoom worden, wat moeten ondernemingsteams loggen, traceren of monitoren om verantwoordelijkheid te behouden zonder zichzelf te overweldigen met ruis?

De basis is nog steeds MELT, maar verantwoordelijkheid voor agente-systemen vereist het toevoegen van een evaluatiekader aan traditionele telemetrie. Metrics, events en logs onthullen infrastructuur-fouten en gebroken integraties die agent-gedrag kunnen corrumperen voordat het model reageert; sporen geven u de redeneringsketen om te begrijpen waarom het een bepaald antwoord heeft bereikt. Maar geen van beiden vertelt u of het antwoord werkelijk correct was, en dat is waar LLM-as-judge-evaluatie de lacune opvult. Dezelfde AI-mogelijkheden die agenten aandrijven, kunnen worden gebruikt om ze te beoordelen, output te scoren voor nauwkeurigheid, gefundeerdheid en taakvoltooiing op een schaal die geen enkel menselijk review-proces kan evenaren.

Vóór productie fungeert het als een kwaliteitspoort, vangt het regressies op voordat ze bij gebruikers komen. In productie wordt het een continue monitor, bemonstert het live-verkeer en markeert het antwoorden die buiten aanvaardbare drempels vallen. De sleutel tot het vermijden van ruis is het erkennen dat niet elke agent-workflow hetzelfde risico met zich meebrengt, wat betekent dat u overstapt van uniforme monitoring naar iets wat de industrie begint te noemen human-on-the-loop-governance. U definieert gedragsnormen en vertrouwensdrempels van tevoren, laat agenten opereren en behoudt menselijke interventie voor uitzonderingen.

Welke rol kunnen telemetrie-pijpleidingen spelen bij het helpen van beveiligings-, SRE-, data- en AI-teams om vanuit een gedeeld perspectief naar agent-gedrag te kijken?

Beveiligingsteams, SRE’s, data-engineers en AI-teams kijken allemaal naar verschillende sneden van hetzelfde probleem via verschillende tools, en geen van hen heeft het volledige beeld. De reden waarom telemetrie-pijpleidingen een standaardonderdeel zijn geworden van de moderne ondernemingsgegevensarchitectuur, is dat ze precies dit probleem oplossen: een enkele, goed beheerde pijpleiding stroomopwaarts van alle tools zorgt ervoor dat elk team werkt met dezelfde genormaliseerde, verrijkte gegevens zonder maatwerk-agenten en -collectors die voor elk team zijn geïmplementeerd.

Die flexibiliteit is belangrijk op twee niveaus. Het eerste niveau is dat van gegevenstiering. Een goed ontworpen telemetrie-pijpleiding laat u toe om gegevens te koppelen aan de juiste opslag- en analysestrategie, zodat u niet betaalt voor analytics-tariefprijs voor gegevens die u alleen nodig hebt voor langetermijncompliance-opslag. Het tweede niveau is optie op het moment dat de AI-tooling-landschap snel blijft evolueren. Ondernemingen die hun observability-strategie bouwen rondom het ecosysteem van één leverancier, zullen tegen dure migratieprojecten aanlopen elke keer als een beter gereedschap opduikt.

Welke fouten ziet u ondernemingen maken wanneer ze proberen bestaande monitoring-praktijken aan te passen aan agente AI-implementaties?

De meest voorkomende fout die ik zie, is het bereiken naar bestaande premium observability-platforms om agent-sporen te verzamelen zonder eerst de kostenimplicaties te overwegen. Agente-sporen zijn groot, variabel en volumineus op manieren die traditionele toepassings-telemetrie niet zijn, en de meeste premium-platforms berekenen kosten op basis van ingevoerde en opgeslagen volumes. De rekening kan een serieus probleem worden voordat teams zelfs maar beseffen wat er aan de hand is, en de typische reactie is om te verminderen wat ze verzamelen. Het resultaat is het slechtste van twee werelden: hoge kosten en onvolledige zichtbaarheid.

De tweede fout is het toepassen van het verkeerde mentale model op wat monitoring zou moeten beantwoorden. Traditionele infrastructuur-monitoring vraagt “is het systeem up?” en activeert alarms als het niet zo is. Die vraag is noodzakelijk maar verre van voldoende voor agente-systemen, waar de infrastructuur perfect gezond kan zijn terwijl de agent stilzwijgend slechte beslissingen neemt, verouderde gegevens ophaalt of afwijkt van zijn oorspronkelijke doel. Teams die bestaande dashboards en alarmdrempels aanpassen aan agent-workflows, overtuigen zichzelf vaak van dekking terwijl ze eigenlijk alleen de leidingen in de gaten houden.

De derde fout is het behandelen van instrumentatie als een bijzaak. Ondernemingen die agenten snel in productie nemen zonder na te denken over observability, belanden in dure herstelcycli, waarbij ze de gegevensverzameling-architectuur opnieuw moeten opbouwen na de eerste significante productiefout. De teams die agent-implementaties het meest succesvol schalen, instrumenteren vroeg, stellen baselines in terwijl het verkeer laag is en het gedrag voorspelbaar is, en bouwen hun evaluatiekader op voordat ze het nodig hebben, in plaats van erna.

Kijkend naar de toekomst, zal infrastructuurzichtbaarheid een vereiste worden voor ondernemings-AI-adoptie op dezelfde manier als cloud-observability essentieel werd voor grote-schaalcloud-migratie?

De parallel met de cloud is extreem vergelijkbaar. Het belangrijkste wat ik klanten vertel wanneer ze infrastructuur naar de cloud verplaatsen, is dat ze niet zomaar liften en shiften. Ze implementeren een hele nieuwe architectuur met nieuwe mogelijkheden. Alles moet worden geïnstrumenteerd en gemonitord op manieren waarop eerdere tools waarschijnlijk niet waren ingesteld. De ondernemingen die die stap oversloegen, liepen tegen cascade-fouten aan die ze niet konden diagnosticeren, tegen kosten die ze niet konden verklaren en tegen uitval die ze niet konden voorkomen. Observability werd de basis van vertrouwen die cloud-schaal mogelijk maakte, en hetzelfde patroon speelt zich nu af met agente AI, sneller en met hogere inzet.

De primaire reden waarom agenten deze soort toezicht nodig zullen hebben, is dat ze non-deterministisch zijn van ontwerp, hun gedrag ontstaat tijdens runtime en hun effectieve capaciteit groeit elke keer dat u een nieuwe tool verbindt. Statische pre-deployment-certificering kan een systeem niet dekken waarvan het actieoppervlak verandert met elke integratie. Agenten zullen opereren binnen gedefinieerde grenzen van vertrouwen, en die grenzen zullen zich uitbreiden over tijd naarmate observability-, beleids- en evaluatie-infrastructuur rijpt. De grenzen zelf zullen nooit verdwijnen, en dat is geen falenstoestand. Het is hoe elk gevolgrijk autonoom systeem in de wereld al werkt.

Bedankt voor het geweldige interview, lezers die meer willen leren, kunnen Cribl bezoeken.