Loop of werkstroom: wie houdt bij jouw AI-agent het plan vast

Een productiefix van twee regels. De fix zelf stond binnen een uur live en geverifieerd. Toch stond de klok pas na twee uur en vijftig minuten stil, over vier iteraties. Die extra twee uur gingen niet naar de fix, maar naar alles eromheen: controleren of het live echt werkte, een usertest over vijf flows, een audit, en de vier bevindingen die daaruit kwamen. Dat staat met tijdstempels in mijn eigen ledger, dus ik kan er niet omheen praten.

Het interessante is wát er verder in dat ledger staat. Geen agent die vrij mocht dwalen, maar een vastgestelde beginstand, een lijst evals die een machine kan afvinken, een taakbord met één eigenaar per bestand, en een reviewgate per stap. De autonomie zat in de uitvoering, het plan lag eromheen.

De tijd ging vervolgens zitten in de naden. Een reviewgate die afkeurde op houding in plaats van op een bug. Een main-branch die intussen drie commits was opgeschoven. Een API-key met de verkeerde scope. En een deploy die al vaststond door een commit van een heel andere feature. Precies de dingen die je vooraf niet in een tak kunt schrijven. Twee jaar geleden vroeg ik me af hoeveel autonomie ik een agent durfde te geven. Nu vraag ik me af op welke plek ik hem zet, en op welke plekken juist niet.

Twee vormen, één verschil

Bij een loop geef je een agent een doel en herhaalt hij zelf rondes tot dat doel gehaald is. Per ronde beslist het model wat de volgende stap is. Jij legt vooraf alleen het doel vast, de grenzen en de stopconditie.

Bij een werkstroom ligt het pad vast, in code of in een schema. Dat bepaalt welke stap wanneer draait. Het model doet nog steeds het werk binnen elke stap, maar het kiest de volgorde niet.

Anthropic formuleerde dat in Building effective agents op de manier die inmiddels de standaard is: werkstromen zijn systemen waarin taalmodellen en tools via vooraf gedefinieerde codepaden worden georkestreerd, agents zijn systemen waarin het model zijn eigen proces en toolgebruik stuurt.

Eén precisering, want de simpele tweedeling klopt niet helemaal. Bij een loop op een vast interval beslist de klok wanneer er een ronde start. Het model beslist dan alleen wat er in die ronde gebeurt. Alleen bij een zelfpacende loop beslist het model allebei.

Het scharnierpunt: wie houdt het plan vast

In de vergelijkingstabel van de Claude Code-documentatie staat het letterlijk als "who decides what runs next". Bij een loop het model, ronde na ronde. Bij een werkstroom het script.

Daar hangt een tweede as onlosmakelijk aan, en die is in de praktijk minstens zo bepalend: waar de tussenresultaten leven. In een loop gaat alles door één contextvenster. Dat schaalt niet naar tientallen werkeenheden. In een werkstroom leven ze in scriptvariabelen en landt alleen het eindantwoord in context.

Twee correcties op die tabel, voordat je hem te hard leest. Het determinisme van een werkstroom zit in de orkestratie, niet in de uitkomst. Een pijplijn over vijftig bestanden garandeert vijftig aanroepen in dezelfde volgorde met dezelfde prompts. Wat elke agent teruggeeft blijft modelgedrag. En het is geen schakelaar maar een schaal. Er zijn tussenvormen waarin het plan half buiten het model ligt, zoals een tweede model dat beoordeelt of het klaar is, of een gedeelde takenlijst op schijf. Anthropic beveelt zelf de hybride vorm aan: eerst inline verkennen om te ontdekken wat het werk is, daarna pas orkestreren.

Vier redenen dat de werkstroom nu wint

1. Niet-determinisme maakt debuggen en meten duur

Anthropic schrijft over het eigen multi-agent onderzoekssysteem dat agents niet-deterministisch zijn tussen runs, zelfs bij identieke prompts. Dat maakt debuggen moeilijker. Voor evaluatie geldt hetzelfde: agents kunnen totaal verschillende, geldige paden nemen, dus je kunt niet controleren of ze de juiste stappen volgden.

En reken er niet op dat temperature 0 je redt. Thinking Machines Lab liet in 2025 zien dat de output ook dan tussen runs wisselt. En dat de gangbare verklaring niet klopt: het komt niet primair door floating point of GPU-parallellisme, maar doordat de batchgrootte bij inferentie varieert. Dat is oplosbaar in de serving-stack, met batch-invariante kernels. Het is alleen niets wat jij aan de aanroepkant in de hand hebt.

