Loop engineering, harness engineering en Hermes uitgelegd

Drie begrippen doken de afgelopen maanden op in bijna elk gesprek over AI-agents: harness engineering, loop engineering en Hermes Agent. Het zijn geen marketingtermen en geen hype. Ze beschrijven een echte verschuiving in hoe ontwikkelaars agents bouwen en draaien, en ze horen in een vaste volgorde bij elkaar. Hieronder lees je wat elk begrip betekent, en hoe ze op elkaar stapelen.

Beginner-tip:Weet je nog niet precies wat een AI-agent is? Lees dan eerst onze uitlegAI-agents in 2026: wat zijn ze en wat kun je er echt mee?. Dit stuk gaat een laag dieper: niet wát een agent is, maar hoe je er een betrouwbaar laat werken.

Waarom deze woorden nu pas opduiken

Om de drie termen te snappen, helpt één stukje achtergrond. Een tijd lang was de belangrijkste vaardigheid voor het werken met AI het schrijven van goede instructies: prompt engineering. Eén bericht erin, één antwoord eruit. Dat werkte prima voor losse taken, en onze gids over goede prompts schrijven gaat daar dieper op in.

In de loop van 2025 verschoof de aandacht naar context engineering. De vraag werd niet langer “hoe formuleer ik dit?”, maar “welke informatie heeft het model nodig om dit op te lossen?” Je denkt dan na over welke documenten, geschiedenis en data je het model voorschotelt.

In 2026 waren die twee lagen basiskost geworden. Agents draaiden inmiddels urenlang, namen tientallen beslissingen achter elkaar en raakten echte bestanden en systemen aan, zonder dat er iemand bij elke stap meekeek. Toen kwamen er drie nieuwe problemen bovendrijven: in welke omgeving zet je de agent, hoe houd je hem betrouwbaar aan de praat zonder jou, en welk gereedschap voert dat allemaal uit? Die problemen kregen namen.

Wat is harness engineering?

Harness engineering is het ontwerpen van de omgeving waarin een AI-agent draait. Niet het model. Niet de prompt. De omgeving. Concreet: welke tools de agent mag aanroepen, waar hij zijn informatie vandaan haalt, welke controles zijn werk toetsen, en wanneer hij hoort te stoppen.

De term komt van Mitchell Hashimoto, de man achter HashiCorp en medebedenker van Terraform. Op 5 februari 2026 beschreef hij op zijn blog een gewoonte die hij had ontwikkeld (Bron: Mitchell Hashimoto). Telkens als een agent een fout maakte, verbeterde hij die niet even snel in de chat, maar bouwde hij een permanente rem in de omgeving van de agent, zodat de fout niet nóg een keer kon gebeuren. Hij noemde het “de harness engineeren”. OpenAI en Anthropic publiceerden binnen enkele weken hun eigen uitwerking. De term bleef plakken.

Waarom het uitmaakt zie je pas op schaal. Zonder harness is een agent alleen betrouwbaar in een demo. OpenAI deelde een intern experiment waarin een team van drie engineers vijf maanden lang vrijwel geen code zelf schreef: alles kwam van hun coding-agent Codex. Het resultaat was een codebase in de orde van een miljoen regels en zo’n 1.500 samengevoegde pull requests (Bron: OpenAI).

Om daar te komen moesten ze vier problemen oplossen die met prompten alleen niet lukten. De agent gokte naar naamgeving en architectuur omdat niets hem de regels van het project vertelde: de oplossing was een gestructureerde docs/-map die de agent zelf kon doorzoeken. Menselijke review werd de bottleneck omdat de agent sneller code maakte dan mensen konden nakijken: de oplossing was de agent zijn eigen tests laten draaien en aan een harde norm laten voldoen voordat een taak “klaar” heette. Architecturale wildgroei ontstond omdat de agent slechte patronen kopieerde: de oplossing was een strikte structuur die linters automatisch afdwongen. En stille technische schuld stapelde zich weken op: de oplossing was geplande achtergrond-agents die op afwijkingen scanden.

Geen van die vier oplossingen raakte de prompt. Allemaal raakten ze de omgeving.

Gevorderden:Let op de norm die OpenAI hanteerde: een service moest binnen 800 milliseconden opstarten voordat de agent een taak als afgerond mocht markeren. Dat is de essentie van een harness: geen vage instructie, maar een meetbare drempel die de agent objectief kan halen of missen. Meetbaarheid is wat verificatie automatiseerbaar maakt.

