De Loop

01

Waarom dit, waarom nu

Vraag een AI-systeem om een zin over het retourbeleid en er komt een zin uit. Vraag hetzelfde systeem om een retour te verwérken, en er moet iets anders gebeuren: het account nakijken, het beleid lezen, de regel toepassen, het bedrag bevestigen, en pas daarna handelen, met een manier om te merken dat er iets niet klopt en het opnieuw te doen.

Dat verschil is waar dit dossier over gaat. Twee jaar lang was het populaire beeld van AI een chatvenster: typ een vraag, lees een antwoord. Dat beeld is inmiddels het belangrijkste wat teams tegenhoudt. De systemen die in 2026 echt werk doen, antwoorden niet één keer. Ze draaien een lus, halen op wat ze nodig hebben, handelen, controleren het resultaat, en gaan opnieuw tot het werk af is.

Het chatvenster leerde iedereen om AI te zien als een automaat: prompt erin, uitvoer eruit, klaar. Dat werkt voor één vraag en valt uit elkaar zodra een taak meer dan één stap heeft, gereedschap nodig heeft, of niet alleen plausibel maar juist moet zijn.

De verschuiving heeft een korte geschiedenis waar het vakgebied het grotendeels over eens is. Eerst kwam de winst uit het model zelf, uit grotere gewichten en meer training. Daarna uit context, oftewel wat je een bevroren model voorzet. Nu komt ze uit de harness, de machinerie rond het model die het laat handelen en zichzelf laat corrigeren. Deze serie van vijf delen is een veldhandleiding voor die machinerie, en ze begint hier omdat de lus het atoom is waaruit al het andere is opgebouwd.

02

1. Waarom nu: het atoom van AI-werk

Het chatvenster leerde iedereen het verkeerde denkbeeld aan. Het liet AI aanvoelen als een automaat, en de teams die er in 2026 echte waarde uit halen hebben dat beeld weggegooid en vervangen door een lus die doorgaat tot het antwoord standhoudt.

Waarom nu is simpel genoeg. Het gereedschap maakt lussen eindelijk vanzelfsprekend, want agents die plannen en gereedschap aanroepen en tests draaien en het opnieuw proberen zijn geen onderzoeksdemo meer maar zitten in producten die mensen dagelijks gebruiken. En het bewijs is bijgetrokken, want systemen die hetzelfde model houden maar het in een betere lus wikkelen, verslaan inmiddels systemen met een sterker model en geen lus.

Eén verduidelijking voordat we verdergaan, want het woord "agent" wordt losjes gebruikt. Een agent is geen bijzonder soort model. Het is een model dat in een lus is gezet, met gereedschap om mee te handelen en een manier om zijn eigen resultaten te controleren. Hetzelfde model dat een chatbericht beantwoordt, wordt een agent op het moment dat je het in ophalen, handelen en controleren wikkelt en het meer dan één keer laat draaien. Gaat deze serie dus over goede agents bouwen, dan gaat ze eigenlijk over goede lussen bouwen rond gewone modellen.

03

2. Vragen-en-ontvangen tegenover de lus

De twee staan het scherpst naast elkaar. Eén API-aanroep is vragen-en-ontvangen: één prompt erin, één antwoord eruit, geen geheugen, geen gereedschap, geen controle. Wat eruit komt, hou je, goed of fout. Nuttig, en scherp begrensd.

Een lus verschilt daarvan in soort. Hij haalt de context op die de stap nodig heeft, handelt door gereedschap aan te roepen of een echte actie te doen, en verifieert het resultaat tegen een test of een beoordelaar. Faalt de controle, dan draait het geheel opnieuw met wat er zojuist geleerd is. Die herkansing bij falen, met bijgewerkte context, is het hele verschil tussen een API aanroepen en een agent draaien.

Een concrete taak maakt het zichtbaar: zoek de drie klanten met het grootste opzegrisico deze maand en schrijf voor elk een mail. Als losse prompt heeft het model geen data, dus verzint het plausibele namen en generieke mails, zelfverzekerd en waardeloos. Als lus bevraagt het de echte gebruiksdata, rangschikt het de accounts, toetst het elk aan de definitie van risico, haalt het de historie van elke klant op, schrijft het een mail die op die historie gegrond is, en markeert het de gevallen waar het onzeker over is voor een mens. Hetzelfde model, een totaal andere uitkomst, omdat de lus het ophalen en handelen en controleren deed dat één aanroep niet kan.

