Agentic analytics

Wat is agentic analytics?

Bij agentic analytics voert een agent het volledige onderzoek uit in plaats van één vraag te beantwoorden. Hij beslist zelf wat hij eerst bekijkt, laat een reeks queries lopen, controleert zijn resultaat langs een tweede kant, en komt terug met een bevinding plus de queries die hij gebruikt heeft.

Het verschil met gewoon een vraag stellen zie je sneller dan je het uitlegt. Vraag aan een chatassistent "wat was onze marge vorige maand" en je krijgt één cijfer uit één query. Dat is conversational analytics, en dat heeft zijn eigen lemma. Vraag aan een agent "onze marge is gezakt, zoek uit waarom" en geen enkele query beantwoordt dat. Iemand moet beslissen om de marge eerst per productgroep te splitsen, dan per klant binnen de groep die bewogen is, en dan te testen of de mix alleen het gat verklaart. Dat beslissen is het werk, en het is wat de agent overneemt: de wandeling die een analist met een draaitabel maakt op de eerste dinsdag van de maand. Van binnenuit bekeken zijn dat vijf stappen.

1. Hij hakt de vraag in stukken.
   Bevestig eerst dat de daling echt is, zoek waar ze zit, zoek wat er binnen dat stuk veranderd is, en test of de voor de hand liggende verklaring het gat dekt.

2. Hij bevraagt de data meerdere keren.
   De eerste query versmalt, de tweede landt daarbinnen, de derde gaat terug naar een andere tabel. Eén bedrijfsvraag wordt vlot een dozijn queries of meer, en in de documentatie van Snowflake staat dat een Deep Research-onderzoek tot tien minuten kan duren.

3. Hij controleert zijn eigen antwoord.
   De versie waar je iets aan hebt, herrekent het cijfer op een tweede manier. Neem de marge van augustus, leg er de klantenmix van juli op, en kijk hoeveel van het gat verdwijnt. Blijft het grootste deel staan, dan zit de oorzaak in de prijs.

4. Hij merkt iets op waar je niet naar gevraagd hebt.
   Dat rolt uit het bevragen zelf, niet uit je prompt. Terwijl hij orderlijnen per leverancier groepeert, ziet hij zestig lijnen zonder aankoopprijs. Niemand had dat gevraagd, en het is vaak de nuttigste zin in het rapport.

5. Hij rapporteert, of hij handelt.
   De meeste analytics-agents die vandaag beschikbaar zijn, stoppen bij rapporteren. Fabric data agents genereren enkel leesqueries en zetten nooit een schrijfproces in gang. Iets doen met een bevinding is een apart ontwerp, zie het lemma over de operations agent.

De winst zit in stap één en stap drie, de twee die een drukke mens overslaat. De prijs is dat een agent die zelf zijn volgende query kiest aan veel meer van je data komt dan een chatvenster ooit doet.

De vier dingen die er eerst moeten zijn

Dit is het stuk dat verkocht wordt als een functie en dat in de praktijk het project blijkt te zijn.

Een beheerd model dat zegt wat omzet betekent. De agent kan niet kiezen tussen twee geloofwaardige definities van marge, want in de data zien ze er allebei correct uit. Snowflake schrijft het zonder omwegen in de documentatie van Cortex Analyst: algemene AI worstelt met text-to-SQL wanneer ze alleen een databaseschema krijgt, omdat een schema geen bedrijfsdefinities meedraagt en niet zegt hoe een metriek behandeld hoort te worden. Een semantisch model met een measure Marge die je boekhouding goedgekeurd heeft, haalt die keuze weg. Zonder zo'n model kiest de agent per onderzoek een definitie, en niets op het scherm zegt welke.

Rechten die de vrager volgen. Dat krijgt hieronder een eigen stuk, want daar loopt het bij de meeste eerste ontwerpen mis.

Een manier om een antwoord na te kijken. Niet het gevoel dat het er ongeveer juist uitzag. Schrijf twintig vragen op waarvan je het antwoord al kent, in de woorden die je collega's echt gebruiken, en laat ze opnieuw lopen na elke aanpassing aan het model, aan de instructies of aan de modelversie. Scoort de agent slechter dan een nieuwe medewerker, dan is hij niet klaar, hoe mooi de demo ook was.

Een register van wat hij uitgevoerd heeft. Elke query, in volgorde, met de measure en de filters, ergens bewaard waar iemand het twee weken later nog kan lezen. Microsoft documenteert dat de prompts en antwoorden van een Fabric data agent opgepikt kunnen worden door Microsoft Purview auditing en eDiscovery, al zitten die Purview-controles op moment van schrijven nog in preview. Snowflake wijst naar rolgebaseerde toegang en audit trails om de autonome acties van een agent binnen de grenzen te houden die een beheerder gezet heeft. Kan je tool je de queries achter een conclusie niet tonen, dan is die conclusie een mening met een grafiek erbij.

Onder wiens naam de agent zijn query uitvoert

De makkelijke manier om dit te bouwen is een service account met leesrechten op het warehouse. Dat werkt de eerste dag, en het is fout.

