Loop Engineering op Enterprise-niveau: van Laptop Loops tot Beheerde Runtimes

In de eerste week van juni 2026 herstructureerde de AI-coding-discussie zich rond één idee. Peter Steinberger — maker van het OpenClaw agent-project — publiceerde dat de vaardigheid niet langer het prompten van coding agents is, maar het ontwerpen van de loops die hen prompten; Boris Cherny, die Claude Code leidt bij Anthropic, omschreef zijn eigen functie op dezelfde manier: "Mijn taak is het schrijven van loops." Addy Osmani's veelgedeelde essay gaf deze praktijk een naam — loop engineering — en een anatomie: automatiseringen, worktrees, skills, connectors, sub-agents en externe status. Het idee is reëel en waard om serieus te worden genomen. Het is ook, zoals het nu wordt toegepast, een patroon voor individuele ontwikkelaars dat draait op individuele laptops — en het gat tussen een loop in je terminal en een loop die een enterprise onbeheerd om 3 uur 's nachts kan laten draaien, is precies waar deze post over gaat.

Noor, een staff engineer, bouwde de loop die iedereen nu beschrijft: een ochtendautomatisering die nachtelijke CI-fouten en openstaande issues leest, conceptoplossingen maakt in geïsoleerde checkouts, een tweede agent deze laat beoordelen, PR's opent en een net statusbestand achterlaat waarin staat wat er is gedaan en wat de volgende stap is. Drie weken lang was het de beste tool in het team — en daarna werd het de aanleiding voor drie ongemakkelijke vergaderingen. Finance vroeg waarom de tokenfactuur van één weekend zo hoog was opgelopen: de loop had twee dagen lang enthousiast herhaaldelijke pogingen gedaan tegen een defecte testomgeving zonder dat iemand toekeek. Security vroeg waar de credentials van de loop zich bevonden: in een configuratiebestand op Noor's laptop, met haar persoonlijke tokens, draaiend onder haar identiteit om 6 uur 's nachts. En haar director stelde de vraag waarop helemaal geen antwoord was: vier andere engineers hadden het patroon gekopieerd, elk op een andere manier — dus hoeveel loops had de organisatie, wat kon elke loop aanraken en wie had dit allemaal goedgekeurd? De loop werkte. De runtime was een laptop, en alles wat misging was daartoe te herleiden.

Deze post neemt loop engineering serieus op haar eigen voorwaarden — wat het is, waarom het daadwerkelijk de volgende laag van het vakgebied is, waar de scherpe randjes zitten — en maakt vervolgens de vertaalslag waar Noor's director stilzwijgend om vroeg: elke primitive van de loop, vertaald van laptopconventie naar beheerde infrastructuur. De terminologie volgt Osmani's essay en de omringende discussie; het enterprise-deel volgt de TrueFoundry Agent Harness documentatie. De eerlijke samenvatting van het gat is één zin: loops zijn een runtime-probleem vermomd als een workflow.

1. Wat Loop Engineering Daadwerkelijk Is

Strip de discussie van opsmuk en de definitie is compact. Twee jaar lang betekende het werken met een coding agent dat je deze continu moest begeleiden: je prompt, je leest, je prompt opnieuw — de mens is de loop. Loop engineering vervangt dat door een ontworpen systeem: iets vindt het werk (een schema dat CI, issues of error feeds scant), draagt het over aan een agent, controleert het resultaat met een verifier die niet de maker is, legt vast wat er is gebeurd in een status die de conversatie overleeft, en bepaalt de volgende stap. Je bouwt het één keer; het prompt de agents vanaf dat moment. Osmani plaatst het "één verdieping boven" harness engineering — de harness voert één agent uit door één taak; de loop bepaalt welke taken, wanneer, en wat telt als voltooid. Sommige auteurs omschrijven het als twee geneste loops: een inner loop die werk uitvoert tegen een specificatie, en een outer loop die de wereld observeert en de volgende specificatie schrijft.

Als dat bekend klinkt uit deze reeks, dan klopt dat — de loop is het plan→act→observe-patroon op een hoger niveau getild, met dezelfde anatomie die onze harness deep dive ontleedde: stopcondities (hier, "draai totdat de tests slagen," beoordeeld door een afzonderlijk model), foutafhandeling en status. Simon Willison schreef al in september 2025 over het ontwerpen van agentic loops; wat er halverwege 2026 veranderde, zoals Osmani opmerkt, is dat de primitives niet langer een verzameling persoonlijke bash-scripts waren, maar direct in de producten werden meegeleverd — wat precies het moment is waarop een praktijk niet langer een hack is, maar infrastructuur wordt. Infrastructuur, zoals we zullen zien, met de eisen van infrastructuur.