04

3. De drie fasen: ophalen, handelen, verifiëren

De lus heeft drie fasen, en ze benoemen maakt de rest van deze serie leesbaar.

Ophalen verzamelt alles wat het model nu nodig heeft: de relevante context, het geheugen van wat er eerder gebeurde, het juiste gereedschap. Handelen draait het model en laat het iets doen, of dat nu gereedschap aanroepen is of een bestand schrijven of doorgeven aan een subagent. Verifiëren controleert de uitvoer voordat die meetelt, met een test of een tweede model als beoordelaar of een verse ronde. En dan, bij falen, opnieuw.

Twee van de vijf delen in deze serie leven vrijwel volledig binnen Ophalen: context engineering gaat over wat erin gaat, en de harness is de machine die het samenstelt. De andere delen gaan over Handelen en Verifiëren.

De reden om deze drie woorden te leren, is dat ze elk AI-systeem dat zich misdraagt diagnosticeerbaar maken. Een agent die hallucineert heeft meestal een probleem bij Ophalen, want hij kreeg de feiten niet aangereikt die hij nodig had. Een agent die het verkeerde doet, heeft een probleem bij Handelen: slecht gereedschap of onduidelijke instructies. Een agent die zelfverzekerd fouten uitlevert, heeft een probleem bij Verifiëren, want niets keek zijn werk na. Naar onze ervaring is vrijwel elke storing in de praktijk een van die drie fasen die ontbreekt of slecht gedaan is. Ik ben dat gaan aanhouden als eerste diagnosevraag, en tot nu toe is er zelden een vierde oorzaak nodig geweest.

05

4. Een lus, stap voor stap gevolgd

Abstracties zijn makkelijk om instemmend bij te knikken en lastig voor te stellen, dus hier draait er een, stap voor stap gevolgd. De taak is gewoon: een agent moet een falende test in software repareren.

Stap één is ophalen: lees de falende test en de twee bestanden die hij raakt. Stap twee is handelen: schrijf een eerste reparatie. Stap drie is verifiëren: draai de tests, en twee van de twaalf falen nog. Niet klaar dus, en de lus gaat opnieuw met wat er net geleerd is. Stap vier is ophalen: lees de precieze foutmeldingen van die twee. Stap vijf is handelen: pas de reparatie aan zodat ze het randgeval afvangt. Stap zes is verifiëren: draai de tests, en alle twaalf slagen. Klaar.

Niets daaraan is slim, en dat is precies het punt. De agent had de reparatie niet in één keer goed, net zomin als een mens dat zou hebben. Wat hem deed slagen was geen genialiteit maar de lus: stap drie faalde, en in plaats van de kapotte reparatie uit te leveren merkte het systeem de fout op, voerde het de foutmeldingen terug, en probeerde het opnieuw. Eén prompt was bij stap twee gestopt, met een plausibele reparatie die niet werkte.

Dat is het overdenken waard, want het keert een gangbare intuïtie om. Mensen nemen aan dat een betrouwbaarder AI-systeem een slimmer model nodig heeft, terwijl het vaak gewoon een lus met een echte controle nodig heeft, zodat er de eerste keer naast zitten te overleven valt in plaats van definitief te zijn. Hetzelfde spoor zou er bijna identiek uitzien voor een marketingagent die zijn tekst aan de merkregels toetst, of een financiële agent die een factuur tegen een inkooporder legt. Ophalen, handelen, verifiëren, herhalen. Het domein verandert en de vorm niet.

06

5. Verifiëren is de fase die iedereen overslaat

Als één fase een demo van een systeem scheidt, is het Verifiëren, en het is precies de fase die wordt overgeslagen. Een lus zonder controle is een snellere manier om zelfverzekerd fout te zitten: het model produceert iets plausibels, niets toetst het, en de fout gaat de deur uit.

