Waarom je AI-agent niet als sessie moet meten, maar als run

De blinde vlek zit niet in de klik, maar in de uitvoering

Veel productteams meten AI-agents nog alsof het gewone software is. Er is een gebruiker, er is een interface, er zijn sessies, clicks, prompts, conversies en misschien een tevredenheidsscore. Dat lijkt logisch, maar bij agents mist die manier van meten precies het stuk waar het spannend wordt: de zelfstandige uitvoering tussen input en resultaat.

Een klassieke productanalyse kan laten zien dat iemand een taak start, een knop indrukt of een output ontvangt. Maar een AI-agent doet ondertussen iets anders dan een formulier of chatbot. Hij interpreteert een doel, kiest stappen, gebruikt mogelijk tools, vraagt soms om extra informatie, maakt tussenbeslissingen en levert daarna iets op dat de gebruiker wel of niet vertrouwt. Als je alleen de sessie meet, zie je vooral de schil. De echte productervaring ontstaat binnen de run.

Voor operators en productteams is dat geen semantisch detail. Het verschil bepaalt of je op tijd ziet waar vertrouwen breekt. Een agent kan technisch een taak afronden, terwijl de gebruiker het resultaat alsnog kopieert naar een collega, handmatig controleert of helemaal niet gebruikt. In een traditioneel dashboard lijkt dat misschien op voltooiing. In werkelijkheid is het een adoptieprobleem.

Wat is een run bij een AI-agent?

Een run is de volledige uitvoering van één taak door een agent. Die begint niet bij de eerste klik, maar bij het doel dat de gebruiker of het systeem aan de agent geeft. Daarna volgt de route: welke context gebruikt de agent, welke acties probeert hij, welke tools worden aangeroepen, welke tussenresultaten ontstaan, waar loopt hij vast en wanneer wordt er opgeschaald naar een mens?

Een bruikbaar run-model bevat minimaal zeven onderdelen. Eén: het taaktype, bijvoorbeeld plannen, samenvatten, verrijken, controleren of uitvoeren. Twee: de bron van de taak, zoals gebruiker, systeemtrigger of workflow. Drie: het autonomielevel: mag de agent alleen voorstellen doen, concepten maken of ook zelfstandig wijzigen en verzenden? Vier: de acties en tussenstappen. Vijf: stopmomenten en menselijke goedkeuring. Zes: fouten, retries en herstelacties. Zeven: het uiteindelijke oordeel van de gebruiker.

Juist dat laatste punt wordt vaak onderschat. Productteams zijn gewend aan completion: is de taak klaar? Bij agents moet je daarnaast acceptance meten: wordt de uitkomst geaccepteerd, aangepast, genegeerd of teruggedraaid? Het verschil tussen voltooid en geaccepteerd vertelt veel over vertrouwen. Een run die elke keer technisch slaagt maar structureel wordt afgewezen, is geen succesrun.

Waarom chatlogs en traces niet genoeg zijn

Chatlogs en technische traces zijn nuttig, maar ze beantwoorden een andere vraag. Een chatlog laat zien wat er is gezegd. Een trace laat zien wat er technisch gebeurde. Productanalytics moet laten zien welk gedrag waarde oplevert, waar frictie ontstaat en waar gebruikers afhaken of ingrijpen. Voor AI-agents heb je dus een laag nodig die technische uitvoering koppelt aan productuitkomst.

Stel dat een agent een voorstel maakt voor een klantmail. De trace kan tonen welke stappen zijn uitgevoerd. De chat kan tonen welke instructie de gebruiker gaf. Maar productmatig wil je weten of de mail is verstuurd, herschreven, ter goedkeuring doorgestuurd of weggegooid. Je wilt ook weten of de gebruiker dezelfde correcties steeds opnieuw maakt. Dat is geen puur technisch signaal; het is een product- en vertrouwenssignaal.

Daarom is agent analytics geen extra dashboard voor de liefhebber. Het is de manier waarop je voorkomt dat agentgedrag onzichtbaar blijft tot er frustratie, kosten of risico ontstaat. Zeker wanneer agents toegang krijgen tot data, systemen of klantcommunicatie, is run-level inzicht een voorwaarde om verantwoord te kunnen opschalen.

Meet de acceptance gap, niet alleen de output

De completion-versus-acceptance-gap is een van de belangrijkste signalen in agentproducten. Completion betekent dat de agent de taak volgens het systeem heeft afgerond. Acceptance betekent dat de gebruiker de uitkomst vertrouwt en gebruikt. Tussen die twee kan veel misgaan.

Een gebruiker kan het resultaat te generiek vinden, te risicovol, te duur in tokens, te traag of net niet passend bij de context. Ook kan de gebruiker onzeker zijn over wat de agent precies heeft gedaan. Dat laatste is cruciaal: wantrouwen ontstaat vaak niet alleen door fouten, maar door onduidelijkheid over autonomie. Als mensen niet weten of een agent alleen leest, ook schrijft of al acties heeft uitgevoerd, gaan ze defensief gebruiken.

Meet daarom per run niet alleen succes of fout. Meet ook: hoeveel handmatige correctie was nodig, welke stap vroeg om bevestiging, waar werd de run afgebroken, wanneer werd output gekopieerd maar niet gebruikt en welke reden gaf de gebruiker voor afwijzing. Houd die redenen eenvoudig. Denk aan onjuist, onvolledig, onveilig, niet in tone of voice, te veel werk om te controleren, of geen toestemming om deze actie zelfstandig te doen.

Een praktisch meetkader voor productteams

Begin klein. Je hoeft niet meteen een allesomvattend observability-platform te bouwen. Definieer eerst wat een run is binnen jouw product. Is dat één opdracht, één workflow, één klantcase of één systeemtrigger? Kies daarna welke agentacties productmatig relevant zijn. Niet elke interne stap hoeft in een managementrapport, maar risicovolle acties en terugkerende frictiepunten moeten zichtbaar worden.

Een praktisch schema kan bestaan uit deze velden: run-ID, taaktype, gebruiker of rol, contextbron, autonomielevel, gebruikte tools, aantal stappen, escalaties, fouttype, herstelactie, eindstatus, acceptatiestatus en afwijsreden. Voeg daar kosten- en tijdsignalen aan toe als die relevant zijn voor je productbeslissing, maar voorkom dat kosten de enige lens worden. Een goedkope run die niemand vertrouwt, is nog steeds duur.

Gebruik de data vervolgens niet alleen voor rapportage, maar voor productkeuzes. Taken met hoge afwijzing krijgen betere instructies, lagere autonomie of meer uitleg. Taken met veel escalaties krijgen duidelijkere grenzen. Taken met hoge acceptatie en weinig correcties kunnen juist meer automatisering krijgen. Zo wordt agent analytics een stuurmechanisme voor vertrouwen, niet alleen een grafiek achteraf.

De kern: autonomie vraagt om auditbaarheid

AI-agents worden pas echt waardevol wanneer ze werk uit handen nemen. Precies daarom moet je anders meten. Hoe meer zelfstandigheid je geeft, hoe belangrijker het wordt om per run te begrijpen wat er gebeurde, waarom het gebeurde en of de gebruiker het resultaat accepteerde.

Voor Funnel Adviseur is de praktische les simpel: behandel een agent niet als een chatvenster met extra knoppen, maar als een uitvoerende laag in je funnel, operatie of product. Dan hoort er ook een meetlaag bij die past bij uitvoering. Niet omdat dashboards het doel zijn, maar omdat vertrouwen zonder zichtbaarheid niet schaalbaar is.