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.

Waarom één regel code veranderen zo gevaarlijk is?

Het aanpassen van een model naam in je code lijkt triviaal. Maar een nieuw model kan volledig andere JSON teruggeven, langere samenvattingen produceren, of tool-aanroepen in een andere volgorde afvuren. Je foutmeldingenlog blijft leeg. Je gebruikers krijgen rare antwoorden. Dat is het echte risico van een model migratie zonder plan.

Stel je bouwt een bestelassistent voor een webshop. Die roept een AI-model aan, dat JSON teruggeeft met velden als product_id, quantity en shipping_option. Je vervangt het model, de API reageert nog steeds, je dashboard zegt groen. Maar het nieuwe model geeft productId terug in camelCase. Je parser crasht niet. Hij leest gewoon een leeg veld en slaat een bestelling op zonder product-ID.

Dit is precies het probleem dat Microsoft Foundry beschrijft: model failures zijn vaak stil voor de systemen die het model aanroepen, maar luid voor de eindgebruiker. Dat maakt het zo lastig. Er is geen alarm. Alleen een groeiende supportwachtrij.

Eerlijk gezegd is dit het type fout dat ik zelf ook niet direct zou zien aankomen. Je denkt: ik verander een string, wat kan er misgaan? Veel, blijkt. Elk model heeft zijn eigen ‘karakter’ in hoe het formaten, hoe uitgebreid het antwoordt en hoe het tools aanroept. Dat karakter verandert bij elke generatiewissel. Een goed begrip van hoe LLMs werken helpt je hier sneller doorheen.

GPT-4o stopt op 1 oktober 2026: wat doe jij nu?

Microsoft maakt het concreet: GPT-4o (versie 2024-05-13) wordt op 1 oktober 2026 afgezet. De opvolger is GPT-5.1. Pay-as-you-go deployments worden automatisch omgezet, maar provisioned deployments (PTU) doe jij zelf. En automatisch omzetten betekent niet dat je app zich hetzelfde gedraagt.

Er zijn drie soorten deployments op Microsoft Foundry, en ze worden elk anders behandeld bij een pensionering:

• Standard / Global Standard / Data Zone Standard (pay-as-you-go): worden automatisch geüpgraded. Je bepaalt de timing via de instelling versionUpgradeOption. Kies je NoAutoUpgrade, dan stopt de deployment gewoon op de pensioneringsdatum.
• Provisioned (PTU): worden niet automatisch gemigreerd. Jij regelt dit zelf, in-place (20-30 minuten zonder downtime) of naast elkaar (side-by-side).
• Batch deployments: altijd side-by-side aanpak. Nieuw model deployen, jobs opnieuw indienen, oud model weggooien.

Microsoft maakt een vervangend model beschikbaar in Global Standard ongeveer 90 dagen voor pensionering, in provisioned regio’s 30 dagen van tevoren en in standaard regio’s 2 weken ervoor. Je hebt dus tijd, maar die raakt op als je wacht.

Mijn standpunt: begin nu met de validatie op GPT-5.1, ook als je deployment automatisch wordt omgezet. Automatisch verkeer omzetten bewijst niet dat je app zich hetzelfde gedraagt. Dat bewijs lever jij zelf.

De 6 fasen van een veilige model migratie

Microsoft Foundry beschrijft zes fasen: Discover, Assess, Adapt, Validate, Roll out en Retire. Elke fase heeft een duidelijk eindpunt. Geen fase overslaan, ook niet als het model ‘lijkt te werken’. De Adapt-fase is voor de meeste productie-apps de zwaarste en meest tijdrovende.

Hier zijn de zes fasen kort uitgelegd, met wat ik er zelf bij denk:

