Bij Anthropic loopt 95 procent van de business analytics vragen via Claude, met ongeveer 95 procent accuraatheid. Zonder skills kwam diezelfde opstelling niet boven de 21 procent uit. Agentic data analytics werkt dus niet omdat het model goed overweg kan met SQL. Het werkt omdat de context eromheen klopt.

Dat onderscheid bepaalt of jouw datateam waarde haalt uit een analytics agent. Een agent op je warehouse loslaten geeft snel het gevoel van precisie. De antwoorden komen terug, netjes opgemaakt en met vertrouwen in visualisaties gegoten. Of ze kloppen, weet niemand.

Waarom analytics agents lastiger zijn dan coding agents

Bij code is de oplossingsruimte open. Creativiteit wordt beloond en tests en documentatie fungeren als guardrails. De code slaagt of faalt.

Analytics heeft die luxe niet. Er is meestal één correct antwoord, uit één correcte bron. De complexiteit zit niet in de query maar in de dubbelzinnigheid van het datamodel. Kun je de vraag van een gebruiker koppelen aan de juiste entiteiten in je datamodel, dan wordt de rest een fluitje van een cent.

De eindgebruiker van de data verandert. Vroeger interpreteerde een data scientist het resultaat en zag die meteen of een getal sense maakte. Nu stelt iemand zonder kennis van het onderliggende model de vraag via een agent. Die persoon kan de correctheid niet valideren.

De drie oorzaken van fouten

Anthropic identificeert drie oorzaken die het overgrote deel van de foute antwoorden verklaren.

  • Concept versus entiteit ambiguïteit. Met honderden beschikbare velden kiest de agent niet altijd betrouwbaar de juiste. Vraag om het aantal actieve gebruikers en de agent moet eerst zelf bepalen wat actief betekent, of frauduleuze accounts meetellen. Die regels staan nergens opgeschreven, dus gokt hij.
  • Verouderde context. Bronnen, definities en schema’s veranderen continu. Je documentatie en de kennis van de agent verwateren en leveren verkeerde antwoorden.
  • Retrieval failure. De juiste tabel staat er, netjes gedocumenteerd, maar de agent vindt hem niet.

Elke laag van de agentic analytics stack pakt minstens één van deze drie oorzaken aan.

Laag één, sterke data foundation

Dimensioneel modelleren, shift left testing, freshness checks op kritieke pipelines. Die praktijken blijven nodig. Wat verandert is het doel. Je datamodel moet leesbaar zijn voor een agent.

De grootste winst zit in canonieke datasets, datasets die consistent en duidelijk heel de logica van het datamodel bevatten . Als omzet maar in één dataset zit in plaats van veertig, verdwijnt het probleem voordat de agent hoeft te zoeken. Minder logische modellen, duidelijk eigenaarschap en agressief schrappen van bijna duplicaten. Fysieke rollups en caches blijven nuttig om kosten te verlagen en de performance te verhogen. Maar deze worden automatisch gecreëerd vanuit de canonieke modellen.

Dit werkt alleen als er streng op wordt toegekeken. Bij Anthropic wordt de canonieke laag afgedwongen via tooling die de agent structureel eerst daar naartoe stuurt. Alle datacode zit in één repository: modellen, semantische laag, referentiedocumentatie. Zorgt een wijziging in het model voor een defect in een dashboard, dan vlagt CI dat.

Laag twee, sources of truth

De sources of truth zijn referentiekaders waar de agents op navigeren.

De semantische laag is de belangrijkste. Gaat een vraag over een goed gedefinieerde metric, dan roept de agent een functie aan en krijgt hij deze metric consistent terug. Je zou een shortcut kunnen nemen en een LLM automatisch metric definities te laten genereren uit ruwe tabellen en query logs. Meestal mislukt dit. De definities zien er ok uit maar ze zijn dubbelzinnig. Documentatie schrijven met Claude werkt prima, maar de definities scherp stellen moet je zelf doen.

Daaronder komen lineage en de transformatiegraaf, waarmee de agent kan redeneren over welke upstream modellen een concept voeden en welke zijn afgevoerd. Daarna volgt het query corpus. Intuïtief zou historische SQL uit dashboards en notebooks goud waard zijn. In de praktijk verbeterde ruwe toegang tot duizenden eerdere queries de accuraatheid met minder dan één punt. Wel werkt het destilleren van dat corpus tot gestructureerde referentiedocumenten per domein.

De laag die de meeste teams overslaan is businesscontext. Een agent die je bedrijf niet begrijpt, beantwoordt wat er gevraagd is maar niet wat er bedoeld wordt. Hij weet niet dat de Q2 launch naar een specifiek product verwijst of dat twee teams dezelfde term anders definiëren.

Laag drie, skills bevatten procedurele kennis

Sources of truth vertellen wat een metric betekent. Een skill vertelt welke bronnen je in welke volgorde raadpleegt en hoe een afgeronde analyse eruitziet. In Claude Code is dat een map met markdown die de agent op aanvraag leest.

Anthropic werkt met paarsgewijze skills. Een knowledge skill fungeert als dunne router die zegt dat de semantische laag voorgaat, en bij gebrek aan dekking wijst naar enkele tientallen referentiebestanden voor dat domein. Dat is het antwoord op retrieval failure. In plaats van zoeken in een warehouse met miljoenen velden versmalt de agent de ruimte tot een handvol gecureerde bestanden voordat er één query geschreven wordt. Daarnaast codeert een runbook skill het proces van een senior analist, inclusief herbruikbare patronen voor retentiecurves, funnelanalyse en rate decomposition.

