Iedereen optimaliseert de prompt. De teams die winnen optimaliseren de loop.

1. Waarom nu: de atoom van AI-werk

Het chatvenster leerde iedereen het verkeerde mentale model. Het liet AI voelen als een verkoopautomaat: stop een prompt erin, krijg een output. De teams die in 2026 echte waarde halen gooiden dat model weg en vervingen het door een loop die doorgaat tot het antwoord standhoudt.

Waarom nu is simpel. De tools maken loops eindelijk native. Agents die plannen, tools aanroepen, tests draaien en opnieuw proberen zijn geen research-demo meer; ze zitten in de producten die mensen dagelijks gebruiken. En het bewijs is bijgetrokken: systemen die hetzelfde model houden maar het in een betere loop wikkelen verslaan nu systemen met een sterker model en geen loop. Dat ene feit herordent hoe een bedrijf over AI-adoptie zou moeten denken, en daar begint deze handleiding.

Eén verduidelijking voordat we verdergaan, want het woord "agent" wordt losjes rondgestrooid. Een agent is geen speciaal soort model. Het is een model dat in een loop is geplaatst, tools heeft gekregen 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 verzamelen, handelen, verifiëren wikkelt en meer dan één keer laat draaien. Dus als deze serie het heeft over goede agents bouwen, gaat het eigenlijk over goede loops bouwen om gewone modellen heen. Dat is de hele truc, en de rest van dit dossier gaat over hoe de truc werkt.

2. Vragen-en-ontvangen versus de loop

Zet de twee naast elkaar. Een enkele API-aanroep is vragen-en-ontvangen: één prompt erin, één antwoord eruit, geen geheugen, geen tools, geen controle. Je houdt wat er terugkomt, goed of fout. Nuttig, en scherp begrensd.

Een loop is wezenlijk anders. Ze verzamelt de context die de stap nodig heeft, handelt door tools aan te roepen of een echte actie te nemen, en verifieert het resultaat tegen een test of een beoordelaar. Als de controle faalt, draait het geheel opnieuw met wat het net leerde. Die herhaling, bij falen, met bijgewerkte context, is het hele verschil tussen een API aanroepen en een agent draaien.

Neem een concrete taak: "vind de drie klanten met het hoogste risico om deze maand op te zeggen en schrijf voor elk een e-mail." Als een enkele prompt heeft het model geen data, dus verzint het plausibele namen en generieke e-mails, zelfverzekerd en nutteloos. Als een loop bevraagt het de echte gebruiksdata, rangschikt het de accounts, checkt het elk tegen de definitie van "risico", haalt het de historie van elke klant erbij, schrijft het een e-mail gegrond in die historie, en markeert het de gevallen waar het onzeker over is voor een mens. Hetzelfde model, een totaal andere uitkomst, want de loop deed het verzamelen, handelen en controleren dat een enkele aanroep niet kan. Daarom kan een loop werk afmaken dat een enkele aanroep nooit kon.

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

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

Verzamelen brengt alles bijeen dat het model nu nodig heeft: de relevante context, het geheugen van wat er eerder gebeurde, de juiste tools. Handelen draait het model en laat het iets doen, een tool aanroepen, een bestand schrijven, doorgeven aan een sub-agent. Verifiëren controleert de output voordat die telt, met een test, een tweede model als beoordelaar, of een verse doorgang. Dan, bij falen, herhalen.

Twee van de vijf delen in deze serie leven bijna volledig binnen Verzamelen: context engineering is hoe je bepaalt 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 je elk AI-systeem dat zich misdraagt laten diagnosticeren. Een agent die hallucineert heeft meestal een Verzamel-probleem: hij kreeg de feiten niet aangereikt die hij nodig had. Een agent die het verkeerde doet heeft een Handel-probleem: slechte tools of onduidelijke instructies. Een agent die zelfverzekerd fouten shipt heeft een Verifieer-probleem: niets controleerde zijn werk. Bijna elke fout in de praktijk is een van die drie fasen die ontbreekt of slecht gedaan is.

4. Een loop, stap voor stap getraceerd

Abstracties zijn makkelijk om instemmend bij te knikken en moeilijk om echt voor je te zien, dus hier is een loop die draait, één stap per keer getraceerd. De taak is alledaags: een agent wordt gevraagd een falende test in een stuk software te fixen. Kijk hoe de drie fasen zich herhalen.