De opzegmail-agent uit sectie twee, gebouwd zonder verificatiestap, laat zien wat dat kost. Hij bevraagt de data, rangschikt de accounts, en schrijft drie mails, waarvan er één opgewekt een korting aanbiedt die het bedrijf helemaal niet geeft, omdat het model gegokt heeft. Niets toetste dat aanbod aan de echte prijslijst, dus de mail gaat weg en het bedrijf heeft iets beloofd dat het niet zal waarmaken. Voeg één verificatiestap toe, waarin elk aanbod in het concept tegen de actuele prijslijst wordt gelegd en alles wat niet matcht wordt gemarkeerd, en de fout wordt gevangen voordat hij het pand verlaat. Het model werd niet slimmer. De lus kreeg een controle.

Daarom zijn de lus en de eval twee kanten van één idee: je kunt niet doorlussen tot het klopt zonder een manier om te weten wat kloppen ís. De teams die betrouwbaar werk uit AI halen, zijn zelden de teams met de slimste prompts. Het zijn de teams die vooraf hebben vastgelegd hoe de lus weet dat hij klaar is: de test die moet slagen, de regel die moet gelden, het tweede model dat akkoord moet geven.

07

6. De lus die zichzelf verbetert

Het duidelijkste bewijs dat de lus en niet het model het werk doet, komt van systemen die verbeteren terwijl het model eronder gelijk blijft.

De Darwin Godel Machine van Sakana is een agent die zijn eigen code herschrijft. Hij werkt in een lus: stel een verandering aan jezelf voor, test de veranderde versie op een codeerbenchmark, houd de verandering als hij beter scoorde, herhaal. Over 80 ronden klom hij volgens het paper van 20 naar 50 procent op SWE-bench en van ongeveer 14,2 naar 30,7 procent op een tweede benchmark, alles op hetzelfde basismodel. Onderweg bedacht hij verbeteringen die een mens met de hand had kunnen toevoegen, waaronder beter gereedschap om bestanden te bewerken, een stap die zijn eigen patches valideert en een manier om eerdere fouten niet te herhalen. Hij bedacht ze omdat de lus beloonde wat hoger scoorde.

AlphaEvolve van DeepMind draait dezelfde vorm van lus op algoritmen in plaats van op zichzelf: genereer veel kandidaat-oplossingen, beoordeel elk automatisch, houd de winnaars, laat die de volgende generatie voortbrengen. Gericht op Googles eigen infrastructuur vond het echte verbeteringen in de planning van datacenters en in chipontwerp, en ontdekte het een snellere kernel die ongeveer één procent van de trainingstijd van het model eronder afhaalde. Dat laatste cijfer is het waard om precies te noemen in plaats van dramatisch, want "de AI versnelde zijn eigen training" is een veel grotere claim dan een besparing van één procent op de totale tijd door één matrixvermenigvuldigingskernel.

Geen van beide systemen kreeg een slimmer model. Elk kreeg een lus die zijn eigen werk controleert en itereert, wat waarschijnlijk het beste beschreven is als recursieve zelfverbetering in gemeten en beheerste vorm, en die draait al.

08

7. Plannen, handelen, waarnemen, reflecteren

Wie inzoomt op één ronde van de lus ziet een kleiner patroon opduiken: plannen, handelen, waarnemen, reflecteren. De agent hakt een doel in stappen, neemt er één, leest wat er gebeurde, en bepaalt wat er nu moet. Magentic-One van Microsoft maakte dat expliciet met een orkestrator die na elke stap dezelfde korte lijst vragen stelt: is de taak af, is het team aan het rondjes draaien of zichzelf aan het herhalen, wordt er voortgang geboekt, wie moet nu handelen, en wat moet die doen.

Die vijf vragen zijn het stelen waard, ook voor wie nooit een regel code schrijft, want het zijn precies de vragen die een goede projectleider stelt. Denkbeeldig geval: een agent die een markt onderzoekt. Na elke zoekopdracht hoort hij zich af te vragen of hij genoeg heeft om de vraag te beantwoorden, of hij dezelfde bronnen aan het herlezen is, of hij werkelijk dichterbij komt of rondjes draait, en wat de nuttigste volgende zoekopdracht is. Een agent die dat doet, blijft vooruitgang boeken. Een agent die dat niet doet, roept ofwel te vroeg de overwinning uit en stopt bij het eerste plausibel ogende antwoord, ofwel blijft eindeloos bijna identieke zoekopdrachten herhalen zonder het te merken. Een lus zonder reflectiestap drijft af.