1. Discover: je hoort dat een model met pensioen gaat, of je wilt proactief upgraden. Einddoel: weet je wat er verandert en wanneer?
2. Assess: kies een kandidaat-model en check of het beschikbaar is in jouw regio, SKU en quota. Let op: prijsstructuren veranderen per generatie. Redeneer-tokens, gecachte input en structured-output overhead kunnen je kosten met factor 2 of meer verschuiven.
3. Adapt: speel je huidige workload af op het nieuwe model zonder aanpassingen. Kijk waar het gedrag afwijkt: verbositeit, JSON-structuur, tool-aanroepen. Pas daarna je prompts, parameters en output-schema’s aan.
4. Validate: run een evaluatiesuite met concrete kwaliteitscriteria. Azure AI Evaluation SDK heeft meer dan 30 evaluatoren, inclusief LLM-as-judge (dat is een AI die de output van een andere AI beoordeelt).
5. Roll out: stuur eerst een klein percentage verkeer naar het nieuwe model (canary deployment). Meet live kwaliteit naast latency en foutpercentages. Houd rollback mogelijk.
6. Retire: gooi het oude deployment weg, archiveer je evaluatie-artifacts en noteer wat je hebt geleerd.

Fase 0 staat er eigenlijk voor: bouw een testdataset van echte productie-input vóór je begint. Zonder die dataset heb je niets om tegen te valideren. En die dataset moet je nu al loggen, want productie-logs zijn niet retroactief beschikbaar.

Welke tools helpen je door elke fase heen?

Microsoft Foundry heeft voor elke fase specifieke tooling: van model-pensioneringschema’s en leaderboards in Assess, tot de Prompt Optimizer in Adapt en de Azure AI Evaluation SDK in Validate. De tooling is goed, maar er zijn ook gaten waar je zelf iets moet bouwen.

Wat goed werkt in de Foundry toolchain:

• Discover: het model-pensioneringschema en de Models API geven je programmatische toegang tot pensioneringsdatums en vervangers. Ideaal voor een interne notificatielaag.
• Assess: model leaderboards vergelijken kwaliteit, veiligheid, kosten, doorvoer en latency. Je kunt tot drie modellen naast elkaar vergelijken.
• Adapt: de Prompt Optimizer in de Foundry Agent playground helpt je prompts aanpassen. Een simulator genereert synthetische testdata als je geen productie-data hebt.
• Validate: Azure AI Evaluation SDK met 30+ evaluatoren. Inclusief LLM-as-judge voor kwalitatieve beoordeling.
• Roll out: automatische upgrade-opties, continuous evaluation en Azure Monitor alerts.
• Retire: de Models API geeft een 410 Gone terug als een model echt offline is. Je observability dashboard toont het deployment-aantal.

Waar het soms misgaat: teams ontdekken een pensionering via e-mail of een productie-fout, in plaats van via een gestructureerd systeem. En soms blijkt een gekozen model niet beschikbaar in de vereiste regio, iets wat je pas ontdekt als de planning al klaar is. Dat is vervelend. Mijn advies: valideer beschikbaarheid in jouw specifieke regio als eerste stap in de Assess-fase, niet als laatste.

Als je meer wilt weten over wat AI-implementatie in de praktijk kost, ook buiten de licentiekosten, bekijk dan wat AI implementatie echt kost aan tijd en aanpassing.

Wat moet jij nu concreet doen als je een AI-app draait?

Check welk model je deployment gebruikt en wanneer dat model met pensioen gaat. Zet logging aan als je dat nog niet hebt. Start alvast met het bouwen van een testdataset op basis van echte productie-input. Wacht niet op een pensioneringsbericht.

Drie concrete stappen die je deze week kunt zetten:

1. Check je deployment type. Gebruik je Standard of Provisioned? Bij Provisioned doe jij de migratie zelf. Dat wil je weten voordat de deadline nadert.
2. Zet content capture aan. Log je prompts, responses, latency en token-aantallen nu. Dit is opt-in en nooit retroactief. Zonder logs heb je geen testdataset voor Validate.
3. Plan een side-by-side test. Draai je huidige workload op GPT-5.1 naast je huidige model. Kijk waar de output afwijkt. Dat hoeft niet perfect te zijn, maar je wilt weten waar de risico’s zitten voordat je live gaat.

Overigens: je hoeft niet te wachten op een pensioneringsbericht om te beginnen. Als een nieuw model betere kwaliteit of lagere kosten biedt, is dat reden genoeg om het proces te starten. Een geplande migratie is altijd minder stressvol dan een gedwongen upgrade op een datum die je niet hebt gekozen.

Voor bredere context over hoe AI-tools en -modellen zich in 2026 ontwikkelen, is het ook de moeite waard om te volgen hoe grote platforms als Google hun AI-functies uitrollen en wat dat voor afhankelijkheden in je toolstack betekent.

