Stop met prompten. Begin met loops.

Waarom de meest waardevolle AI-vaardigheid van 2026 niet het schrijven van een prompt is, maar het ontwerpen van het systeem dat de prompts schrijft.

---

Op 7 juni 2026 plaatste Peter Steinberger — de maker van OpenClaw, het open-source AI-agentproject dat de snelst gestarde repo in de geschiedenis van GitHub werd — twaalf woorden die het AI-coding-internet op zijn kop zetten:

"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

Een paar dagen eerder zei Boris Cherny, de bedenker en hoofd van Claude Code bij Anthropic, vrijwel exact hetzelfde vanaf het podium: hij prompt Claude niet meer zelf. Hij heeft loops draaien die Claude aansturen en zelf bepalen wat er moet gebeuren. Zijn werk is het schrijven van loops.

Twee uitspraken. Miljoenen views. En een golf van verwarring, want bijna niemand kon uitleggen wát een loop nou eigenlijk is.

Dat is jammer, want het concept raakt aan de kern van waar wij bij The Automation Group dagelijks mee bezig zijn: de verschuiving van AI als gereedschap dat je vasthoudt, naar AI als collega die zelfstandig doorwerkt. In dit stuk leggen we uit wat loop engineering is, hoe een loop in elkaar zit, waar het waarde oplevert voor organisaties — en, minstens zo belangrijk, waar het misgaat.

Van prompt engineering naar loop engineering

Twee jaar lang was de manier om waarde uit een AI-agent te halen simpel: schrijf een goede prompt, geef genoeg context mee, lees wat eruit komt en typ het volgende. De agent was het gereedschap en jij hield het de hele tijd vast — beurt na beurt.

Loop engineering breekt met die houding. In plaats van zelf elke prompt te typen, bouw je één keer een klein systeem dat het werk vindt, uitdeelt, controleert, vastlegt wat klaar is en zelf bepaalt wat de volgende stap is. Daarna laat je dat systeem de agents aansturen — niet jij.

Addy Osmani, jarenlang engineeringleider bij Google en auteur over agentic engineering, vat het kernachtig samen: loop engineering is jezelf vervangen als degene die de agent prompt. Je ontwerpt het systeem dat dat voortaan doet.

De analogie die het beste blijft hangen: prompt engineering is schaken — één weloverwogen zet tegelijk, met al je aandacht op het bord. Loop engineering is het bouwen van de schaakcomputer. Je definieert het doel, stelt de regels op en laat de machine spelen.

Dit is geen verandering van gereedschap. Het is een verandering van rol. Je bent niet langer de prompter. Je bent de architect van het systeem dat de prompter vervangt.

De anatomie van een loop: vijf bouwstenen plus geheugen

Een loop die echt onbewaakt draait, is geen lange prompt. Het is een klein systeem met vijf capaciteiten en één plek om dingen te onthouden. Osmani's indeling — die opvallend genoeg bijna één-op-één terugkomt in zowel Claude Code als OpenAI Codex — ziet er zo uit:

1. Automations (de hartslag). Geplande taken die op een vast ritme afgaan en zelfstandig werk ontdekken en trieëren. Zonder een schema heb je een eenmalige sessie. Mét een schema gebeurt "ik zou eigenlijk elke ochtend de openstaande tickets moeten checken" voortaan ook als niemand een terminal opent.

2. Worktrees (parallel zonder chaos). Zodra je meer dan één agent tegelijk draait, gaan ze elkaars werk overschrijven — net als twee engineers die op dezelfde regels committen zonder overleg. Geïsoleerde werkomgevingen zorgen dat agents elkaar niet in de weg zitten.

3. Skills (vastgelegde projectkennis). Een agent begint elke sessie koud en vult elk gat in je intentie op met een zelfverzekerde gok. Een skill is die kennis één keer opgeschreven, op een plek waar de agent hem elke keer leest: de conventies, de bouwstappen, de "dit doen we zo níét vanwege dat ene incident". Zonder skills leidt de loop je hele project elke cyclus opnieuw af uit het niets. Mét skills stapelt de kennis zich op.