2. Fouten stapelen op over lange ketens

Het falen van één stap kan een agent een totaal ander traject in sturen. Kleine systeemfouten worden groot bij runs die lang doorlopen en state vasthouden over veel toolcalls. Empirisch: in TheAgentCompany, de benchmark van CMU met 175 realistische kantoortaken, voltooit de sterkste agent 30 procent van de taken volledig autonoom, bij gemiddeld 27 stappen en ruim 4 dollar per taak. Dat is Gemini 2.5 Pro in de gepubliceerde versie van 2025. In diezelfde tabel staat Claude 3.5 Sonnet op 24 procent bij 29 stappen, dus reken erop dat het cijfer verschuift zodra je het leest. De orde van grootte is wat telt: ruim twee op de drie realistische kantoortaken loopt nog niet vanzelf af.

3. Zonder vast pad heeft de rekening geen bovengrens

Anthropic heeft aan het eigen systeem gemeten dat agents ongeveer 4 keer de tokens van een chatinteractie gebruiken, en multi-agent systemen ongeveer 15 keer. Behandel dat als een meting aan één systeem, niet als natuurconstante. De rem staat in dezelfde tekst. Het loont niet als agents dezelfde context delen of veel van elkaar afhangen. Niet bij het meeste codeerwerk. En niet als de waarde van de taak de meerkosten niet dekt.

Eerlijk erbij: hierboven staat alleen de rekening van de loop. De bouwkosten van de werkstroom staan er niet in, en die zijn reëel. Een pijplijn moet vaak genoeg draaien om het schrijven en onderhouden ervan terug te verdienen. Voor eenmalig werk is dat zelden zo.

4. Verantwoording vraagt om expliciete beslispunten

De EU AI Act eist voor hoog-risicosystemen automatische logging over de levensduur en effectief menselijk toezicht met de mogelijkheid tot ingrijpen. Hoog-risico is geen gevoelskwestie maar een lijst: onder Annex III vallen onder meer cv-selectie, kredietscoring, beslisondersteuning bij handhaving en grenscontrole. Die verplichtingen zouden op 2 augustus 2026 gaan gelden. Ze zijn met de Digital Omnibus on AI verschoven, Verordening (EU) 2026/1744, in werking sinds 27 juli 2026. Nieuwe data: 2 december 2027 voor losstaande systemen, 2 augustus 2028 voor AI die als veiligheidscomponent in een gereguleerd product zit. Dat uitstel kwam er niet omdat de eis onzin bleek, maar omdat de uitvoering niet op tijd rond kwam. De richting verandert dus niet. Je hebt er zestien maanden langer voor, en dat is precies de periode waarin je je architectuur nog kunt kiezen.

Gartner verwacht dat meer dan 40 procent van de agentic-AI-projecten voor eind 2027 wordt geannuleerd, door oplopende kosten, onduidelijke business value of ontoereikende risicobeheersing. Simon Willison noemt drie dingen samen de "lethal trifecta": toegang tot private data, blootstelling aan onvertrouwde inhoud, en externe communicatie. Zijn eigen conclusie erbij: we weten nog niet hoe je dit voor 100 procent voorkomt. Een open loop maximaliseert die drie tegelijk. OpenAI adviseert daarom risicoklassen per tool, op lezen versus schrijven, omkeerbaarheid en financiële impact, en pauzes op basis daarvan.

Waar de markt het over eens is, en waarover niet

Anthropic, Cognition, OpenAI en LangChain schrijven onafhankelijk van elkaar over dezelfde faalmodus: zodra beslissingen over meerdere agents verspreid raken en context onvoldoende gedeeld wordt, gaat het mis. Ze trekken er niet dezelfde conclusie uit. Anthropic bouwt juist mét een lead agent en parallelle subagents. Cognition houdt in Don't Build Multi-Agents schrijfacties expliciet single-threaded, met als argument dat handelingen impliciete beslissingen meedragen die met elkaar in conflict komen. Waar ze elkaar wel vinden: de plek waar het plan en de doorlopende context wonen, moet er één zijn.

Harrison Chase van LangChain vat de praktijk zo samen: hoe agentischer je systeem wordt, hoe minder voorspelbaar, en bijna alle agentische systemen in productie zijn een combinatie van werkstromen en agents. Het zit inmiddels ook in de tooling zelf. In de versie van Claude Code die ik nu draai (2.1.202) gooit de workflowruntime een fout op Date.now(), een kale new Date() en Math.random(). Het argument: ze maken hervatten kapot.

