De run is de eenheid van governance: waarom durable execution onder elke agent hoort

Veldnotities agentplatform, vijf van acht. Notities twee en vier leunden allebei op een woord dat ik nog niet heb gedefinieerd: de run. Deze notitie gaat over waarom dat woord zoveel gewicht draagt, en welke engines het kunnen dragen.

De vraag

De meeste agentframeworks modelleren een gesprek. Berichten gaan erin, berichten komen eruit, tussendoor worden tools aangeroepen. Voor een chatbot is dat prima. Het valt uit elkaar zodra een gemeente drie vragen stelt die elk gereguleerd proces uiteindelijk stelt:

• Waar is dit stuk werk nu precies, en wie wacht op wie?
• Toen de mens goedkeurde, in welke staat was het werk toen, en is dat sindsdien veranderd?
• Kunnen we het stoppen, nu meteen, en weten dat het gestopt is?

Een gesprek kan die vragen niet beantwoorden. Een run wel. De ontwerpbeslissing in deze notitie is dus: elke agentactie wordt uitgevoerd als een duurzame, inspecteerbare run, en de run, niet het gesprek en niet de agent, is de eenheid die de governor toelaat, goedkeurt, van bewijs voorziet en annuleert.

Een gesprek onthoudt wat er is gezegd. Een run onthoudt wat er is gedaan. Rechters, auditors en inwoners hebben nog nooit om het eerste gevraagd.

Wat een run moet zijn

Voordat ik een engine koos, heb ik opgeschreven wat de run moet kunnen, want dat is wat ik zou kopen.

Hij moet overleven. Een crash, een deploy, een node die verdwijnt, een modelprovider met een time-out: de run hervat vanaf zijn laatst voltooide stap, niet vanaf het begin, en voert een voltooide stap nooit twee keer uit. Een e-mail aan een inwoner opnieuw versturen omdat een pod herstartte, is geen randgeval; het is het eerste incident dat je krijgt.

Hij moet zo lang kunnen pauzeren als een mens nodig heeft. Goedkeuring in een gemeente is geen pop-up van dertig seconden. Een leidinggevende kan met verlof zijn. De run moet duurzaam wachten, dagen als het moet, en alleen de exacte planrevisie hervatten die werd goedgekeurd. Is er tussendoor iets veranderd, dan is de goedkeuring verouderd en moet de run opnieuw vragen.

Hij moet inspecteerbaar zijn zonder aangeraakt te worden. Een auditor, een beheerder en de betrokken persoon moeten elk kunnen zien waar de run is en wat hij heeft gedaan, via een weergave die hem niet kan veranderen.

Hij moet annuleerbaar zijn, en annulering moet een feit zijn, geen verzoek. Compensatie voor al uitgevoerde acties hoort bij de levenscyclus van de run zelf, niet bij de nazorg.

En elke stap moet een record achterlaten waarvan volgorde en inhoud vastliggen: welk beleid is geëvalueerd, wat het model voorstelde, welke tool is uitgevoerd, wie goedkeurde, wat er terugkwam.

Die lijst is de specificatie van een durable-execution-engine, met governancewoorden erin.

De drie engines

Ik heb drie families diepgaand beoordeeld en de rest van het veld eromheen geplaatst.

Temporal is de event-sourced gevestigde naam. Elke beslissing die een workflow neemt, wordt aan een historie toegevoegd, en een worker speelt die historie opnieuw af om de state na elke storing te reconstrueren. De server is Go en draait op Postgres, MySQL of Cassandra; de SDK’s dekken Go, Java, TypeScript, Python en .NET. Voor de run zoals hierboven gedefinieerd, is de eventhistorie het bewijs van wat er gebeurde, in volgorde, zonder extra werk. Worker versioning, nieuw in 2026, pint lopende workflows vast aan de workerversie die ze startte, wat het probleem “we hebben midden in een run gedeployd” oplost dat anders goedkeuringen breekt. De prijs is operationeel: het is een cluster om te beheren, en de historie is krachtig maar niet iets wat een casemedewerker leest.