2. De Anatomie: Zes Primitives

Osmani's analyse — die vrijwel identiek is aan zowel de Codex-app als Claude Code, waarbij de convergentie zijn meest interessante observatie is — geeft de loop zes onderdelen. Automatiseringen zijn de hartslag: prompts die op een schema worden geactiveerd, discovery en triage uitvoeren, en bevindingen naar een inbox sturen; plus run-until-done primitives waarbij een doel wordt uitgevoerd totdat aan een verifieerbare voorwaarde is voldaan. Geïsoleerde werkruimtes (git worktrees, in het geval van codering) voorkomen dat parallelle agents op dezelfde bestanden botsen. Skills — het SKILL.md-patroon — codificeren projectkennis eenmalig, zodat de loop niet elke cyclus opnieuw je conventies hoeft af te leiden. MCP-connectors koppelen de loop aan echte systemen — het verschil tussen een agent die zegt "hier is de fix" en een loop die de PR opent en het ticket bijwerkt. Sub-agents scheiden de maker van de checker, omdat het model dat de code schreef zijn eigen werk te welwillend beoordeelt. En externe status houdt bij wat er is gedaan en wat er volgt, omdat het model tussen runs door alles vergeet en het geheugen buiten de context moet leven.

Twee dingen vallen op voordat we deze lijst vertalen. Ten eerste is vrijwel niets ervan een nieuw mechanisme — schema's, isolatie, verpakte kennis, integraties, delegatie en duurzame status zijn de oudste ideeën in operations, opnieuw gerangschikt rondom een model. Ten tweede, en nog belangrijker: elke primitive is een toekenning van bevoegdheden. Een automatisering is een permanente toestemming om op een schema te handelen; een connector is een permanente toegang tot een echt systeem; een sub-agent is een gedelegeerde identiteit. Op een laptop zijn die toekenningen onzichtbaar. Op de schaal van een organisatie vormen ze het centrale vraagstuk.

3. Een Eerlijke Analyse van Wanneer Loops Rendant Zijn

De discussie is pas enkele dagen oud en kent nu al een gezonde sceptische stroming, die aandacht verdient voorafgaand aan de enterprise-vertaling — het vertalen van een slecht idee naar beheerde infrastructuur levert immers alleen beheerde verspilling op. De eigen voorwaarden van experts voor het rendabel maken van loops, zoals vroege analyses lieten zien: de taak herhaalt zich (een loop schrijft de ontwerpkosten af over meerdere runs; voor een eenmalige taak is een goede prompt sneller); verificatie is te automatiseren ("alle tests slagen en lint is clean" is een echte stopcondition, "ziet er goed uit" niet); het tokenbudget kan de verspilling opvangen (Osmani's eigen essay begint met de kostenwaarschuwing, en Noor's weekendfactuur is het klassieke incident); en de agent beschikt al over de tools die de taak vereist. Ontbreekt er één, dan kost de loop meer dan dat deze oplevert.

Er is ook een diepere waarschuwing die het enthousiasme rond brute-force-loops vaak overslaat: foutpercentages stapelen zich op. Een loop die vijf stappen aan elkaar koppelt, die elk voor 95% betrouwbaar zijn, wordt in ongeveer driekwart van de gevallen foutloos afgerond — en de fouten van een onbeheerde loop hopen zich op in de status, waar de run van morgen op voortbouwt. Dit is waarom de scheiding tussen maker en checker essentieel is en niet slechts decoratief, en waarom Willison's oude grap — een agent als "een LLM die in een loop zijn omgeving ruïneert" — het juiste principe is om boven het automatiseringstabblad te plakken. Niets hiervan is een argument tegen loops; het argument is dat een loop een productiesysteem is — en de rest van deze post behandelt het als zodanig.

4. Het Enterprise-gat: de Laptop Is de Verkeerde Runtime