Wat is Model 2 en hoe sterk is het precies?

Anthropic heeft intern een model in gebruik dat ze Model 2 noemen, ingedeeld in de Mythos-klasse. Op hun interne capaciteitsindex, de AECI, scoort het 1,5 punten hoger dan Claude Mythos 5, het sterkste model dat nu publiek beschikbaar is. Dat klinkt indrukwekkend, maar de sprong is kleiner dan de stap van Mythos Preview naar Mythos 5. Model 2 is op sommige vlakken zelfs zwakker dan Mythos 5. Geen grote generatiesprong dus, eerder een incrementele verbetering.

De AECI is een verzameling interne benchmarks waarmee Anthropic bijhoudt hoe capabel hun modellen zijn. Benchmarks zijn altijd een momentopname: ze meten wat je ervoor kiest te meten. Dat Anthropic zelf zegt dat Model 2 slechts 1,5 punt hoger scoort, is waarschijnlijk eerlijk, maar het is ook hun eigen meetlat.

Wat meer zegt: Anthropic omschrijft het verschil als ‘iets sterker overall, maar zwakker op sommige gebieden’. Dat is geen doorbraak. Het is een fijnafstelling. Ze trekken geen grote conclusies over wat dit model anders maakt. Opvallend voor een bedrijf dat normaal graag over haar modellen communiceert.

Voor de context: als je nu al werkt met Claude Code en de bijbehorende gebruikslimieten, dan is dit het soort model dat intern de basis vormt voor verdere ontwikkeling. Jij ziet het niet, maar het beïnvloedt wel hoe het systeem zich verder ontwikkelt.

Schrijft AI nu de code van een AI-bedrijf zelf?

Ja, en dat is misschien wel het meest concrete gegeven uit dit verhaal. Anthropic meldt dat Claude inmiddels het grootste deel van de code schrijft die in hun eigen productiesystemen draait. Model 2 zit daar middenin, deels via agents die continu doorwerken. Het model is intern gereviewed, maar minder grondig getest dan Mythos 5 publiek is getest. Anthropic ziet geen nieuwe of zorgwekkendere vormen van misalignment.

Misalignment is een term uit AI-veiligheidsonderzoek. Het betekent dat een model doelen nastreeft die niet overeenkomen met wat mensen bedoelen of willen. Anthropic zegt dat de risico’s hierop ‘laag’ zijn voor Model 2, en dat ze bij de interne review niks nieuws of verontrustends hebben gevonden.

Dit is een vrij openhartige mededeling. De meeste AI-labs vertellen je niet welk model ze intern gebruiken, laat staan dat ze zeggen dat het hun eigen productiecode schrijft. Dat Anthropic dit publiceert in een risicoreport, is een teken dat ze hun veiligheidscommunicatie serieus nemen.

Of dat genoeg is? Dat is een andere vraag. Lees ook hoe Anthropic zijn veiligheidsnormen aanscherpt. Dit past in dat patroon: transparantie over wat er intern gebeurt, ook als het ongemakkelijk is.

Wat betekent dit als je nu Claude gebruikt voor je werk?

Eerlijk gezegd: weinig direct. Je hebt geen toegang tot Model 2, en er zijn geen plannen om dat te veranderen. Wat je meeneemt: het beste model van een AI-lab is zelden het model dat jij kunt gebruiken. Dat geldt voor Anthropic, maar ook voor andere labs. De publieke modellen zijn krachtig genoeg voor het meeste werk. Maar denk je dat je het absolute topmodel gebruikt? Dat klopt waarschijnlijk niet.

De kloof tussen intern gebruik en publieke toegang is structureel. Dat is niet per se erg. Labs testen nieuwe modellen eerst intern voor ze ze breed uitrollen. Dat is verantwoord. Maar het betekent ook dat als jij nu Claude Mythos 5 gebruikt, je werkt met een model dat intern al ingehaald is.

Voor de meeste taken maakt dat niks uit. Gebruik je Claude om tekst te schrijven, code te reviewen of vragen te beantwoorden? Dan is Mythos 5 meer dan krachtig genoeg. De 1,5 punten extra die Model 2 scoort op een interne index, vertalen zich niet automatisch naar merkbaar betere output op alledaagse taken.

