Waar een AI-agent zijn toestand moet bewaren

Het ERP, het centrale bedrijfssysteem, bevatte dezelfde leverancier twee keer. Een AI-agent verzorgde het aanmaken van nieuwe leveranciers: hij las de documenten, controleerde het btw-nummer, maakte de leverancier aan, vroeg bankgegevens op en stelde betalingsvoorwaarden in. In de tests ging alles goed. In de eerste live week herstartte een routinematige software-update de dienst midden in een geval, en de agent maakte de leverancier opnieuw aan.

Het model redeneerde beide keren juist. De fout zat in waar de agent bijhield wat hij al had gedaan: in een aanroep naar het ERP en het antwoord, in de gespreksgeschiedenis die de herstart wiste. Het beeld van de agent en de werkelijkheid liepen uit elkaar, en niets in het ontwerp merkte het.

De meeste agentfouten die wij onderzoeken, zien er zo uit: fouten in waar informatie staat, die op denkfouten lijken omdat het symptoom in de uitvoer zit.

Drie soorten informatie, drie eigenaren

Veel agenttools laten drie soorten informatie door elkaar lopen, en daar beginnen de problemen.

Het bronsysteem is het bedrijfssysteem met de geldende gegevens: het ERP, de klantendatabase, het ticketsysteem, de bank. Het past eigen controles toe en is van de IT-afdeling van de klant. De agent wijzigt het alleen via bestaande koppelingen.

Het dossier is het blijvende verslag van het werk: afgeronde stappen, beslissingen, bewijs, goedkeuringen. De workflow schrijft het, niet het AI-model. Het staat naast het bedrijfssysteem, in opslag van de klant, nooit in vrije velden van het ERP, waar het de agent aan de updates van het ERP zou binden en werknotities met geldende gegevens zou mengen.

De werkcontext is wat het model in de huidige stap ziet: instructies, de relevante documenten, feiten uit de andere twee. Ze wordt voor één stap opgebouwd en daarna weggegooid.

De regel: de context is een weergave, nooit een opslag. Wat een stap moet overleven, wordt in het dossier of het bedrijfssysteem geschreven voordat de stap als klaar telt. Stopt het proces op enig moment, dan bouwt een nieuw proces de context opnieuw op en gaat verder. Dat testen we letterlijk: tijdens de acceptatietest stoppen we de agent op willekeurige momenten en controleren of elk geval toch precies één keer wordt afgerond.

Er is een tweede reden om opnieuw op te bouwen in plaats van op te stapelen. Engineers van Anthropic beschrijven wat zij context rot noemen ("Effective context engineering for AI agents", september 2025): hoe meer een model moet vasthouden, hoe slechter het dat gebruikt, dus context is een budget met afnemend rendement. Een context die per stap opnieuw ontstaat, bevat alleen wat die stap nodig heeft, en de agent blijft scherp op dag twee van een geval, als een opgestapelde geschiedenis vol achterhaalde waarden zou zitten.

Zo toetst u ook snel elk agentontwerp, dat van een leverancier inbegrepen: vraag waar elk van de drie staat. Is het antwoord voor twee ervan "in het gesprek", dan heeft het ontwerp er maar één.

Leg de bedoeling vast voordat u handelt

Veilig herstarten hangt af van de volgorde van schrijven. Vóór elke stap die iets buiten verandert, legt de workflow vast wat hij gaat doen (deze leverancier aanmaken, voor dit geval), en daarna het kenmerk dat het systeem teruggaf. Een herstart vindt dan een open voornemen, geen leeg blad, en niets wordt herhaald voordat dat voornemen is afgehandeld.

Bij de onboarding verdween de dubbele leverancier hiermee zonder één woord aan de instructies van de agent te veranderen, die nooit de oorzaak waren. De prijs is een paar extra schrijfacties en wat vertraging per stap, altijd goedkoper dan één dubbele leverancier, order of betaling.

Een plan veroudert zodra het er ligt