Voer Noor's drie vergaderingen nu uit als een engineering review. Levenscyclus: de runtime van haar loop was haar machine — deze stopt wanneer het laptopdeksel sluit, overleeft een crash halverwege een run niet, en kan niet pauzeren voor een drie dagen durende goedkeuring, omdat niets duurzaams de run vasthoudt. Een vroeg draaiboek trok precies deze grens: op het moment dat een loop om 3 uur 's nachts moet draaien zonder dat er een terminal openstaat, crashes moet overleven en onbepaalde tijd op een mens moet wachten, heb je het terrein van tools verlogen voor het terrein van runtimes. Credentials: de loop draaide als Noor — haar tokens, in een configuratie in platte tekst, die haar rechten op een schema uitoefenden, in geen enkel audit log te onderscheiden van Noor zelf; een permanente automatisering die de sleutels van een persoon bevat, is het non-human-identity-probleem in het klein. Kosten: niets zat tussen de loop en de teller van de provider — geen budget, geen rate limit, geen toewijzing per run; de uitgaven werden pas ontdekt op de factuur. Inventarisatie: vijf engineers, vijf verschillende kopieën, nul registry — ons verhaal over coding-agent governance en de wildgroei aan agents komt via de achterdeur van productiviteitstools binnen.

Niets hiervan zijn fouten in loop engineering; het zijn eigenschappen van de laptop als runtime, onzichtbaar totdat de loop goed genoeg is om er echt toe te doen. De oplossing is niet het verbieden van het patroon — verboden leiden tot schaduwversies ervan — maar het bieden van een thuis aan dezelfde zes primitives, gebouwd voor onbeheerd, multi-tenant en geauditeerd gebruik. Dat is de vertaalslag die de rest van deze post maakt.

5. De Primitives, Vertaald naar een Beheerde Runtime

Hier is de vertaling, primitive voor primitive, met TrueFoundry's Agent Harness als uitgewerkt voorbeeld. Skills vertalen vrijwel een-op-een: hetzelfde SKILL.md-artefact, maar gepubliceerd in de Skills Registry met versies, herkomst en RBAC, en op verzoek gekoppeld — gecodificeerde kennis als een beheerde catalogus in plaats van een map op vijf laptops. Connectors vertalen naar de MCP Gateway: dezelfde MCP-servers, bereikbaar via een registry met centrale authenticatie, RBAC per tool, guardrails en OAuth-delegatie per gebruiker — gescopete, roteerbare credentials in plaats van de tokens die in Noor's configuratiebestand stonden. Sub-agents vertalen naar harness sub-agents: elke checker of explorer met zijn eigen geïsoleerde context, gescopete tooltoegang en trace — de maker/checker-scheiding met een identiteitsgrens, niet alleen een promptgrens. Geïsoleerde werkruimtes vertalen naar de harness Sandbox: een veilige uitvoeringsomgeving per run — het worktree-idee gegeneraliseerd naar "elke agent krijgt zijn eigen machine." Status wordt een duurzame, door het platform beheerde runstatus die crashes en gesloten laptops overleeft. En automatiseringen worden getriggerde runs: dezelfde agentdefinitie aangeroepen op basis van een schema of event via REST API of SDK, waarbij resultaten in traces en meldingen terechtkomen in plaats van een terminal-scrollback.

Het structurele verschil dat de vertaling oplevert, is de garantie die de laptop niet kan bieden: geen sleutels ergens in de loop. Agentdefinities verwijzen naar modellen, MCP-servers en skills op naam; provider credentials bevinden zich in de AI Gateway, tool-authenticatie in de MCP Gateway, eenmalig geconfigureerd door het platformteam. Noor's loop, op deze manier herbouwd, draait als zichzelf — een geregistreerde agent met een eigen identiteit en toekenningen — en "wat kan deze loop aanraken?" verandert in het raadplegen van een configuratie in plaats van een archeologisch onderzoek.

Noor's ochtendloop als een beheerde agentdefinitie (ter illustratie)

6. Onbeheerd door Ontwerp: Goedkeuringen, Guardrails en Stopcondities