Waar het relevant wordt: als je AI inzet voor complexe, meerstaps-taken zoals AI-agents die als ontwikkelteam werken. Dan kunnen kleine capaciteitsverschillen op de marge groot worden. Maar dat is voor de meeste Nederlandse ondernemers nog toekomstmuziek.

De echte les hier is een andere: vergelijk AI-modellen niet op basis van wat labs intern gebruiken, maar op basis van wat jij ermee doet in de praktijk. De eerlijke vergelijking tussen ChatGPT Pro en Claude is relevanter dan het bestaan van een model dat je toch niet kunt aanraken.

Het kostenplaatje dat klanten verrast

De software is goedkoop. Een AI-tool kost per medewerker meestal tussen de 20 en 50 euro per maand. Wat klanten verrast: de tijd om de tool zinvol in hun werkproces te krijgen kost vaak meer dan de licentie zelf.

Vorig jaar adviseerde ik een ondernemer met acht medewerkers over een AI-schrijftool voor de klantenservice. De licentie was 35 euro per gebruiker per maand. Hij dacht dat hij voor 280 euro per maand klaar was.

De realiteit: drie weken om het team te trainen, twee dagen om de tool aan zijn helpdesk-systeem te knopen, en daarna nog wekelijks bijsturen omdat de AI antwoorden gaf die niet bij zijn merkstem pasten. Bij elkaar zat er aan zijn kant zo’n 40 uur in voor hij de tool echt productief had.

Niet ongewoon. Bij vrijwel elke klant die ik begeleid is de implementatietijd het grootste kostenpost, niet de tool zelf.

Waarom Anthropic en OpenAI nu consultancy aanbieden

Beide grote AI-bedrijven zijn aparte takken gestart die ondernemingen helpen met implementatie. Niet omdat hun tooling zo moeilijk is, maar omdat de implementatie-uren vaak buiten hun klanten hun bereik vallen.

Anthropic en OpenAI hebben in 2026 elk een professional services arm opgetuigd. Voor enterprise-klanten heel logisch: een MKB-bedrijf dat ChatGPT op zijn factuurproces wil zetten, weet vaak niet waar te beginnen.

Voor de gemiddelde Nederlandse ondernemer is dit pakket waarschijnlijk te zwaar (en te duur, denk in tonnen, niet in honderden euro’s). Maar het signaal is wel duidelijk: de AI-bedrijven zelf erkennen dat hun software alleen niet genoeg is om resultaat te halen. Daar zit een hint voor jou: investeer ook in begeleiding aan jouw kant.

Wat dit betekent voor je budget-planning

Plan voor elke AI-tool drie kostenposten: de licentie, de implementatie-uren en het onderhoud. Vergeet de derde post niet, die telt jaar na jaar door.

Mijn vuistregel als ik klanten een AI-tool aanraad:

Licentie: wat het bedrijf op de website vraagt, per maand maal twaalf.

Implementatie: tussen tweemaal en vijfmaal de jaarlicentie. Twee voor een eenvoudige use-case zoals klantenservice-mails, vijf voor iets dat in meerdere systemen moet haken.

Onderhoud: minimaal 10 procent van de jaarlicentie per kwartaal. Modellen veranderen, prompts moeten bijgewerkt, integraties breken. Dit kostenpost vergeten klanten consequent en het wreekt zich na zes maanden.

Mijn werkwijze bij klanten

Ik adviseer klanten altijd om eerst klein te beginnen: één proces, één tool, drie maanden uitproberen. Pas daarna opschalen. Dat voorkomt dat je vastzit aan een dure tool die niet bij je werk past.

Wat ik zelf doe bij elke klant: we kiezen één proces dat duidelijk afgebakend is en waar de pijn voelbaar is. Vaak klantenservice of routinematige tekstwerk. Daar zetten we drie maanden lang één AI-tool op, met een vast budget voor zowel software als implementatie.

Na drie maanden meten we: scheelt het echt tijd, klopt de kwaliteit, vinden de medewerkers het werkbaar. Pas als het antwoord drie keer ja is, breiden we uit. Dat scheelt veel achteraf-wisselen, en het maakt de echte kosten zichtbaar voordat je je hele bedrijf eraan vasthecht.