DBOS neemt de tegenovergestelde positie: duurzaamheid als rijen in Postgres, verder niets te beheren. Annoteer een functie als workflow en zijn stappen, en de library slaat de voortgang op in de database die je al hebt. Exactly-once-uitvoering van stappen, queues, planning en workflow-versioning komen mee. Voor een gemeente die al Postgres draait en geen extra control plane wil, is dit aantrekkelijk, en het duurzaamheidsrecord staat in dezelfde database als alles waar de auditor naar zal kijken. De prijs is dat de engine de library binnen je proces is; de discipline is aan jou.

Restate is een Rust-runtime met durable execution, durable promises en timers, en consistente state per entiteit in één engine. Het is de meest natuurlijke keuze voor de eis “een week pauzeren voor een mens”, omdat een durable promise precies dat is: een waarde waarop de run wacht en die alles overleeft. Het is ook de jongste van de drie in productiegebruik.

De beslissing die ik nam is minder interessant dan het criterium. Elk van de drie kan de run dragen. Wat geen van de drie kan, is beslissen wat de run mag doen. De engine garandeert dat stap vier na stap drie komt en dat stap drie nooit twee keer gebeurt. Hij heeft geen mening over of stap vier toegelaten had mogen worden. Dat blijft het werk van de governor, en daar heb ik het gelaten: de engine voert een toegelaten run uit, de governor laat hem toe, en de historie van de engine voedt het hash-chained bewijsrecord dat de governor schrijft, maar vervangt het niet.

Twee gevolgen die mensen onderschatten

Durable execution maakt menselijk toezicht echt in plaats van theater. Artikel 14 van de EU AI Act vraagt om menselijk toezicht dat effectief is, niet decoratief. Het verschil, in de praktijk, is of de mens zo lang mag doen als nodig is, precies kan zien wat hij goedkeurt, en het systeem kan laten wachten. Een gespreksmodel kan dat niet bieden. Een durable run wel, en het override-percentage over runs heen wordt een meetbaar getal, en dat is de enige manier die ik ken om te bewijzen dat toezicht plaatsvindt.

Durable execution verandert wat “stop” betekent. Op een gespreksmodel betekent een agent stoppen: hopen dat de loop een vlag controleert. Op een durable run is annulering een event in de historie, zijn compensatiestappen zelf duurzaam, en is “het is gestopt” iets wat je aan een auditor kunt laten zien.

Wat ik nog niet kan bewijzen

Prototypeniveau. Mijn platform draait op een van de drie en de demo’s oefenen pauzeren, hervatten, annuleren en compenseren. Wat nog niet is gebeurd: een goedkeuringswachttijd van een week over een workerversie-upgrade in productie heen, of een annulering tijdens een half voltooide compensatie met een echt downstream-systeem aan de andere kant. Dat zijn de gevallen die mij zullen leren of het runmodel standhoudt.

Wat je hiermee doet

Heeft je agentplatform geen durable run, vraag dan wat de mens goedkeurt. Is het eerlijke antwoord “een bericht in een gesprek”, dan heb je geen menselijk toezicht; dan heb je een chat met een pauzeknop. Zet er een engine onder voordat je er een inwoner voor zet.

Volgende notitie: evaluatie- en guardrail-tooling, en het verschil tussen wat je kunt bewijzen en wat je alleen kunt hopen.

Tijd in een gesprek is wibbly-wobbly, timey-wimey. Tijd in een run is een volgnummer. Auditors geven, anders dan de Doctor, de voorkeur aan het volgnummer.

Verwijzingen

De knipogen en citaten in dit stuk, met hun herkomst:

• Doctor Who, “Blink” (BBC, 2007): “wibbly-wobbly, timey-wimey”.