Wat is loop engineering?

Loop engineering is het ontwerpen van het systeem dat je agent aanstuurt, in plaats van dat je elke prompt zelf typt.

De term werd breed opgepikt na een essay van Addy Osmani, engineering-lead bij Google Chrome, in juni 2026 (Bron: Addy Osmani). Hij bouwde voort op twee observaties die al snel rondgingen. Peter Steinberger, de ontwikkelaar achter het OpenClaw-project, schreef: “Je zou coding-agents niet meer moeten prompten. Je zou loops moeten ontwerpen die je agents prompten.” Die post haalde binnen een dag miljoenen weergaven. En Boris Cherny, hoofd van Claude Code bij Anthropic, zei het nog directer: “Ik prompt Claude niet meer. Ik heb loops draaien die Claude prompten en uitzoeken wat te doen. Mijn werk is loops schrijven.”

Een loop is een herhalende cyclus. De agent voert een actie uit, krijgt echte feedback uit zijn omgeving (testresultaten, linter-output, foutmeldingen), gebruikt die feedback om te beslissen wat hij daarna doet, en gaat door tot een doel is bereikt. Jij definieert het doel één keer. De loop draait tot het af is. Het verschil met een losse prompt is groot: een prompt vraagt het model om een antwoord, een loop zet het model in een systeem dat naar een echte uitkomst toewerkt.

Osmani gaf de loop een concrete anatomie van zes onderdelen. Ze vormen een handige checklist als je zelf begint.

Dit sluit aan op wat we eerder schreven in Karpathy stopt met zelf coderen: de mens verschuift van uitvoerder naar ontwerper van het systeem.

Hoe harness en loop zich tot elkaar verhouden

Loop engineering ligt precies één laag boven harness engineering. De harness is de omgeving. De loop is wat de agent door die omgeving heen jaagt, herhaaldelijk en met controle.

Je kunt een harness hebben zonder loop: één goed uitgeruste agent die je één keer laat lopen. Een loop zonder harness is wankel, want er zijn geen grenzen, geen feedback en geen geheugen. Ze werken samen. Osmani vatte het bondig samen: de harness maakt een agent capabel, de loop maakt hem autonoom.

Gevorderden:De verificatiestap in een loop verdient een eigen model of agent. Laat je dezelfde agent zijn eigen werk beoordelen, dan krijg je een beoordelaar met dezelfde blinde vlekken als de maker. Dat is ook waarom governance rond agents zo’n thema is:Gartner voorspelt dat 40% van de bedrijven zijn agents vóór 2027 weer terugschroeft, vaak omdat controle en verificatie ontbraken.

Het bewijs op schaal: zestien agents bouwden een complete C-compiler

Waar OpenAI’s Codex-experiment laat zien wat een kleine harness voor een productieteam oplevert, laat een tweede voorbeeld zien hoe ver diezelfde aanpak reikt als je hem maximaal opschaalt. Nicholas Carlini, onderzoeker op Anthropics Safeguards-team, zette zestien Claude-agents parallel aan het werk op één gedeelde codebase, met de opdracht een C-compiler te schrijven die de Linux-kernel kan bouwen (Bron: Anthropic).

De agents kregen geen losse instructies maar een harness die Claude in een simpele lus zet: pak de volgende openstaande taak, werk hem af, ga door. Na bijna 2.000 Claude Code-sessies en zo’n 20.000 dollar aan API-kosten stond er een compiler van ruim 100.000 regels die Linux 6.9 kan bouwen op x86, ARM én RISC-V, plus een reeks andere open-sourceprojecten (Bron: InfoQ). Het meeste denkwerk zat niet in de code zelf, maar in de tests en de feedback eromheen — want zodra de verificatie niet waterdicht is, lost een agent met evenveel overtuiging het verkeerde probleem op.

Dit sluit direct aan bij wat hierboven al bleek: harness plus loop schalen exponentieel mee, zolang de controle daarin meegroeit.

Wat een loop kost, en de valkuil die naar een Simpsons-personage is vernoemd