4. Plugins en connectors (de loop raakt je echte gereedschap). Een loop die alleen het bestandssysteem ziet, is een minuscule loop. Via connectors — gebouwd op het Model Context Protocol (MCP), de standaard die inmiddels door OpenAI, Google, Microsoft en de rest is overgenomen — kan de agent je issuetracker lezen, een database bevragen, een bericht in Slack plaatsen. Dit is het verschil tussen een agent die zegt "hier is de oplossing" en een loop die de oplossing zélf doorvoert en het ticket bijwerkt.

5. Sub-agents (scheid de maker van de controleur). Het nuttigste structurele element in een loop, met afstand. Het model dat de code schreef is veel te aardig om zijn eigen huiswerk te beoordelen. Een tweede agent — met andere instructies en soms een ander model — vangt op wat de eerste zichzelf had wijsgemaakt.

En dan de zesde, het geheugen. Een markdownbestand, een bord in je projecttool, wat dan ook dat buiten één gesprek leeft en bijhoudt wat klaar is en wat nog moet. Klinkt te simpel om belangrijk te zijn, maar het is de spil van het geheel: het model vergeet alles tussen runs, dus het geheugen moet op schijf staan, niet in de context. De agent vergeet, het geheugen niet.

Hoe één loop er in de praktijk uitziet

Zet de stukken bij elkaar en één draad verandert in een klein controlepaneel. Een veelgebruikt patroon:

Een automation draait elke ochtend. De prompt roept een triage-skill aan die de mislukte tests van gisteren, de openstaande issues en de recente wijzigingen leest, en schrijft de bevindingen weg in een geheugenbestand. Voor elke bevinding die de moeite waard is, opent de draad een geïsoleerde werkomgeving en stuurt een sub-agent om een oplossing te schrijven — waarna een tweede sub-agent die oplossing controleert tegen de projectkennis en de bestaande tests. Connectors zorgen dat de loop het werk zelf doorvoert en het ticket bijwerkt. Alles wat de loop niet aankan, belandt in een inbox voor jou.

Het mooie: je hebt dit één keer ontworpen. Je hebt geen van die stappen geprompt. En morgenochtend pakt de run de draad op waar hij vandaag stopte.

De loop-stack: waar de waarde voor bedrijven écht zit

Voor wie agents in een organisatie wil inzetten, is het nuttig om verder te kijken dan de coding-context. LangChain beschrijft loop engineering als een stapeling van vier loops, en juist de bovenste twee zijn waar bedrijfswaarde zich opbouwt:

1. De agent-loop — het model roept tools aan tot de taak klaar is. De basis.
2. De verificatie-loop — een controleur toetst de output aan een rubric en stuurt hem terug als het niet goed genoeg is.
3. De applicatie-loop — de agent wordt ingebed in je bestaande systemen en draait op events: een nieuw document, een binnenkomende mail, een webhook.
4. De hill-climbing-loop — het systeem verbetert zichzelf continu op basis van jouw criteria.

De meeste organisaties denken nog in loop 1 en 2. De waarde compoundt in loop 3 en 4 — waar agents permanent in je ecosysteem draaien en meebewegen met wat jij belangrijk vindt.

Concrete, vandaag al inzetbare voorbeelden buiten de codewereld:

• Klantenservice die reageert op events. Een ticket landt in je systeem, de webhook vuurt, de agent leest het, classificeert het, schrijft een concept-antwoord en besluit zelf: versturen of escaleren naar een mens.
• Wekelijkse analyses op de klok. Elke vrijdag om 16:00 aggregeert een agent de cijfers van de week tot een digest — of iemand erom vraagt of niet. De kracht is voorspelbaarheid.
• Continue concurrentiemonitoring. Elk uur checkt een agent of de prijspagina van een concurrent is veranderd en vergelijkt met de opgeslagen baseline.
• Leadkwalificatie, datavalidatie, documentcontrole. Batchtaken die te variabel zijn voor klassieke regelgebaseerde automatisering, maar te repetitief om handmatig te doen.

Het ontwerpprincipe dat steeds terugkomt: handel de duidelijke gevallen automatisch af, escaleer de twijfelgevallen naar een mens, en leg altijd vast wat er is gedaan.

Wat de loop níét voor je doet

Hier wordt het eerlijk. Loop engineering verandert het werk, het laat je er niet uit verdwijnen. En drie problemen worden juist scherper naarmate de loop beter werkt, niet makkelijker.