Drie manieren waarop mijn werkstromen stil faalden

Elke tak die je schrijft is een hypothese over hoe de taak eruitziet. Klopt die niet, dan faalt het systeem stil. Drie keer dat mij dat is overkomen.

Geraden buckets. Een orkestrator koos zelf drie skills per team uit een oppervlakkige taxonomie. Dat las als volledige dekking, terwijl er ongeveer driekwart van het onderwerp was afgekapt. Pas toen ik als vakman zei dat het veel te kort was, ging er een onderzoeksronde vóór het vaste plan, en groeide het van 53 naar 208 skills. Laat de orkestrator nooit de inhoud van een bucket raden, en log wat je hebt weggelaten. Precies dezelfde faalmodus staat als hard voorschrift in de eigen workflow-prompt van Anthropic: stille truncatie leest als volledige dekking.

Falen op de naad. Alle stappen groen betekent niet dat het geheel werkt. Twee branches waren allebei groen en braken elkaar op de naad: een backfill zette klant_id zonder klant_slug, terwijl het conversiepad alleen naar de slug keek. Onzichtbaar in beide losse diffs. Een pijplijn van onafhankelijke stappen heeft geen naadcontrole tenzij je die er expliciet in bouwt.

Een groene gate is niet kijken. Twee lints, statisch en gerenderd, misten tien kapotte slides door één CSS-override. Alleen screenshots per slide vonden het. Een lint is geen paar ogen.

En dan het vierde, dat geen faalgeval is maar slijtage: je stellage veroudert sneller dan je model. De formulering komt van het team achter browser-use. Wat je bouwde om de zwaktes van het oude model te compenseren, wordt het ding dat je belet te profiteren van de sterktes van het nieuwe. METR meet dat de taaklengte die frontier-modellen op 50 procent halen exponentieel groeit. In hun herziene reeks van januari 2026 verdubbelt die sinds 2023 ongeveer elke 131 dagen; over de volledige reeks gemeten is het 188 dagen. Bouw je werkstroom dus zo dat je takken eruit kunt slopen.

Wanneer een loop wel het juiste is

• Als het aantal stappen niet vooraf vastligt. Anthropic noemt agents geschikt voor open problemen waar je geen vast pad kunt hardcoderen, mits je uitgebreid test in een sandbox met passende guardrails.
• Als deterministische regels onhoudbaar worden. OpenAI noemt drie triggers: complexe besluitvorming met veel uitzonderingen, regelsets die te duur zijn om te onderhouden, en zwaar ongestructureerde input.
• Als het werk echt parallelliseert en de context niet gedeeld hoeft te worden. De keerzijde staat er expliciet bij: domeinen waarin alle agents dezelfde context nodig hebben of veel onderlinge afhankelijkheden kennen zijn geen goede kandidaat, met codeerwerk als voorbeeld.
• Als de waarde van de uitkomst de tokenkosten ruim overtreft, en de schade beperkt of terug te draaien is.
• En het belangrijkste: als je een goedkoop, betrouwbaar verificatiesignaal hebt. Tests, types, compilers, checkers. Daar kan de loop zichzelf beoordelen, en dat is wat een lange loop economisch maakt.

Wat ik er zelf van maak

Mijn standaardhouding past in één zin. Begin met de werkstroom en zet er één agent-stap in, op precies de plek waar het oordeel zit. Alles eromheen is orkestratie die je kunt lezen, herhalen en aan iemand uitleggen.

De naad tussen die twee is waar het werk in gaat zitten. Laat de agent-stap iets teruggeven waar het script op kan takken, niet een lap proza: een keuze uit een vaste lijst, met de onderbouwing als los veld. En leg vooraf vast wat er gebeurt als hij iets teruggeeft dat er niet in past, want dat gebeurt. Bij mij is dat standaard stoppen en het melden, niet gokken.

En dan dit nog, want het valt in de verhalen over autonome agents meestal weg. In mijn eigen runs levert onbewaakt doorlopen consequent minder op dan bijsturen. Dat is een observatie aan mijn eigen werk, geen meting. Wat lange loops bij mij laat werken is iemand met vakkennis die ingrijpt: specs repareren, het plan opnieuw laten genereren, af en toe hard terugzetten naar de laatste goede staat. Je haalt de mens er niet uit. Je kiest de twee of drie momenten waarop hij er expliciet in staat.