Een agent die onder een service account draait, ziet elke rij. Vraag hem de marge per klant en hij geeft een vertegenwoordiger de klanten die hij niet mag zien. Vraag hem de loonkost per afdeling en hij antwoordt daar ook op. Dit is dezelfde val die het lemma over RAG beschrijft voor documentassistenten, en het antwoord is hetzelfde: toegang op naam van de gebruiker is geen extra beveiliging die je er later bij zet, het is het ontwerp.

De beheerde producten pakken het op dezelfde manier aan, en het loont om na te gaan of die van jou dat ook doet. Een Fabric data agent gebruikt de credentials van wie de vraag stelt, dus row-level en column-level security blijven gelden. De agent van Snowflake erft de row-access policies en de column-level security die aan de rol van de gebruiker hangen. Stel je leverancier één vraag en aanvaard geen omweg: als de agent een query uitvoert, wiens rechten gelden dan? Is het antwoord een service account, dan bouw je een datalek met een chatvenster ervoor.

Er hangt een tweede helft aan vast. Het register moet bijhouden wie gevraagd heeft, en niet alleen wat er gelopen heeft. Anders zie je wel dat iemand de loontabel opgevraagd heeft, maar niet wie.

Een margedaling, stap voor stap uitgewerkt

Een technische groothandel in Limburg, veertig mensen, ongeveer 1,2 miljoen euro omzet per maand. Augustus sluit af op 28,9 procent brutomarge tegenover een gemiddelde van 31,2 over twaalf maanden. De zaakvoerder typt één zin: onze marge is gezakt in augustus, zoek uit waarom.

1. Bevestig het. Marge per maand over vierentwintig maanden. Augustus is de laagste van de laatste twaalf en juli was normaal, dus dit is één maand en geen trend.

2. Zoek waar het zit. Marge per productgroep. Fittingen, goed voor zo'n 360k omzet in augustus, kwam binnen op 26 procent tegenover gewoonlijk 34. Acht punten op 360k is grofweg 29k marge die ontbreekt, en dat is het volledige gat van het bedrijf.

3. Kijk binnen de groep. Marge per klant binnen fittingen. Eén klant nam in augustus voor 110k af tegenover normaal 20k, aan zijn contractmarge van 11 procent.

4. Controleer de verklaring. De agent herrekent de marge op fittingen met die klant terug op zijn gewone 20k en komt uit op 31 procent. De klant verklaart dus vijf van de acht punten. De andere drie staan nog open: de rest van de groep kwam binnen op net geen 33 procent in plaats van 34, en dat wijst op prijs en niet op mix.

5. Meld wat niemand gevraagd had. Terwijl hij per leverancier groepeert, vindt de agent 62 orderlijnen, samen zo'n 18k omzet, met aankoopprijs nul, allemaal van dezelfde leverancier. Die lijnen staan op 100 procent marge. Het prijsbestand van die leverancier is op 4 augustus niet binnengeraakt. Zet er een normale kostprijs op en de marge van augustus ligt een vol punt lager dan het rapport zegt, en fittingen zit dichter bij 22 procent dan bij 26.

En nu het stuk dat onopgemerkt zou gebleven zijn. In stap twee greep de agent naar een measure die Brutomarge heet. Stel dat die measure op standaardkostprijs draait terwijl je boekhouding rapporteert op de volledige kostprijs met vracht en douane erin. Alle cijfers hierboven blijven onderling kloppen. De groep is nog altijd bewogen, de klant verklaart nog altijd vijf punten, het ontbrekende prijsbestand is nog altijd echt. Alleen ligt het niveau overal anderhalf punt verkeerd, en niets in de uitvoer zegt dat, want de agent heeft nooit gekozen tussen twee definities. Hij nam de enige die hij vond. Dat is het volledige argument om de definitie in je model vast te leggen voor je er een agent op zet.

Waar de agent goed in is, en waar hij de mist ingaat

Hij is goed in het werk dat een mens overslaat bij gebrek aan tijd. Niemand rekent op een dinsdagnamiddag met de hand het tegenscenario van stap vier uit; de agent doet het omdat het hem niets kost. Hij maakt van twintig afwijkingen de drie die je tijd waard zijn, met bij elk een reden. En hij schrijft de query zelf, waar je vroeger moest wachten op die ene collega die het warehouse kent.

Wat hij niet kan is één hardnekkig ding: hij weet niet welke van twee geloofwaardige definities jouw bedrijf gebruikt. Een beter model lost dat niet op. Het is een beslissing die niemand opgeschreven heeft, en enkel een mens kan ze nemen. Daarom legt de semantische laag het plafond vast van hoever dit bij jou geraakt.

Daar bestaat een meting bij. Het onderzoekslab XLANG bouwde een testset met de naam Spider 2.0 uit echte bedrijfsdatawarehouses, 632 opgaven op databanken met meer dan duizend kolommen. In de eerste ronde loste het sterkste algemene redeneermodel ongeveer 17 op 100 opgaven op, tegenover ongeveer 87 procent op de oudere academische versie van dezelfde test. Het klassement is sindsdien fors geklommen, maar door systemen die speciaal daarvoor gebouwd zijn, met veel engineering rond het model, en niet door betere modellen.

