Wat is het probleem met duizenden agent-traces?

Een AI-agent die een dag draait, genereert makkelijk duizenden logs. Elk log bevat modelaanroepen, toolaanroepen, foutmeldingen en reactietijden. Je kunt dashboards instellen voor dingen die je al weet te meten, maar het echte probleem is wat je nog niet weet. Welke fout herhaalt zich elke dag, maar is nooit gedefinieerd als metric? Dat is precies het gat dat automatische Insight-analyse probeert te vullen.

Stel je bouwt een AI-agent die klantmails beantwoordt. Je meet al responstijd en foutpercentage. Maar wat als de agent systematisch bij een bepaald type vraag in een loop belandt? Dat zie je niet in je dashboard, want je hebt die loop nooit als fout gedefinieerd.

Observability (zichtbaarheid op wat er gebeurt) en evaluaties (testen op criteria die je al kent) lossen dit niet op. Ze meten wat je al weet. Het ontdekkingsprobleem is anders: je wilt patronen zien die je nog niet zocht.

Dit is het vertrekpunt van Insights in Microsoft Foundry. De tool analyseert je productie-traces en groepeert terugkerend gedrag automatisch in reviewbare bevindingen. Of dat in de praktijk werkt, lees je in de volgende secties.

Voor wie meer wil weten over hoe AI-agents in elkaar zitten: AI agent tools bouwen zonder vijftien versies bij te houden legt de basis goed uit.

Wat bevat een Insight precies?

Een Insight is geen alert en geen foutmelding. Het is een samengestelde bevinding over terugkerend gedrag. Je krijgt een titel en uitleg, gekoppelde traces als bewijs, ernst en categorie voor prioritering, en een voorstel voor vervolgactie. Concreet: niet ‘er is een fout’, maar ‘deze agent herhaalt bij 80 inputs een extractiestap zonder voortgangscheck, hier zijn drie voorbeeldtraces, overweeg een terminatieconditie toe te voegen’.

Het verschil met een gewone foutmelding is het bewijs. Een Insight laat je niet alleen weten dát er iets mis is, maar ook welke traces het laten zien en hoe vaak het voorkomt. Dat maakt het reviewbaar in plaats van vaag.

Let op de beperkingen. Concrete code- of promptwijzigingen als voorstel zijn alleen beschikbaar voor ondersteunde agent-types en configuraties. Voor andere agents krijg je algemene onderzoeksrichtingen, geen kant-en-klaar antwoord. Dat is eerlijk, want een automatisch systeem dat je code herschrijft zonder context is gevaarlijker dan nuttig.

Het systeem scheidt ernst van impact. Een klein probleem kan prima gecalibreerd zijn op ‘laag’ zonder dat het daarmee niet de moeite waard is om te bekijken. Dat zijn twee aparte dimensies, en vermenging ervan leidt tot slechte prioritering.

Hoe goed werkt het? De benchmarkcijfers op een rij

Microsoft heeft de kwaliteit van Insights getest op zes publieke datasets met gelabelde agent-traces. De resultaten lopen sterk uiteen per dataset. Op datasets met alleen mislukte traces haalt het systeem tot 99,7% recall. Op een gemengde dataset met goede en slechte traces zakt die recall naar gemiddeld 57,5%. Dat laatste getal is het meest eerlijke, want echte productieomgevingen zijn altijd gemengd.

De twee meetwaarden zijn trace recall (welk percentage van de bekende fouten pikt het systeem op?) en trace precision (van alles wat als fout wordt aangemerkt, hoeveel is ook echt een fout?). Op de AgentRx Tau-bench dataset, de enige dataset met een echte mix van goede en slechte traces, was de gemiddelde precision 37,8% en de recall 57,5%. Dat betekent: van elke drie traces die een Insight aanwijst als problematisch, is er gemiddeld iets meer dan één ook echt gelabeld als mislukking.

Is dat goed of slecht? Dat hangt af van je alternatief. Heb je nu helemaal geen geautomatiseerde detectie, dan is 57,5% recall een flinke verbetering. Doorzoek je handmatig elke trace, dan kan een precision van 37,8% frustrerend zijn: je kijkt naar veel ruis.

De scores op de LLM-judge evaluatie (hoe goed zijn de bevindingen zelf?) variëren van 2,84 tot 3,88 op een schaal van 1 tot 5. Dat is solide maar niet uitmuntend. Tau2-bench scoort het laagst met 2,84, wat aangeeft dat sommige Insights te generiek zijn voor bepaalde agent-typen.

Meer over hoe je AI-implementaties eerlijk evalueert lees je in AI implementatie kosten: waar het geld écht heen gaat.

Wat betekent dit als je zelf AI-agents bouwt of inkoopt?

Dit type tooling is pas echt waardevol als je agent al in productie draait met enig volume. Voor een agent die tien keer per dag wordt aangeroepen, heb je geen automatische patroondetectie nodig. Ga je richting honderden of duizenden dagelijkse uitvoeringen, dan is handmatig reviewen onmogelijk. Dan wil je weten welke patronen terugkomen, zonder ze allemaal vooraf te definiëren.

Het eerlijke advies: ga er niet van uit dat een Insight een kant-en-klare oplossing geeft. Het is een startpunt voor onderzoek, geen eindoordeel. De tool zegt zelf ook: valideer voorgestelde wijzigingen via je normale evaluatie- en deploymentproces. Dat is precies de juiste insteek.

Koop je AI-agents in via een bureau of platform? Vraag dan naar monitoring en observability. Niet alleen dashboards voor de metrics die je al kent, maar ook mechanismen om onverwacht gedrag te ontdekken. Zegt een leverancier alleen ‘we monitoren op uptime en responstijd’, dan zie je terugkerende fouten in agent-gedrag pas als een klant erover klaagt.

Bouw je agents op Microsoft Azure? Insights in Foundry is nu in public preview, dus gratis te proberen. Koppel je Application Insights-resource aan je Foundry-project en het systeem analyseert bestaande traces. Je hoeft niets opnieuw te bouwen.

Wie bredere keuzes maakt over AI-modellen en migraties: LLM model migratie: zo doe je het zonder gedoe is de moeite waard om naast dit onderwerp te lezen.