Verificatie blijft bij jou. Een loop die onbewaakt draait, is ook een loop die onbewaakt fouten maakt. Daarom splits je de controleur van de maker — om de "klaar"-melding van de loop iets te laten betekenen. Maar zelfs dan is "klaar" een claim, geen bewijs. Je taak blijft: alleen werk opleveren waarvan je hebt bevestigd dat het klopt.

Je begrip verdampt als je het toelaat. Hoe sneller de loop dingen oplevert die jij niet zelf hebt gemaakt, hoe groter het gat tussen wat er bestaat en wat jij nog snapt. Een soepele loop laat dat gat alleen maar sneller groeien — tenzij je leest wat hij heeft gemaakt.

De comfortabele houding is de gevaarlijke. Als de loop zichzelf draait, is het verleidelijk om geen mening meer te hebben en simpelweg aan te nemen wat eruit komt. Osmani noemt dat cognitive surrender. De loop ontwerpen is de remedie als je het doet met oordeelsvermogen — en het versnellingspedaal als je het doet om niet te hoeven nadenken. Dezelfde handeling, tegenovergesteld resultaat.

En let op de kosten. Een geplande loop met een verificatiemodel na elke beurt kan razendsnel tokens verbranden. Agents verbruiken al snel een veelvoud van een gewone chat, en in multi-agent-opstellingen loopt dat verder op. De praktijkles: begin met een traag ritme en een strakke stopconditie, hou de kosten een paar dagen in de gaten, en schaal pas op als de loop werk oplevert dat je daadwerkelijk gebruikt. En bouw altijd een rate limit in — een webhook-storm die in een minuut tienduizend events binnenduwt, kan tienduizend agent-runs starten en je budget in een uur opmaken.

Twee mensen, dezelfde loop, tegengesteld resultaat

De scherpste observatie uit alle stukken die we erop nalazen: twee mensen kunnen exact dezelfde loop bouwen en volkomen tegengestelde uitkomsten krijgen.

De een gebruikt hem om sneller te gaan op werk dat hij diep begrijpt. De ander gebruikt hem om dat begrip juist te vermijden. De loop kent het verschil niet. Jij wel.

Dát is wat loop-ontwerp moeilijker maakt dan prompt engineering, niet makkelijker. Het punt van Cherny is nooit geweest dat het werk lichter werd. Het is dat het hefboompunt is verschoven.

Wat dit betekent voor jouw organisatie

Voor ons sluit loop engineering naadloos aan op hoe wij naar de agentic enterprise kijken: niet langer denken in losse AI-taken die iemand handmatig aanstuurt, maar in systemen die zelfstandig doorlopen terwijl je team zich richt op oordeel, richting en de gevallen die er écht toe doen.

Drie dingen om mee te nemen als je hiermee aan de slag wilt:

1. Begin smal. Pak één terugkerend, goed begrepen proces — niet je meest complexe. Bouw daar één loop omheen, krijg hem werkend, en breid pas dan uit. Alles tegelijk willen automatiseren is de snelste weg naar een loop die overal stilletjes lekt.
2. Investeer in de zesde bouwsteen. Het geheugen en de vastgelegde skills zijn waar je voorsprong zich opstapelt. Een loop zonder geheugen herhaalt elke dag dezelfde leercurve. Een loop mét geheugen wordt elke dag beter.
3. Hou een mens in de loop op de plekken die ertoe doen. Niet als vangnet voor als de agent faalt, maar als bewuste ontwerpkeuze: de agent-loop handelt af wat redeneerbaar is, de mens-loop handelt af wat autoriteit, context of verantwoordelijkheid vereist die de agent niet heeft.

Het hefboompunt is verschoven. Prompten was vorig jaar. Loops zijn nu — en de bouwstenen liggen voor iedereen klaar.

Bouw de loop. Maar bouw hem als iemand die van plan is de engineer te blíjven, niet alleen degene die op start drukt.

---

The Automation Group bouwt agentic AI-systemen voor ruim 300 organisaties per jaar. Ons engineeringteam — agentic engineers met een 10x-mindset, onder leiding van CTO Stefan van der Leeden — ontwerpt loops, skills en verificatie die in productie standhouden. Benieuwd waar in jouw organisatie de eerste loop waarde oplevert? Neem contact op.