Veel agenttools plannen één keer en voeren dan uit. In een organisatie is dat omgekeerd. In een geval van twee dagen wijzigt een inkoper de order, blokkeert kredietbeheer de klant en corrigeert iemand het adres, terwijl de agent een plan met de oude waarden vasthoudt.

Dus het plan is wegwerpbaar en de controles zijn het waardevolle deel. Elke stap die iets wijzigt, draagt de waarden mee waarop hij werd gepland: de versie van de order, de kredietstatus, een vingerafdruk van het adres. Vóór uitvoering vergelijkt hij ze met het actuele record. Ongewijzigd: hij gaat door. Gewijzigd in een veld dat hij niet gebruikt: hij gaat door en legt het vast. Gewijzigd in een veld waarop hij steunt: hij stopt en geeft het geval terug om opnieuw te plannen, en een mens ziet beide versies.

Tussen controle en schrijven blijft een gat. Waar het systeem het ondersteunt, draagt de schrijfactie de voorwaarde zelf. De Dataverse Web API achter de klantapps van Microsoft Dynamics 365 geeft bijvoorbeeld bij elk record een versiekenmerk en weigert een update als het record sinds het lezen is veranderd. De controle geldt dan op het moment van schrijven, niet seconden ervoor.

In de systemen die wij hebben onderzocht, veroorzaken verouderde plannen meer foute wijzigingen dan foute redeneringen, en in tests vallen ze niet op, omdat testdata nooit verandert terwijl de agent nadenkt. Voor stamgegevens zoals klant- en productlijsten geldt hetzelfde: een agent met een eigen kopie voor snelheid werkt vroeg of laat met een verouderde, dus leest hij actuele waarden in de stap die ze nodig heeft.

De context elke stap opnieuw opbouwen kost tijd als een geval lange documenten meedraagt: een contract, een prijslijst, een aanbesteding van honderd pagina's. Daarom bewaren we wat eruit is gehaald, een geëxtraheerde tabel of een samenvatting van de voorwaarden, gelabeld met de versie van de bron, nooit met het gesprek. Verandert de bron, dan wordt het oude uittreksel niet meer gebruikt. De snelheid komt terug zonder dat de context een opslag wordt.

Geheugen dat beslissingen verandert, is een bedrijfsregel

Agents komen nu vaak met geheugen: samenvattingen van eerder werk, bewaard voor later. Hetzelfde stuk van Anthropic beschrijft notities en samenvattingen voor lange taken, wat past bij onderzoeks- en programmeeragents. In een organisatie heeft samenvatten een grens nodig. Een samenvatting houdt wat belangrijk lijkt, en de rest is in een zakelijk geval vaak juist de uitzondering: de creditnota die te laat kwam, de goedkeurder die om een tweede offerte vroeg. Dus alleen de werkcontext wordt samengevat. Het model mag een samenvatting van het dossier lezen; het dossier zelf, het controlespoor, blijft volledig.

Bedrijfsbeslissingen vragen een hardere grens. Leert een agent dat een leverancier per pallet factureert terwijl de inkooporder dozen telt, dan verandert dat hoe toekomstige facturen worden gekoppeld. Het is een bedrijfsregel en wordt zo opgeslagen: het feit, het geval waaruit het komt, wie het bevestigde, wanneer het verloopt. Een financieel analist kan het lezen, corrigeren of verwijderen. Geheugen dat niemand kan inzien, zoals opgeslagen sporen van oude gesprekken die gedrag verschuiven op een manier die geen auditor kan volgen, mag niet in de buurt van een bedrijfsbeslissing komen.

Waar het bedrijf zich herinnert

Deze scheiding kost ontwerptijd voordat de agent iets indrukwekkends doet, dus onder demodruk wordt ze uitgesteld, en de demo werkt toch: demo's zijn kort, hebben één gebruiker en worden nooit herstart. Het betaalt zich uit in gebruik: de agent kan op elk moment worden gestopt, twee mensen zien bij een geval dezelfde geschiedenis, en als het model volgend jaar wordt vervangen, gaat er niets verloren, want niets zat in het model.

In de context denkt de agent. In het dossier herinnert het bedrijf zich.