Onderhoud is geen bijzaak. De offline accuraatheid zakte in één maand van ongeveer 95 naar 65 procent voordat het als engineeringprobleem werd behandeld. De oplossing was colocatie. De skill markdown staat in dezelfde repo als de transformatiemodellen en een code review hook signaleert elke wijziging aan een reporting model die geen skillbestand raakt. Inmiddels bevat ongeveer 90 procent van de datamodel PR’s een skillwijziging in dezelfde diff.

Laag vier, validatie en evals

Veel teams bouwen een uitgebreide agentomgeving zonder enig proces om de accuraatheid te kennen. Offline evals zijn simpele vraag en antwoord paren. Ze vertellen je niet hoe je productieagent presteert, maar ze laten wel zien of er gapende gaten zitten.

Een paar principes helpen. Anker de ground truth op een snapshotdatum of laat de beoordelaar de query beoordelen in plaats van het getal, anders verouderen je evals zodra de cijfers bewegen. Sla resultaten op als telemetrie in een warehousetabel met skillversie, git SHA, model ID en pass of fail per assertie, zodat de vraag of een wijziging hielp een query wordt. En gate je lancering per domein, met een drempel die gehaald moet worden voordat stakeholders erop mogen vertrouwen.

Structurele keuzes worden getest met ablaties waarbij precies één component varieert. Het nuttigste resultaat was negatief. De agent kreeg directe grep toegang tot alle dashboard SQL, transformaties en analistennotebooks. Transcripten bevestigden dat hij die ook las. De accuraatheid bewoog minder dan een punt. In ongeveer 80 procent van de foute antwoorden stond het juiste antwoord gewoon in het corpus. De informatie was er, de agent zag het en gebruikte het niet. Het knelpunt was structuur, niet toegang.

Wat je online nog kunt afvangen

Een adversarial review skill die alle aannames onder een conceptantwoord aanvalt leverde 6 procent extra accuraatheid op, tegen 32 procent meer tokens en 72 procent hogere latency. Of die ruil de moeite waard is, verschilt per organisatie.

Goedkoper en verrassend effectief is de provenance footer. Elk antwoord vermeldt uit welke brontier het komt, hoe vers de data is en wie het model beheert. Het maakt het antwoord niet correcter, maar het helpt de lezer inschatten hoeveel vertrouwen gepast is. Een melding dat het om een ruwe tabel met onbekende freshness gaat, is een signaal om te verifiëren voordat je het doorstuurt.

Daarnaast draait er passieve monitoring op twee signalen. Welk aandeel van de queries resolvet via de semantische laag en welk aandeel van de antwoorden krijgt correctietaal terug van stakeholders, in de trant van verkeerde tabel of je mist de fraudefilter. Een geplande agent scant die kanalen, stelt een regel fix voor in het relevante referentiedocument en opent een pull request voor de domeineigenaar. De fixroute is bewust saai gehouden, want alleen dan gebeurt het ook echt.

Hoe dit uitpakt in een gewone organisatie

Consultants van Rittman Analytics beschreven de toepassing op een middelgrote moderetailer met een warehouse dat jarenlang tabel per tabel groeide. Claude gekoppeld aan hun BI laag gaf ongeveer een derde van de tijd een bruikbaar antwoord. Niet omdat het model niet kon rekenen, maar omdat het datamodel te veel manieren bood om ernaast te zitten.

De audit bracht het bekende beeld naar boven. Een attributiemodel dat verwees naar een tabel die acht maanden eerder hernoemd was en daardoor stilletjes nul rijen teruggaf. Twee ordertabellen die returns op een ander niveau verrekenden, dus verschillende omzet per categorie afhankelijk van welke je raakte. Vier definities van omzet zonder vastgelegde autoriteit. Na governancesessies met de domeineigenaren en verankerde evals klom de accuraatheid naar de hoge tachtig procent per domein.

De les daaruit is scherp. Het mechanische werk gaat snel en wordt sneller. De tijd zit in de gesprekken over definities, en precies daar komt de accuraatheid vandaan. Een slimmer model koopt je daar niet uit.

Begin klein en houd rekening met wat je niet ziet

Start je vanaf nul, dan pakken een handvol canonieke datasets, enkele tientallen offline evals en een dunne knowledge skill het grootste deel van de winst. De rest bouw je erbij zodra dat fundament staat.

Weeg daarbij mee hoe technisch je publiek is, hoeveel je wilt betalen voor extra accuraatheid en hoe je omgaat met toegangsrechten. Meer context maakt een agent doorgaans beter, maar brede datatoegang botst met de meeste governanceposities. Die afweging bepaalt of je één agent bouwt of meerdere met een afgebakende scope.

Eén faalmodus blijft ondertussen grotendeels ongedekt. Het stille verkeerde antwoord dat plausibel oogt en zonder tegenspraak wordt gebruikt. Provenance footers, menselijke aftekening op alles wat richting directie gaat en dagelijkse sanity checks op de belangrijkste KPI’s dempen het risico, maar lossen het niet op. Dat is geen reden om te wachten. Het is wel de reden om te weten welke vragen je nooit zonder tweede paar ogen laat vertrekken.