Niets hieraan is briljant, en dat is het punt. De agent kreeg de fix niet in één keer goed, precies zoals een mens dat niet zou. Wat het liet slagen was geen briljantie; het was de loop. Stap drie faalde, en in plaats van de kapotte fix te shippen, merkte het systeem de mislukking op, voerde de fouten terug, en probeerde opnieuw. Een enkele prompt zou bij stap twee zijn gestopt met een plausibele fix die niet werkte. De loop ging door tot de tests werkelijk slaagden.

Dit is het waard om bij stil te staan, want het keert een veelvoorkomende intuïtie om. Mensen nemen aan dat een betrouwbaarder AI-systeem een slimmer model nodig heeft. Vaak heeft het gewoon een loop met een echte controle nodig, zodat fout zijn bij de eerste poging te overleven is in plaats van definitief. De trace hierboven zou er bijna identiek uitzien voor een marketing-agent die zijn copy tegen merkregels checkt, of een finance-agent die een factuur tegen een inkooporder afstemt. Verzamelen, handelen, verifiëren, herhalen. Het domein verandert; de vorm niet.

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 de fase die mensen overslaan. Een loop zonder controle is enkel een snellere manier om zelfverzekerd fout te zitten. Het model produceert iets plausibels, niets test het, en de fout gaat mee.

Stel je de opzeg-e-mail-agent uit sectie twee voor, gebouwd zonder verifieerstap. Hij bevraagt de data, rangschikt de accounts, en schrijft drie e-mails, waarvan er één vrolijk een korting aanbiedt die het bedrijf helemaal niet geeft, omdat het model gokte. Niets checkte het aanbod tegen de echte prijslijst, dus de e-mail gaat uit en nu heeft het bedrijf iets beloofd dat het niet zal nakomen. Voeg één verifieerstap toe, "check elk aanbod in de concepttekst tegen de huidige prijslijst, en markeer alles dat niet klopt", en de fout wordt gevangen voordat hij het pand verlaat. Het model werd niet slimmer. De loop kreeg een controle.

Daarom zijn de loop en de eval twee kanten van één idee. Je kunt niet loopen tot het klopt zonder een manier om te weten wat kloppen is. De teams die betrouwbaar werk uit AI halen zijn zelden die met de slimste prompts. Het zijn die welke vooraf hebben vastgelegd hoe de loop weet dat hij klaar is: de test die moet slagen, de regel die moet gelden, het tweede model dat moet goedkeuren. Het laatste deel van deze serie gaat volledig over die controle goed bouwen, want het is het moeilijkste en waardevolste deel van de hele stack.

6. De loop die zichzelf verbetert

Het helderste bewijs dat de loop, en niet het model, het werk doet, komt van systemen die verbeteren terwijl het model eronder vast blijft.

Sakana's Darwin Godel Machine is een agent die zijn eigen code herschrijft. Hij werkt in een loop: stel een wijziging aan zichzelf voor, test de gewijzigde versie op een coding-benchmark, houd de wijziging als die beter scoorde, en herhaal. Over tachtig rondes hiervan klom hij van twintig naar vijftig procent op SWE-bench en van ongeveer veertien naar eenendertig procent op een tweede benchmark, allemaal op hetzelfde foundation-model. Onderweg vond hij verbeteringen uit die een mens met de hand had kunnen toevoegen, betere tools om bestanden te bewerken, een stap die zijn eigen patches valideert, een manier om oude fouten niet te herhalen, en hij vond ze omdat de loop beloonde wat hoger scoorde.

DeepMind's AlphaEvolve draait dezelfde vorm van loop op algoritmes in plaats van op zichzelf: genereer veel kandidaat-oplossingen, evalueer elk automatisch, houd de winnaars, en laat ze de volgende generatie fokken. Gericht op Google's eigen infrastructuur vond het echte verbeteringen aan data-center-scheduling en aan chipontwerp, en het ontdekte zelfs een snellere kernel die ongeveer één procent van de trainingstijd van het model eronder afsneed. Geen van beide systemen kreeg een slimmer model. Elk kreeg een loop die zijn eigen werk controleert en itereert. Dat is recursieve zelfverbetering, in een gemeten en gecontroleerde vorm, die nu al draait, en het is het sterkst mogelijke bewijs voor de claim die dit dossier steeds maakt: de loop is waar de hefboom zit.

7. Plannen, handelen, observeren, reflecteren