09

8. Lussen in lussen

Echte systemen zijn niet één lus maar lussen in lussen. De codeer-agent uit sectie vier laat het zien: er is een buitenste lus om de functionaliteit te bouwen, en daarbinnen een binnenste lus voor elk klein stuk, een functie schrijven en de test draaien en repareren en opnieuw draaien, voordat de buitenste lus verdergaat. Magentic-One beschreef precies dat, een buitenste besturingslus voor de hele taak en een binnenste voor elke stap.

Dat doet ertoe voor hoe je over schaal denkt. Eén reuzenlus ontwerpen die alles tegelijk doet is de manier om een agent te krijgen die niemand kan debuggen en die zich elke run anders gedraagt. Beter is een kleine lus die één ding betrouwbaar doet, controleren dat hij werkt, en hem dan wikkelen in een grotere lus die er veel aanstuurt. Een documentverwerkend systeem heeft misschien een binnenste lus die de gegevens uit één factuur betrouwbaar haalt, gewikkeld in een buitenste lus die hem over tienduizend facturen draait en de gevallen afhandelt die falen. Het vierde deel van deze serie gaat volledig over dat wikkelen. Voor nu telt dat de lus stapelt: krijg één kleine lus goed, en het grote systeem is uit kopieën ervan te bouwen.

10

9. De lus sluiten in een bedrijf

Tot hier is dit techniek. Nu de versie die bepaalt of AI in de resultaten opduikt. De meeste zakelijke AI-pilots blijven steken, en de reden lijkt meestal te zijn dat het open lussen zijn: een indrukwekkende demo die een losse prompt beantwoordt, met niets dat terugstroomt en niets dat de uitvoer controleert. Het maakt indruk in de zaal en gaat daarna nergens heen.

Een gesloten lus heeft drie delen, aldus Exponential View: een echt signaal dat vanuit het bedrijf binnenkomt, een operationele graaf die de relaties bevat die de agent nodig heeft, en een afgebakende scope voor waarop hij mag handelen, met een controle die de lus sluit voordat hij opnieuw draait. Dit is een raamwerk en geen gemeten bevinding, en we gebruiken het omdat het overeenkomt met wat we zien, niet omdat iemand het heeft gekwantificeerd.

Het verschil is met één voorbeeld te zien. Open, de pilot die blijft steken: een team bouwt een chatbot die "vragen over facturen kan beantwoorden". Hij demonstreert prachtig. Niets voert hem echte facturen, niets handelt op zijn antwoorden, en na het applaus gebruikt niemand hem. Gesloten, de versie die zich terugverdient: elke binnenkomende factuur is het signaal. De agent leest hem, legt hem naast de inkooporder en de ontvangstregistratie, zijn operationele graaf, en keurt hem goed voor betaling als die drie overeenkomen en het bedrag onder een vastgestelde grens ligt. Alles wat niet matcht of boven de grens uitkomt, gaat naar een mens. Hij draait op elke factuur, leert van de uitzonderingen, en duikt in de cijfers op als dagen bespaarde financiële tijd per week.

De praktische instructie die daaruit volgt is bijna saai. Niet jagen op een brede, open AI-capaciteit, maar één strak afgebakende lus kiezen, er een echt signaal in bedraden, hem een eigenaar en een controle geven, en hem sluiten. Een demo is een open lus en waarde is een gesloten.

11

10. De autonomiegrens

Het beeld van de gesloten lus bevat het nuttigste bestuursidee in agentische AI: de autonomiegrens. Niet elke actie binnen de lus hoort door de machine alleen te worden genomen, en of de agent handelt of escaleert zou van drie dingen moeten afhangen: de waarde die op het spel staat, de zekerheid over het antwoord, en de omkeerbaarheid van de actie.

Van boven naar beneden gelezen tekent de regel zichzelf. Lage waarde, hoge zekerheid, makkelijk ongedaan te maken: laat de lus zelfstandig draaien. Hoge waarde, minder zekerheid, moeilijk of niet terug te draaien: een mens beslist. Die lijn expliciet trekken, actie voor actie, is wat zelfstandigheid veilig maakt om te geven, en het beantwoordt de angst dat agents op hol slaan. Een goed gebouwde lus heeft geen onbegrensde scope. Hij heeft een grens, en alles daarvoorbij gaat naar een mens.

