De laatste systeemstand is niet altijd de waarheid
Stel: om 19.05 uur vraagt een storingscoördinator aan een AI-agent wat de status van een incident is. Op dat moment is de storing erkend, staan er drie gebeurtenissen op de tijdlijn en is de oorzaak nog onbekend. Om 20.55 uur is het incident opgelost, bevat de tijdlijn tien gebeurtenissen en is de oorzaak vastgelegd.
Als de acceptatietest alleen de uiteindelijke systeemstand gebruikt, ontstaat een vreemde uitkomst. De agent die om 19.05 uur correct meldt dat het incident nog loopt, krijgt een onvoldoende. De agent die antwoordt met informatie uit de toekomst, lijkt juist goed te presteren.
Dat voorbeeld komt uit nieuw onderzoek naar tijdgebonden evaluatie van zakelijke AI-agents. De kern is breder dan incidentmanagement: een antwoord is alleen correct ten opzichte van wat op dat moment bestond én wat die specifieke gebruiker mocht zien. Een actuele databasekopie is daarom niet automatisch geschikte ground truth voor een historisch of doorlopend werkproces.
Toekomstinformatie zit ook ín bestaande records
Dit probleem los je niet op door simpelweg alle records met een latere aanmaakdatum weg te filteren. Bedrijfsrecords veranderen van binnen. Een ticket krijgt opmerkingen, een order verandert van status, een dossier krijgt een besluit, een e-mailthread groeit en een onderhoudsmelding krijgt later een oorzaak en afsluitdatum.
Een record kan dus al om 19.05 uur hebben bestaan, terwijl de versie in de testomgeving informatie bevat die pas uren of dagen later is toegevoegd. Zonder reconstructie per tijdstip test je niet of de agent toen een goed antwoord had kunnen geven. Je test of hij nu de laatste versie kan navertellen.
Dat verschil raakt ook acties. Een agent die een order om 14.00 uur correct niet vrijgeeft omdat een controle nog ontbreekt, mag niet zakken omdat die controle om 16.00 uur alsnog is afgerond. Anders leert de evaluatie precies het verkeerde gedrag: handelen met kennis die tijdens de echte uitvoering nog niet beschikbaar was.
Toegangsrechten horen bij het verwachte antwoord
Tijd is maar de helft van het vraagstuk. Twee medewerkers kunnen op hetzelfde moment een andere geldige werkelijkheid zien. Een servicemedewerker ziet bijvoorbeeld het klantdossier en de openbare incidentstatus, terwijl een engineer ook interne foutlogs en beveiligingsdetails kan bekijken.
Een antwoord kan feitelijk kloppen en toch onacceptabel zijn wanneer de agent daarvoor een bron gebruikte die de vragende medewerker niet mocht zien. Daarom moet een acceptatiescenario niet alleen een vraag en referentieantwoord bevatten, maar minimaal ook een persona, tijdstip, zichtbare bronnen en toegestane handelingen.
Dat maakt rechten onderdeel van de testdata in plaats van een losse beveiligingscontrole achteraf. Het laat bovendien een belangrijk onderscheid zien: een agent kan te weinig informatie hebben zonder defect te zijn. In zo'n geval is een correct antwoord bijvoorbeeld dat bewijs ontbreekt of dat escalatie nodig is. Zekerheid veinzen is dan de fout.
Een bruikbare acceptatieset heeft een scenario-klok
Voor document- en systeemoverschrijdende workflows moet een acceptatieset meer doen dan een verzameling losse prompts afspelen. Bouw scenario's rond echte procesgebeurtenissen: een aanvraag komt binnen, een controle wordt toegevoegd, iemand past een dossier aan, een uitzondering wordt goedgekeurd en het doelsysteem verandert van toestand.
Leg per relevant moment vast:
- welke records toen bestonden en welke versie van ieder record geldig was;
- welke medewerker of rol de vraag stelde;
- welke bronnen en tools voor die rol toegankelijk waren;
- welke feiten nog onbekend of onbevestigd waren;
- welke handeling, systeemwijziging of escalatie als succes telde;
- welke informatie de agent expliciet niet mocht gebruiken.
Test daarna niet alleen de tekst van het antwoord. Controleer ook de gebruikte bronnen, uitgevoerde toolcalls, goedkeuringsmomenten en uiteindelijke toestand van CRM, ERP, ticketsysteem of dossier. Een agent die een overtuigend afrondingsbericht schrijft maar het verkeerde record bijwerkt, is operationeel niet geslaagd.
Maak de test reproduceerbaar vóórdat je modellen vergelijkt
Het onderzoek beschrijft een aanpak waarbij veranderlijke records vooraf voor relevante tijdstippen worden gereconstrueerd. Mechanische wijzigingen — latere opmerkingen verwijderen, toekomstige tijdvelden leegmaken en groeiende lijsten inkorten — worden met vaste regels verwerkt. Alleen waar interpretatie nodig is, bijvoorbeeld bij vrije tekst of een afgeleide status, wordt een taalmodel gebruikt. Die uitkomsten worden vooraf berekend, zodat tijdens het daadwerkelijke testen geen extra model de score kan laten schommelen.
Volgens de auteurs leverde één uitgewerkt proces tientallen tests per tijdstip en persona op, daalde het aansluiten van een nieuwe applicatie van dagen naar minuten en waren batchruns exact reproduceerbaar. Dat zijn vroege ervaringen met de beschreven architectuur, geen onafhankelijke vergelijking van agents of bewijs dat iedere gereconstrueerde historische toestand perfect is. De auteurs noemen die laatste validatie zelf als open vraag.
De ontwerpregel is desondanks direct bruikbaar: stabiliseer eerst de testwereld en vergelijk daarna pas modellen, prompts of agentarchitecturen. Als de verwachte werkelijkheid tussen twee runs verschuift, weet je niet of de agent beter werd of alleen de meetlat veranderde.
De go-livevraag is niet alleen: werkt het nu?
Een goede eerste workflow heeft een eigenaar, afgebakende uitkomst en acceptatieset. Voor processen met veranderlijke data hoort daar een extra vraag bij: werkt de agent op ieder beslismoment met de informatie en bevoegdheden die dán geldig zijn?
Vraag bij acceptatie daarom om scenario's uit het midden van het proces, niet alleen om nette eindgevallen. Laat zien wat de agent doet vóórdat informatie compleet is, nadat een status wijzigt, wanneer twee rollen verschillende toegang hebben en wanneer een eerder correct antwoord later achterhaald raakt. Neem iedere gevonden fout vervolgens op als regressietest.
Een momentopname bewijst dat een agent één bevroren wereld aankan. Een operationele workflow vraagt meer: correct handelen terwijl die wereld verandert.
Bronnen: What Could the Agent See at 19:05? (Sahu en Arora, 2026); Reproducible Hybrid Time-Travel Retrieval in Evolving Corpora (Staudinger, Piroi en Rauber, 2024).