Een loop draait door totdat hij stopt, en dat is precies waar het vaak misgaat. Ontwikkelaar Geoffrey Huntley doopte het risico de “Ralph Wiggum”-techniek: een agent die dezelfde opdracht blijft herhalen en zichzelf, net als het gelijknamige Simpsons-personage, overtuigd voor vol aanziet terwijl het resultaat half werk is (Bron: Geoffrey Huntley). Zonder harde stopconditie en een onafhankelijke verificatiestap blijft zo’n loop stilletjes middelmatige output produceren, met de rekening die gewoon doortikt.

Reken daarom in kosten per geaccepteerde wijziging, de enige eenheid die er echt toe doet. Levert een loop tien resultaten op en gebruik je er zes, dan doe je alsnog het controlewerk dat de loop juist moest overnemen, en draait hij feitelijk verlieslatend. Onder een acceptatiegraad van ongeveer de helft is het vaak goedkoper om de taak te versmallen of de toets aan te scherpen dan om de loop te laten doordraaien.

Wat is Hermes Agent?

Hermes Agent is een open-source, autonome AI-agent gebouwd door Nous Research. Hij verscheen op 25 februari 2026 onder een MIT-licentie (Bron: Nous Research). Hermes draait op je eigen server in plaats van een clouddienst die iemand anders beheert, en werkt met elk taalmodel dat je kiest: Claude, GPT, Gemini of een lokaal model via je eigen endpoint. Het project groeide hard en passeerde in minder dan vier maanden de 175.000 GitHub-sterren, een uitzonderlijk tempo voor een nieuwe repository.

Wat Hermes anders maakt is zijn geheugen. De meeste agents zijn stateless: sluit je de sessie, dan vergeet de agent alles. Je projectcontext, je voorkeuren, wat de vorige keer werkte, wat faalde: weg. Hermes werkt niet zo. Als hij een taak afrondt, schrijft hij een herbruikbaar skill-bestand: een gestructureerd verslag van wat hij deed en hoe. Komt later een vergelijkbare taak langs, dan laadt hij dat skill-bestand en past het toe. Nous Research noemt dit een closed learning loop: de agent voert niet alleen uit, hij leert van de uitvoering en stelt zich bij.

Daarnaast draait Hermes geplande cron-taken terwijl je niet achter je computer zit, koppelt hij met een reeks berichtenplatforms, en gebruikt hij het Model Context Protocol (MCP) om externe diensten aan te haken. Geen telemetrie, geen cloud-afhankelijkheid, geen vendor lock-in.

Beginner-tip:“Op je eigen server draaien” klinkt zwaarder dan het is, maar het betekent wel dat je zelf voor installatie en onderhoud zorgt. Gebruik je AI vooral binnen één project via een kant-en-klare tool, dan isClaude Code op desktopwaarschijnlijk een logischer beginpunt dan een zelf-gehoste agent.

Hermes is geen coding-assistent die vastzit aan een editor, en ook geen chatbot-omhulsel. Het lijkt meer op een achtergrondproces dat op jouw infrastructuur draait, kennis opbouwt en beter wordt naarmate het werkt. Heb je vooral hulp nodig bij code binnen één project, dan is een tool als Claude Code op dat specifieke werk nog steeds sterker. Hermes is de keuze als je over meerdere projecten werkt, blijvend geheugen wilt, en een agent op je eigen infrastructuur wilt draaien.

Welke moet je kennen, en wat merk je ervan

Gebruik je AI voor losse klussen, dan is geen van deze begrippen urgent. Een goede prompt met de juiste context handelt de meeste individuele verzoeken nog prima af.

Bouw je agents die langer dan een paar minuten draaien, echte systemen aanraken of betrouwbaar moeten werken zonder toezicht, dan heb je een harness nodig. Geen hoeveelheid prompten vervangt die. Wil je die agents op een schema laten lopen, ‘s nachts of parallel, dan ben je loops aan het bouwen, en de zes onderdelen van Osmani zijn dan je checklist. Wil je dat alles in een open-source, zelf-gehost pakket dat met elk model werkt en onthoudt wat het leert, dan is Hermes Agent het bekijken waard.

De volgorde is prompt, context, harness, loop. We zitten nu op de loop-laag. De eerste drie zijn niet verdwenen, ze zijn alleen niet meer de bottleneck. Voor Nederlandse teams die met agents experimenteren, betekent dat een verschuiving in waar je tijd insteekt: minder in de perfecte zin, meer in de omgeving en de controles eromheen. Dat is minder spannend om over te praten op een borrel, maar het is precies waar betrouwbare agents vandaan komen.