12

11. De eerlijke tegenwerping

Lussen zijn niet gratis en niet altijd juist, dus drie kanttekeningen. Ten eerste versterkt een lus die goed niet van fout kan onderscheiden de fout in plaats van te convergeren, en itereert hij zelfverzekerd naar het verkeerde antwoord toe, sneller dan één aanroep zou doen. De verificatiestap moet echt zijn, anders maakt de lus het erger. Een lus die zijn werk controleert door hetzelfde model te vragen of het er goed uitziet, krijgt meestal gewoon een zelfverzekerd ja, en dat is verificatietheater.

Ten tweede kosten lussen geld. Elke iteratie is meer tokens en meer tijd, een multi-agent-lus kan een flink budget verbranden voor marginale winst, en soms is één goed gerichte aanroep werkelijk het juiste gereedschap voor een simpele taak. Het gewicht van de lus afstemmen op de waarde van de taak hoort bij het vak en is geen bijzaak.

Ten derde verhoogt zelfstandigheid de inzet van een slechte controle. Hoe meer een lus vertrouwd wordt om alleen te handelen, hoe meer een zwakke verificatiestap kan aanrichten voordat iemand het merkt, en precies daarom doet de autonomiegrens ertoe. Niets hiervan pleit tegen de lus. Het pleit ervoor de lus met dezelfde zorg te bouwen als het model: een echte controle, een begrensde scope, en kosten waar werkelijk naar gekeken is.

13

12. Wat een bedrijf hiermee doet

Voor een bestuurder is de les niet om agents te gaan bouwen. Het is een bril voor elk AI-initiatief in het gebouw. Is dit een open lus of een gesloten? Stroomt er een echt signaal in? Is er een verificatiestap, en bezit iemand die? Waar ligt de autonomiegrens? De meeste vastgelopen pilots zakken op een van die vragen, en benoemen wélke is meestal de oplossing. Een pilot die vragen beantwoordt maar nooit handelt, is een open lus. Een pilot die iedereen mooi vindt in de demo maar niemand gebruikt, mist een echt signaal. Een pilot die af en toe een gênante fout uitlevert, mist een verificatiestap.

Dit is See, Understand, Adopt toegepast op de basiseenheid van AI. Zien of wat er ligt een demo is of een lus. Begrijpen wat de drie fasen zijn en waar het eigen proces breekt, wat vrijwel altijd bij Verifiëren is. En dan adopteren door één lus goed te sluiten in plaats van er tien te openen: één taak met hoge frequentie en een strakke afbakening, of dat nu factuurmatching is of ticket-triage of leadscoring, het echte signaal erin bedraad, een echte controle erbij, de autonomiegrens getrokken, en dicht. Eén gesloten lus die elke dag draait verslaat tien open demo's die één keer indruk maakten.

De zet: stop met prompts beoordelen en begin met lussen ontwerpen. Eén strak afgebakende taak met hoge frequentie; een echt signaal erin; een echte controle zodat de lus weet wanneer hij klaar is; de autonomiegrens getrokken, actie voor actie; en dicht. Eén gesloten lus verslaat tien open demo's.

14

13. Verantwoording en bronnen

Dit dossier steunt op live webresearch en een persoonlijk archief van ruim 15.000 bronnen. Dragende cijfers zijn waar mogelijk gecontroleerd. De uitgewerkte voorbeelden en sporen zijn illustratief, gemaakt om de mechaniek uit te leggen en niet om een specifiek systeem te beschrijven. De notities hieronder geven per claim het vertrouwen en de belangrijkste voorbehouden, in de geest van ons uitgangspunt: laat zien hoe je eraan gekomen bent.

De ingekaderde figuur in dit dossier komt uit publiek geplaatst materiaal en is in het bijschrift aan de oorspronkelijke bron toegeschreven. Grafieken met het label "BFF" zijn van ons, getekend naar de bronnen die eronder staan. Sporen en scenario's zijn illustratief, geschreven om het idee uit te leggen.

Back From the Future · BFF Inzichten · Werken met AI · Deel 1 van 5 · juli 2026