De bepalende eigenschap van een loop is dat niemand meekijkt, dus het is de taak van de runtime om "niemand kijkt mee" veilig te maken. Drie mechanismen dragen die verantwoordelijkheid. Human-in-the-loop controlepunten: de harness pauzeert een gevoelige tool call — het mergen van een PR, het wijzigen van een productiesysteem — en bewaart de status van de run op een duurzame manier totdat iemand toestemming geeft; de loop stopt niet omdat een mens het weekend vrij heeft. Cruciaal is dat destructieve tools organisatiebreed één keer worden gemarkeerd bij de MCP Gateway — het beleid geldt automatisch voor elke loop, in plaats van dat het afhangt van vijf engineers die er elk aan moeten denken dit te configureren. Guardrails: elke model call en tool call passeert de pre- en post-call controlepunten van de gateway — PII, contentbeleid, aangepaste regels — zodat een loop die om 6 uur 's nachts echte tickets verwerkt op exact dezelfde manier wordt gecontroleerd als een interactieve sessie om 14.00 uur. Stopcondities: run-until-done is alleen zo veilig als de vastgestelde grenzen, dus stappenlimieten, tokenbudgetten en stall-detectie zijn harness-configuraties en geen vrome hoop — het verschil tussen "de loop is geconvergeerd" en "de loop is gestopt toen het budget dat aangaf," waarbij de trace laat zien wat het geval was.

Dit is ook waar het maker/checker-idee compleet wordt. Osmani's verifier sub-agent controleert het werk; de controlepunten van de runtime controleren de acties. Een loop kan een uitstekende reviewer-agent hebben en nog steeds een mens nodig hebben tussen de agent en een onomkeerbare merge — en de harness is de plek waar die beoordeling wordt omgezet in handhaving.

7. De Teller: Loops Zijn een Kostenpatroon Voordat Ze een Productiviteitspatroon Zijn

Osmani's essay opent met de waarschuwing die de facturen later bevestigen: tokenkosten variëren enorm, en bij een onbeheerde loop is er ook geen mens aanwezig in de kostencyclus. TrueFoundry's kostenbeheersingsstack verandert dat van een financiële verrassing in een operationele parameter, verdeeld over drie lagen. Ten eerste, harde grenzen per principal: budgetten, quota en rate limits zijn van toepassing op de loop als een eigen agentidentiteit — gedeclareerd als GitOps YAML bij de gateway, afdwingbaar per agent, team, gebruiker of model — zodat Noor's incident in het weekend, afgespeeld tegen een budget per agent, verandert in een begrensde run en een melding op zaterdagavond in plaats van een onverwachte factuur op maandag. Ten tweede, toewijzing per run: de harness traceert elke run met tokens en kosten per model call, tool call en sandbox-uitvoering — waarbij de kosten van de checker afzonderlijk zichtbaar zijn van die van de maker, zodat de afweging uit sectie 3 (herhalend versus eenmalig) wordt gemaakt op basis van cijfers in plaats van onderbuikgevoel. Ten derde, de consolidatie: de kostenanalyses van de gateway aggregeren die uitgaven per loop, per team, per model in de loop van de tijd — wat het punt is waar "zijn de loops rendabel?" ophoudt een discussie te zijn en een dashboard wordt.

De trace bewijst zijn waarde voor meer dan alleen kosten. Een loop die onbeheerd draaide en een vreemde PR opleverde is een forensische vraag, die wordt beantwoord met een volledig dossier per stap.

8. Wat de Runtime Niet Doet: Jij Blijft de Engineer

Osmani sluit zijn essay af met een waarschuwing die de enterprise-vertaling overeind moet houden: de loop verandert het werk, het neemt het niet van je over. Verificatie blijft jouw verantwoordelijkheid — een checker sub-agent zorgt ervoor dat "voltooid" bij een loop iets betekent, maar voltooid is een bewering, geen bewijs. Begripsschuld groeit sneller naarmate de loop verbetert — de kloof tussen wat bestaat en wat je begrijpt, stapelt zich op bij elke ongelezen PR. En de comfortabele houding is de gevaarlijke houding: dezelfde loop is een hefboom voor de engineer die deze gebruikt voor werk dat hij begrijpt, en een versneller van achteruitgang voor degene die deze gebruikt om begrip te vermijden. Een beheerde runtime veranderde die balans niet; het veranderde wat de organisatie ervan kan zien — beoordelingspercentages, goedkeuringspatronen, resultaten per loop — wat de voorwaarde is om het te beheren, geen vervanging voor menselijk oordeel.

Wat de runtime wel veranderde, is wie zich het patroon kan veroorloven. Het huidige loop engineering selecteert op engineers die bereid zijn hun eigen automatiseringsopstellingen te onderhouden; op een beheerde harness is het een definitie die iedereen kan opstellen — no-code builder of SDK, hetzelfde artefact — waarbij de gevaarlijke onderdelen door de architectuur worden afgevangen. Noor's vijfde vergadering is in deze versie kort: elf geregistreerde loops, wat elke loop aanraakt, de kosten van vorige week en het resultaat per loop, en de nieuwe wordt dinsdag binnen dezelfde kaders uitgerold. Geen loops met een compliance-belasting — maar loops met de runtime die ze altijd al stilzwijgend veronderstelden.