Daarom kost een antwoord dat fout is maar juist oogt meer dan geen antwoord: er wordt naar gehandeld. Een demo is gemaakt voor het gesprek. Een uitrol moet gemaakt zijn voor wat de demo nooit toont, namelijk of je het antwoord kan nakijken en of iemand achteraf kan achterhalen wat er gelopen heeft.

Agentic analytics tegenover een dashboard met alerts

Allebei merken ze het op. Wat de twee uit elkaar houdt, is wat er gebeurt in de uren nadat er iets niet klopt.

Bij een dashboard met een alertregel stopt de automatisering bij de melding. De alert zegt dat de marge onder 30 procent zit. Iemand opent het rapport, filtert op augustus, exporteert naar Excel, vraagt het aan de collega die het ERP kent, en heeft twee dagen later een oorzaak. De alert klopte, en met die twee dagen deed ze niets.

Bij agentic analytics is de alert net het startpunt. De agent voert de ontleding uit die een mens gedaan zou hebben, en de melding komt binnen mét een shortlist van mogelijke oorzaken en de queries achter elk daarvan. Twee dagen graven worden tien minuten lezen.

Wat niet verandert, is wie verantwoordelijk is. Iemand beslist nog altijd of je de klant belt, het contract heronderhandelt of het prijsbestand herstelt. En het dashboard verdwijnt niet. Cijfers die elke keer identiek moeten zijn, de cijfers voor de raad van bestuur en alles wat een revisor onder ogen krijgt, horen op een pagina die een mens gebouwd en nagekeken heeft.

Wat er echt beschikbaar is, en wat een roadmapslide is

September 2026, en het loont om dit zorgvuldig uit elkaar te houden, want deze categorie wordt verkocht op wat ze volgend jaar belooft. Fabric data agents zijn algemeen beschikbaar, read-only en beheerd, met tot vijf databronnen en queries die lopen als de persoon die de vraag stelt. Snowflake toont de hele waaier binnen één product: het doopte Snowflake Intelligence op 2 juni 2026 om tot CoWork, waar de chat en de domeinagents algemeen beschikbaar zijn, Deep Research in diezelfde aankondiging als binnenkort algemeen beschikbaar stond, en orkestratie over meerdere agents, geheugen en automatiseringen op vaste tijdstippen als binnenkort in publieke preview.

Lees dat zoals het er staat. Op één dag, in één product, is het antwoorden af, het onderzoeken bijna, en het handelen op een eigen uurrooster nog preview. ThoughtSpot en Salesforce zitten op dezelfde plek. En elke leverancier wijst, als je vraagt waarom hun antwoorden kloppen, naar zijn semantische laag.

Waar een KMO begint

Kies één terugkerende analyse die iemand nu elke maand met de hand doet: de margeanalyse, de klantenopvolging, het voorraadrapport waar een halve dag in kruipt. Schrijf eerst de definitie op, want discussieert je team daar twintig minuten over, dan kwam die discussie er toch. Geef de agent daarna de data en de vraag van vorige maand, waarvan je het antwoord al kent omdat iemand het met de hand gemaakt heeft.

Vergelijk dan de bevinding en niet het cijfer. Kwam hij op dezelfde oorzaak uit, in dezelfde volgorde, en verklaarde hij evenveel van het gat? Lees vervolgens de queries, allemaal, want daar leer je of hij het juiste antwoord om de juiste reden gevonden heeft. Herhaal dat drie maanden voor er iemand anders bij komt.

Krijgt hij één keer het cijfer juist en de reden fout, dan heb je een gat in je model gevonden, en dat is de nuttigere uitkomst. In dat gat was je vroeg of laat toch gevallen.

Waar moet je op letten bij agentic analytics

Een zelfverzekerde oorzaak is lastiger na te kijken dan een fout cijfer. Een fout totaal wordt opgemerkt, want iemand aan tafel weet ongeveer wat de omzet was. "De daling komt van de klantenmix in fittingen" heeft niets om tegen af te toetsen behalve de queries eronder.

De agent stopt zodra hij een geloofwaardig verhaal heeft. Hij vond een klant die vijf van de acht punten verklaart en schreef dat op als het antwoord. Vraag in elk rapport welk aandeel van het gat verklaard is, en behandel alles onder tachtig procent als onafgewerkt.

De kost zit per onderzoek, niet per vraag. Een dozijn queries en een lange redeneerketen per keer, maal iedereen die op de knop mag duwen, maal elke ochtend. Zet er een uitgavenlimiet op voor je uitrolt, zoals bij elke agent die uit zichzelf geld uitgeeft.

Ontbrekende data faalt stil. Een agent die werkt op een warehouse waar een laadproces mislukt is, rapporteert over wat er staat en heeft geen idee van wat er niet staat. Controles op versheid en volledigheid van de bron horen in het ontwerp.

Taal. De beheerde Microsoft-optie ondersteunt op moment van schrijven enkel Engels, dus je collega's in Genk die hun vraag in het Nederlands typen, zitten niet op het pad dat getest is.