Loop engineering

Wat is loop engineering?

Loop engineering is het ontwerpen van de loop rond een agent in plaats van de prompt erin: wat de agent opnieuw doet vertrekken, wat hij dan te zien krijgt, wat hij mag verbruiken, en welk bewijs er moet liggen voor een run als afgewerkt telt.

Het onderscheid dat de term zijn betekenis geeft, ligt tussen twee loops. De inner loop is het model dat een tool aanroept, het resultaat leest en de volgende stap kiest. Dat is de agent loop, en die werkt intussen goed: de SDK's regelen hem voor jou. De outer loop zit er een niveau boven en beslist of de inner loop opnieuw vertrekt, met welke context, binnen welk budget, en wanneer het definitief gedaan is.

Addy Osmani vatte het in juni 2026 in één zin samen: bij loop engineering vervang je jezelf als de persoon die de agent aanstuurt, en bouw je het systeem dat dat in jouw plaats doet. Zit je zelf de output te lezen en "nee, probeer nog eens" te typen, dan ben jij de outer loop. Loop engineering is opschrijven wat je gezegd zou hebben.

De onderdelen die je zelf ontwerpt

De stopvoorwaarde. Het moeilijkste stuk en meteen ook het stuk dat het vaakst overgeslagen wordt. Een run moet ergens op eindigen, en standaard is dat het model dat een beurt aflevert zonder tool-aanroep, wat neerkomt op zijn eigen mening dat het klaar is. Schrijf de stopvoorwaarde voor je de prompt schrijft: wat moet er waar zijn voor deze run voorbij is? Kan je dat niet beantwoorden zonder het woord "goed" te gebruiken, dan heb je er nog geen.

De controle die ze test. De stopvoorwaarde is de uitspraak, de controle is de code die ze nakijkt, en wat telt is waar die controle staat. Een zin in de prompt die de agent vraagt om zijn eigen werk na te kijken is een suggestie. Een script dat jouw harness draait nadat de agent gestopt is, en waarvan de exit code bepaalt of de agent opnieuw vertrekt, is een stopvoorwaarde.

Wat er van iteratie naar iteratie meegaat. De naïeve outer loop plakt alles aan elkaar, dus tegen de vierde ronde zit het model vooral zijn eigen doodlopende sporen te herlezen. Anthropic beschreef in september 2025 drie manieren om daaronderuit te komen: compaction, waarbij de run samengevat wordt en je van die samenvatting vertrekt; notities die de agent wegschrijft naar een bestand buiten het context window; en sub-agents, die een schone context krijgen en een korte samenvatting terugleveren. De reden is context rot, het feit dat een model minder goed het juiste terugvindt naarmate het venster voller zit. Wat de volgende ronde nodig heeft is het doel, de huidige versie van het werk en de fouten, niet het volledige gesprek.

Een budget in stappen, tokens of geld. Bij agent loop staan de grenzen die de SDK's op één run leggen. De outer loop heeft er daarbovenop eigen nodig, want hij kan de inner loop vele keren opnieuw laten vertrekken. Drie tot vijf rondes voor er een mens naar kijkt is een verstandige standaard. Een loop die na vijf pogingen nog faalt draait rondjes in plaats van te naderen, en die zesde poging kost evenveel als de eerste.

Een uitweg naar een mens. Het Agent Framework van Microsoft behandelt stoppen als een eigen laag, met middleware die een run beëindigt voor het model aangeroepen wordt of nadat het geantwoord heeft. In hun documentatie staat een waarschuwing die het overnemen waard is: stop je midden in een tool-aanroep, dan blijft er in de geschiedenis een aanroep zonder resultaat achter, en daar loopt de volgende run die ze leest op stuk. Spreek dus af wat de agent achterlaat als hij het opgeeft, een bestand met de foute lijnen of een ticket met de laatste fout en de invoer die ze veroorzaakte. "Hij is gestopt" is geen overdracht.

Een opkuisloop met een echte stopvoorwaarde

Een groothandel krijgt elke ochtend een prijsbestand van zijn grootste leverancier binnen: 4.200 artikellijnen plus een samenvattingslijn met het totaal van de leverancier zelf. Voor dat bestand in het ERP mag, moeten vier regels kloppen. Elke artikelcode staat in de interne codelijst, elke prijs leest als een getal in euro, geen enkele code komt twee keer voor, en het totaal van het bestand sluit tot op de cent aan bij dat van de leverancier. Die vier regels zijn samen een validatiescript, en dat script is de stopvoorwaarde: nul afgekeurde lijnen en een aansluitend totaal.

De loop errond is kort. Draai het script. Slaagt het, laad dan het bestand in. Faalt het, geef de agent de afgekeurde lijnen met hun foutmelding, laat hem ze verbeteren en draai het script opnieuw. Na vijf rondes, of zodra twee rondes dezelfde fouten opleveren, schrijf je wat overblijft naar een bestand en mail je de aankoper.