9. Veelgestelde Vragen

Hebben we een enterprise runtime nodig voor de ochtendloop van één engineer? Voor één loop, op doelen met een laag risico, waarbij de auteur de factuur in de gaten houdt — waarschijnlijk niet, en anders beweren zou leverancierstheater zijn. De noodzaak voor een runtime ontstaat bij schaalvergroting en belangen: meerdere loops, gedeelde systemen, echte credentials, onbeheerde uren. Noor's verhaal is het typische traject — het patroon verspreidt zich omdat het werkt, en het gat in de governance wordt precies even snel groter.

Kan een loop pauzeren voor een menselijke goedkeuring zonder te stoppen? Op een laptop in feite niet — de status van de run bevindt zich in een proces dat het niet tot maandag volhoudt. Op de harness wel: human-in-the-loop controlepunten bewaren de run op een duurzame manier totdat iemand een beslissing neemt, wat van "de loop opent de PR maar een mens merget deze" een architectuur maakt in plaats van een wensbeeld.

Hoe stoppen we de wildgroei aan loops zonder ze te verbieden? Maak het beheerde pad het makkelijkste pad: een registry geeft antwoord op "hoeveel zijn het er en wat kunnen ze aanraken," centrale credentials nemen de noodzaak weg om tokens in configuratiebestanden te plakken, en een builder die binnen een middag een getraceerde, budgetteerde loop oplevert, wint het qua gemak van een verzameling persoonlijke bash-scripts. Een verbod leidt tot schaduw-loops; een betere standaard leidt tot geregistreerde loops.

Helpt de maker/checker-scheiding echt, of verdubbelt het alleen de kosten? Het kost daadwerkelijk tokens en levert gericht wat op: zet de second opinion in waar een fout maken duur is. Geef de checker andere instructies (idealiter een ander model) en houd deze read-only — een checker die kan bewerken is simpelweg een tweede maker. De trace per stap laat je per loop zien of het genoeg opvangt om de kosten te rechtvaardigen.

Het moment van loop engineering is aangebroken: het zwaartepunt is verschoven van de prompt naar het systeem dat prompt. Maar een loop is een productiesysteem zodra deze zonder jou draait — met de behoeften van een productiesysteem: identiteit, grenzen, controlepunten, traces en een runtime die niet stopt wanneer de laptop dichtgaat. Ontwerp de loop, zoals Osmani zegt, als iemand die van plan is de engineer te blijven. Draai deze, zo voegen wij toe, op iets dat is gebouwd om op te draaien.

Referenties

• Addy Osmani — "Loop Engineering" (juni 2026) — de anatomie waarop deze post voortbouwt, geparafraseerd met bronvermelding; zie ook zijn essays over harness engineering en langdurig draaiende agents.
• Peter Steinberger en Boris Cherny's commentaar uit juni 2026 over het ontwerpen van loops in plaats van het prompten van agents — via Osmani's essay en gelijktijdige berichtgeving.
• Simon Willison — "Designing agentic loops" (september 2025) — de eerdere formulering van loop-ontwerp als de cruciale vaardigheid.
• TrueFoundry Agent Harness — de beheerde runtime: definities, skills, sandbox, goedkeuringen, traces, implementeerbaar als SaaS/self-hosted/on-premise.
• TrueFoundry MCP Gateway en AI FinOps bij de gateway — de lagen voor connector-governance en kostenhandhaving onder de loop.

Northwind en Noor zijn een illustratieve samenstelling, geen specifieke organisatie of incident. De kadering van loop engineering volgt Addy Osmani's essay uit juni 2026 en de omringende community-discussie (Steinberger, Cherny en vroege analyses), geparafraseerd met bronvermelding; geciteerde zinnen zijn korter dan vijftien woorden en voorzien van bronvermelding. Tool-functionaliteiten van de Codex-app en Claude Code worden beschreven volgens die openbare discussie op het moment van schrijven en ontwikkelen zich snel. Configuratiefragmenten zijn vereenvoudigd voor de leesbaarheid en zijn geen letterlijke productschema's; de betrouwbaarheidsberekening in sectie 3 is illustratief. TrueFoundry-functionaliteiten weerspiegelen de openbare documentatie op het moment van schrijven; controleer dit met de actuele documentatie.

‍

‍