Zoom in op één doorgang van de loop en er duikt een kleiner patroon steeds op: plannen, handelen, observeren, reflecteren. De agent breekt een doel in stappen, neemt er één, leest wat er gebeurde, en beslist wat te doen. Microsofts Magentic-One maakte dit expliciet met een orchestrator die na elke stap dezelfde korte lijst vragen stelt: is de taak af, loopt het team in cirkels of herhaalt het zich, wordt er voortgang gemaakt, wie moet nu handelen, en wat moeten ze doen.

Die vijf vragen zijn het stelen waard, zelfs zonder code, want het zijn precies de vragen die een goede projectmanager stelt. Stel je een agent voor die een markt onderzoekt. Na elke zoekactie zou hij moeten vragen: heb ik genoeg om de vraag te beantwoorden? Herlees ik enkel dezelfde bronnen? Kom ik werkelijk dichterbij, of draai ik in cirkels? Wat is de nuttigste volgende zoekactie? Een agent die deze stelt blijft voortgang maken. Een agent die dat niet doet roept ofwel te vroeg de overwinning uit, en stopt bij het eerste plausibel ogende antwoord, ofwel draait eindeloos, en herhaalt bijna-identieke zoekacties zonder het te merken. Een loop zonder reflectiestap dwaalt af. Een loop die vraagt "maak ik werkelijk voortgang", elke keer, is degene die aankomt.

8. Loops binnen loops

Echte systemen zijn niet één loop maar loops genest binnen loops. De coding-agent uit sectie vier laat het zien. Er is een buitenste loop, "implementeer deze feature", en daarbinnen een binnenste loop voor elk klein stuk, "schrijf deze functie, draai zijn test, fix het, draai het opnieuw", voordat de buitenste loop doorgaat naar het volgende stuk. Magentic-One beschreef precies dit: een buitenste control-loop voor de hele taak en een binnenste voor elke stap.

Dit doet ertoe voor hoe je over schaal denkt. Je ontwerpt geen één reuzenloop die alles tegelijk doet; zo krijg je een agent die onmogelijk te debuggen is en zich elke run anders gedraagt. Je ontwerpt een kleine loop die één ding betrouwbaar doet, verifieert dat die werkt, en wikkelt die dan in een grotere loop die er veel van orkestreert. Een document-verwerkingssysteem kan een binnenste loop hebben die betrouwbaar de data uit één factuur haalt, gewikkeld in een buitenste loop die het over tienduizend facturen draait en de mislukte gevallen afhandelt. Het vierde deel van deze serie, workflows en agents, gaat volledig over dat wikkelen, wanneer loops als een vaste reeks te componeren en wanneer een lead-agent ze te laten orkestreren. Voor nu is het punt dat de loop componeert: krijg één kleine loop goed, en je kunt het grote systeem bouwen uit kopieën ervan.

9. De loop sluiten in een bedrijf

Tot nu toe is dit engineering. Hier is de versie die bepaalt of AI in je resultaten opduikt. De meeste bedrijfs-AI-pilots stranden, en de reden is meestal dat het open loops zijn: een indrukwekkende demo die een eenmalige prompt beantwoordt, met niets dat terugstroomt en niets dat de output controleert. Het imponeert in de kamer en gaat daarna nergens heen.

Een gesloten loop heeft drie delen, zoals Exponential View het stelde: een echt signaal dat vanuit het bedrijf binnenstroomt, een operating graph die de relaties bevat die de agent nodig heeft, en een gedefinieerde scope voor waarop hij mag handelen, met een controle die de loop sluit voordat hij opnieuw draait. Het verschil tussen een open en een gesloten loop is het verschil tussen een slimme demo en iets dat een getal verzet.

De praktische instructie die volgt is bijna saai. Jaag niet op een breed, open AI-vermogen. Kies één strak afgebakende loop, sluit er een echt signaal op aan, geef hem een eigenaar en een controle, en sluit hem. Dat verzet een getal. Een demo is een open loop; waarde is een gesloten loop.

10. De autonomiegrens

Het gesloten-loop-beeld bevat het nuttigste governance-idee in agentische AI: de autonomiegrens. Niet elke actie binnen de loop hoort door de machine alleen te worden genomen. Of de agent handelt of opschaalt naar een mens zou moeten afhangen van drie dingen: de waarde die op het spel staat, het vertrouwen in het antwoord, en de omkeerbaarheid van de actie.

Getekend als een simpele tabel, voor de factuur- en retour-agents, ziet het er zo uit:

Lees de tabel naar beneden en de regel tekent zichzelf. Lage waarde, hoog vertrouwen, makkelijk ongedaan te maken: laat de loop op eigen kracht draaien. Hoge waarde, lager vertrouwen, moeilijk of onmogelijk terug te draaien: een mens beslist. Die lijn expliciet trekken, actie voor actie, is wat autonomie veilig maakt om te verlenen, en het beantwoordt de angst dat agents op hol slaan. Een goed gebouwde loop heeft geen onbeperkte scope; hij heeft een grens, en alles voorbij die grens gaat naar een mens. Het laatste deel van deze serie komt hierop terug, want beslissen wat je de machine toevertrouwt is een vaardigheid, geen vinkje.

11. Het eerlijke tegengeluid

Loops zijn niet gratis en niet altijd juist. Drie eerlijke kanttekeningen. Ten eerste: een loop die goed niet van fout kan onderscheiden versterkt de fout in plaats van te convergeren; hij itereert zelfverzekerd naar het verkeerde antwoord sneller dan een enkele aanroep zou. De verifieerstap moet echt zijn, anders maakt de loop het erger in plaats van beter. Een loop die zijn werk "controleert" door hetzelfde model te vragen "ziet dit er goed uit?" krijgt vaak enkel een zelfverzekerd ja, wat verificatie-theater is, geen verificatie.

Ten tweede: loops kosten. Elke iteratie is meer tokens, meer tijd en meer geld. Een multi-agent-loop kan een groot budget verbranden voor een marginale winst, en soms is een enkele goedgerichte aanroep werkelijk het juiste gereedschap voor een simpele taak. Het gewicht van de loop afstemmen op de waarde van de taak is deel van de kunst, geen bijzaak. Ten derde: autonomie verhoogt de inzet van een slechte controle: hoe meer een loop vertrouwd wordt om alleen te handelen, hoe meer een zwakke verifieerstap schade kan doen voordat iemand het merkt, wat precies is waarom de autonomiegrens in de vorige sectie ertoe doet.

Niets hiervan pleit tegen de loop. Het pleit ervoor de loop met dezelfde zorg te bouwen als het model: een echte controle, een begrensde scope, en een kostprijs waar je naar gekeken hebt. De faalmodus van loops is een zwakke controle. Een loop die zijn eigen output niet kan beoordelen doet te veel, te zelfverzekerd.

12. Wat een bedrijf hiermee doet

Voor een leider is de les geen opdracht om agents te gaan bouwen. Het is een lens voor elk AI-initiatief in het gebouw. Vraag van elk: is dit een open loop of een gesloten? Stroomt er een echt signaal in? Is er een verifieerstap, en heeft iemand die in eigendom? Waar is de autonomiegrens getrokken? De meeste gestrande pilots falen op een van die vragen, en benoemen welke is meestal de oplossing. Een pilot die "vragen beantwoordt" maar nooit handelt is een open loop; 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 shipt mist een verifieerstap.

Dit is de See, Understand, Adopt-methode toegepast op de basiseenheid van AI. Zie of het ding voor je een demo of een loop is. Begrijp de drie fasen en waar jouw proces breekt, bijna altijd bij Verifiëren. Adopteer dan door één loop netjes te sluiten in plaats van er tien te openen. Kies één enkele, hoogfrequente, strak afgebakende taak, factuur-matching, ticket-triage, lead-scoring, sluit het echte signaal aan, voeg een echte controle toe, trek de autonomiegrens, en sluit hem. Eén gesloten loop die elke dag draait wint van tien open demo's die één keer imponeerden. De rest van deze serie bouwt van hieruit naar buiten: de harness die de loop draait, de context die hem voedt, de patronen die veel loops componeren, en de verificatie die je ze laat vertrouwen.

13. Verificatie en bronnen

Dit dossier steunt op live webonderzoek en een persoonlijk archief van meer dan 15.000 bronnen. Dragende cijfers zijn waar mogelijk dubbel gecheckt. De uitgewerkte voorbeelden en traces zijn illustratief, gebouwd om de mechaniek uit te leggen en niet om een specifiek genoemd systeem te beschrijven. De noten hieronder markeren vertrouwen en de belangrijkste kanttekeningen, in de geest van ons werk laten zien.

De ingekaderde figuur in dit dossier komt uit publiek geplaatst materiaal, in het onderschrift gecrediteerd aan de oorspronkelijke bron. Grafieken met "BFF" zijn van onszelf, getekend uit de eronder genoemde bronnen. Traces en scenario's zijn illustratief, geschreven om het idee te leren. De grafieklabels zijn in het Engels gehouden zodat termen één op één met de bronnen te vergelijken zijn.