Een gewone ochtend kost drie rondes: eerst 180 afgekeurde lijnen, vooral komma's als decimaalteken en twee codes die de leverancier hernoemd heeft, dan nog 25, dan de laatste drie en het totaal sluit aan. Elke ronde stuurt de vaste instructies mee, zowat 2.000 tokens, plus de afgekeurde lijnen met hun fouten aan ruwweg 40 tokens per lijn. Samen komen die drie rondes op zo'n 14.000 tokens in en 4.000 uit. Aan de gangbare prijs van een middenklassemodel, rond twee dollar per miljoen tokens in en tien per miljoen uit, kost één ochtend minder dan tien cent en blijft een heel jaar onder de twintig euro. De aankoper was er vroeger elke ochtend twintig minuten mee bezig.

Draai nu de versie waarin er niets weggegooid wordt. Stuur het hele bestand elke ronde opnieuw mee en elke ronde weegt zo'n 170.000 tokens in plaats van 9.000, dus drie rondes zijn een half miljoen tokens en een euro per dag, nog voor je de output meetelt. Zelfde resultaat, vijftien keer de rekening, en een model dat 4.200 lijnen leest om er drie te verbeteren.

Een mechanische stopvoorwaarde tegenover het oordeel van het model

Allebei stoppen ze. Wat hen scheidt is welk bewijs de run beëindigt.

Een mechanische stopvoorwaarde eindigt op iets buiten het model: de tests slagen, het bestand valideert, het aantal rijen komt overeen met de bron, de factuur klopt. Het bewijs is een exit code of een getal, het valt elke keer hetzelfde uit, en je legt het zonder blozen aan een revisor voor. De beperking is dat iemand die regel geschreven heeft, dus ze dekt alleen wat ze dekt. Een bestand kan perfect valideren en toch de prijzen van vorige week bevatten.

Het model dat zelf beslist dat het klaar is eindigt op een oordeel over zijn eigen werk, en het bewijs is een zin die dat zegt. Dat rekt tot alles, en daar zit de aantrekkingskracht. Het is ook hetzelfde instrument dat zichzelf beoordeelt, en daar zit het probleem. Osmani zegt het scherp: het model dat de code geschreven heeft is veel te mild als het zijn eigen huiswerk verbetert.

Gebruik dus een mechanische voorwaarde overal waar er een te schrijven valt, en waar je terugvalt op het oordeel van een model, geef dat oordeel aan een tweede agent met andere instructies en een schone context.

Waar moet je op letten bij het bouwen van een loop

De loop roept de overwinning uit. De run eindigt op een zelfzekere samenvatting van wat er allemaal gebeurd is, en niets heeft die samenvatting naast het resultaat gelegd. Deze kost het meest, want ze ziet er exact uit als succes en komt pas weken later boven in een rapport dat niet klopt.

De loop stopt nooit. Als de stopvoorwaarde een oordeel is dat het model over zichzelf velt, is ze meestal altijd waar of nooit waar. Ofwel slaagt de eerste poging en was de loop versiering, ofwel raakt niets eraan voldaan en loopt de run tot aan de grens. Dezelfde ontwerpfout, twee tegengestelde symptomen.

De loop herhaalt dezelfde mislukte stap. Binnen één run gaat dat over foutmeldingen van tools, en dat staat bij agent loop. Over de rondes heen moet de outer loop het opmerken: vergelijk de fouten van deze ronde met die van de vorige, en zijn ze identiek, stuur dan niet dezelfde context terug. Verander de aanpak of escaleer. Gaat er niets nieuws in, dan komt er niets nieuws uit.

Wat een loop niet oplost

Loop engineering maakt een model niet bekwaam in iets waar het niet toe in staat is. Het zet iets wat af en toe lukt om in iets wat betrouwbaar genoeg lukt om te laten draaien.

Het onderzoek is nuchterder dan de verkooppraat. Onderzoekers van Google DeepMind en de University of Illinois gaven hun paper uit 2024 de kale titel "Large Language Models Cannot Self-Correct Reasoning Yet". Ze testten precies de versie waarvan iedereen aanneemt dat ze werkt: laat het model zijn eigen antwoord herlezen en herzien, zonder verdere informatie. Het werd niet beter, en vaak slechter. Van de antwoorden die het model aanpaste, veranderde het vaker een juist antwoord in een fout dan omgekeerd. Verbeteren mét feedback van buiten het model werkte wel. Dat ene resultaat is het argument om de outer loop uit controles op te bouwen in plaats van uit instructies om na te denken.

Daarmee heb je meteen het tegenvoorbeeld. Zet een loop op de herwerking van je herinneringsmail aan leveranciers: de agent schrijft, beoordeelt zijn eigen tekst, herschrijft, vijf keer na elkaar. Wat eruit komt is langer, voorzichtiger en verder van wat je bedoelde, en je hebt vijf versies betaald waar er één volstond. Er was geen score, dus de loop had niets om naartoe te werken.

Twee vragen bepalen of een loop de moeite van het bouwen waard is. Kan een machine je zeggen dat het antwoord juist is? En draait die taak vaak genoeg om de dag die je erin steekt terug te verdienen? Een dagelijks prijsbestand met een controletotaal antwoordt twee keer ja. Een jaarlijkse aangifte die iemand in tien minuten nakijkt zegt nee op de tweede, hoe mooi de controle ook is.