De context van een agent is niet het dossier

Het ERP bevatte dezelfde leverancier twee keer. Het interne team van een klant had een agent gebouwd voor het aanmaken van nieuwe leveranciers: hij las de documenten van de leverancier, controleerde het btw-nummer, maakte de leverancier aan, vroeg de bankgegevens op en stelde de betalingsvoorwaarden in. In de tests ging alles goed. In de eerste week in productie herstartte een routinematige deployment de service terwijl de agent halverwege een geval was. Toen hij weer opstartte, maakte hij de leverancier opnieuw aan.

Het model had beide keren correct geredeneerd. De fout zat in de plek waar de agent bijhield wat hij al had gedaan: in een toolaanroep en het antwoord daarop, binnen een gespreksgeschiedenis die bij de herstart verloren ging. Wat de agent dacht dat er was gebeurd en wat er werkelijk was gebeurd, liepen uit elkaar, en niets in het ontwerp had dat door.

De meeste fouten van agents die wij in productie onderzoeken, zien er zo uit. Het zijn fouten in state die lijken op fouten in redeneren, omdat het symptoom zichtbaar wordt in de uitvoer van de agent.

Drie soorten state, drie eigenaren

Een agent die in de bedrijfsvoering werkt, heeft met drie soorten state te maken. Frameworks laten die door elkaar lopen, en daar beginnen de problemen.

Het bronsysteem is het ERP, het CRM, het ticketsysteem of de bank. Daar staat de zakelijke waarheid, het systeem past zijn eigen validaties en rechten toe en het is van het IT-team van de klant. De agent wijzigt het alleen via bestaande interfaces.

Het dossier is de blijvende vastlegging van het werk: welk geval, welke stappen zijn afgerond, wat er bij elke stap is besloten, het bewijs en wie wat heeft goedgekeurd. De workflow schrijft het dossier, niet het model. Het staat naast het bronsysteem, in een opslag die van de klant is. Nooit in maatwerktabellen of ongebruikte velden van het ERP, want dan hangt de agent vast aan de upgradecyclus van het ERP en raken werknotities vermengd met zakelijke gegevens.

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

Daaruit volgt de regel. De context is een weergave, nooit een opslag. Alles wat na een stap nog nodig is, wordt in het dossier of het bronsysteem vastgelegd voordat de stap als afgerond geldt. Valt het proces op een willekeurig moment weg, dan bouwt een nieuw proces de context opnieuw op uit die twee bronnen en gaat verder. Dat testen we letterlijk: tijdens de acceptatierun schieten we de worker op willekeurige momenten af en controleren we of elk geval nog steeds precies één keer wordt afgerond.

Het is ook een snelle manier om elk agentontwerp te beoordelen, ook dat van een leverancier. Vraag waar elk van de drie soorten state staat. Luidt het antwoord bij twee ervan "in het gesprek", dan heeft het ontwerp er in werkelijkheid maar één.

De intentie wordt vastgelegd voor de wijziging

Of een agent na een onderbreking veilig verder kan, hangt af van de volgorde waarin hij schrijft. Voor elke stap die iets in een ander systeem verandert, legt de workflow eerst de intentie vast (leverancier aanmaken, met deze zakelijke sleutel). Daarna vraagt hij het bronsysteem of er onder die sleutel al een eerdere poging bestaat, voert hij de wijziging alleen uit als dat niet zo is en legt hij tot slot het kenmerk vast dat het systeem teruggaf. Een crash tussen twee van die stappen richt dan geen schade aan.

Bij de beoordeling van die leveranciersagent verdween de dubbeling door deze volgorde, zonder één wijziging in de prompt. Het team had eerder een week aan het bijschaven van de prompt besteed. De prijs is een paar extra schrijfacties en wat vertraging per stap, en in bedrijfsprocessen is dat altijd goedkoper dan één dubbele leverancier, order of betaling.

Een plan is verouderd zodra het is gemaakt

De meeste agentframeworks behandelen het plan als het waardevolste onderdeel: één keer redeneren, dan uitvoeren. In de bedrijfsvoering is het andersom. Bij een geval dat twee dagen loopt, past een inkoper de order aan, blokkeert credit control de klant en corrigeert iemand het afleveradres, terwijl de agent vasthoudt aan een plan dat op de oude gegevens is gebaseerd.

Het plan is daarom wegwerpbaar en de randvoorwaarden zijn het waardevolle deel. Elke stap die iets schrijft, neemt de exacte waarden mee waarop hij bij het plannen vertrouwde: de versie van de order, de kredietstatus, een hash van het adres. Vlak voor de uitvoering vergelijkt hij die met het actuele record. Niets veranderd: hij gaat door. Iets veranderd in een veld dat de stap niet gebruikt: hij gaat door en legt het verschil vast. Iets veranderd in een veld waar hij op steunt: hij stopt en stuurt het geval terug naar de planning, met beide versies zichtbaar voor een medewerker.

In de systemen die wij hebben beoordeeld, leiden verouderde plannen tot meer foute schrijfacties dan foute redeneringen. In tests blijven ze bovendien onzichtbaar, omdat testdata nooit verandert terwijl de agent aan het nadenken is.

Voor stamgegevens geldt hetzelfde. Een agent die voor de snelheid een eigen kopie bijhoudt, werkt vroeg of laat met verouderde gegevens. Hij leest de actuele waarden op het moment dat een stap ze nodig heeft.

De context bij elke stap opnieuw opbouwen kost echt iets als een geval lange documenten meeneemt: een contract, een prijslijst, een aanbesteding van honderd pagina's. De oplossing is om te cachen wat eruit is afgeleid, zoals een uitgelezen tabel of een samenvatting van de voorwaarden, met de versie van de bron als sleutel en nooit het gesprek. Verandert de bron, dan verandert de sleutel en is de cache niet meer geldig. Zo komt de snelheid terug zonder dat de context een opslag wordt.

Geheugen dat beslissingen beïnvloedt, is een bedrijfsregel

Agents die lang doorlopen, krijgen steeds vaker een geheugen: samenvattingen van eerder werk, opgeslagen om later terug te halen. Het engineeringartikel van Anthropic over context engineering (september 2025) beschrijft gestructureerde notities en compaction voor lange taken, en voor agents die onderzoek doen of code schrijven is dat verstandig.

Zakelijke beslissingen vragen om een strengere grens. Heeft een agent geleerd dat een leverancier altijd per pallet factureert terwijl de inkooporder in dozen telt, dan verandert dat feit hoe toekomstige facturen worden gematcht. Hoe het framework het ook noemt, het is een bedrijfsregel. Het wordt daarom vastgelegd als een expliciet record: het feit, het geval waar het uit voortkomt, wie het heeft bevestigd en wanneer het vervalt. Een financieel analist kan het lezen, corrigeren of verwijderen. Geheugen dat niemand kan inzien, zoals embeddings van oude gesprekken die gedrag verschuiven op een manier die niemand aan een auditor kan uitleggen, mag geen zakelijke beslissing beïnvloeden.

Waar het bedrijf onthoudt

State op deze manier scheiden kost ontwerptijd voordat de agent iets indrukwekkends laat zien, en teams die snel moeten demonstreren, slaan die stap over. De demo werkt toch, omdat demo's kort zijn, één gebruiker hebben en nooit worden herstart. Het loont zich in productie: de agent kan op elk moment worden gestopt, twee mensen die naar hetzelfde geval kijken, zien dezelfde geschiedenis, en als het model volgend jaar wordt vervangen, verandert er niets aan de state, omdat die nooit in het model zat.

In de context denkt de agent. In het dossier onthoudt het bedrijf.