Wat is een agent harness, en waarom telt het soms meer dan het model?
Agent = model + harnas. Wat een agent harness is, waarom hetzelfde model in een ander harnas veel beter scoort, en hoe gidsen en sensoren een agent bijsturen.

Zet de slimste professor ter wereld in een lege kamer. Geen pen, geen papier, geen computer, en na elk gesprek is hij alles vergeten. Hoe briljant hij ook is, een project afronden lukt hem niet.
Zo werkt een los taalmodel. Het kan redeneren en schrijven, maar het kan zelf geen bestand openen, geen test draaien en niet onthouden wat het gisteren deed. Alles wat dat wel mogelijk maakt, heet sinds begin 2026 steeds vaker het agent harness. En de keuze van het harnas blijkt soms meer uit te maken dan de keuze van het model.
Wat is een agent harness?
Een agent harness is alle code, configuratie en uitvoeringslogica rond een taalmodel die van dat model een werkende agent maakt. De formule die onder meer LangChain (maart 2026) en Thoughtworks hanteren: agent = model + harnas. Het model levert de intelligentie; het harnas bepaalt wat het model te zien krijgt, welke acties het kan uitvoeren en wat er met de resultaten gebeurt.
Claude Code, OpenAI Codex en Hermes Agent zijn voorbeelden van harnassen. Onder de motorkap draaien ze allemaal dezelfde lus: stel de prompt samen, roep het model aan, voer de tool-aanroepen uit die het model vraagt, geef de resultaten terug, en herhaal tot de taak klaar is.
Hoeveel maakt het harnas uit?
Een veelgehoorde claim is dat "hetzelfde model tot zes keer beter presteert met een beter harnas, volgens Stanford". Dat klopt half. In het artikel Meta-Harness (maart 2026) van onderzoekers van Stanford en MIT staat in de inleiding dat het veranderen van het harnas rond een vast model op dezelfde benchmark een prestatieverschil van zes keer kan opleveren. Dat getal halen ze uit eerder onderzoek van anderen. Het gaat om het verschil tussen een slecht en een goed harnas, niet om een garantie dat jouw agent zes keer beter wordt.
Wat de onderzoekers zelf lieten zien, is ook interessant. Ze lieten een AI-systeem automatisch zoeken naar betere harnascode. Op de programmeerbenchmark TerminalBench-2 haalde Claude Haiku 4.5 in het gevonden harnas 37,6 procent, tegen 27,5 procent in Claude Code. Hetzelfde kleine model, tien procentpunt verschil, alleen door de code eromheen.
Dat maakt de vraag "welk model gebruiken we?" minder allesbepalend dan hij lijkt. Een goedkoper model in een goed harnas kan een duurder model in een matig harnas bijhalen.
Waaruit bestaat een harnas?
Er is geen vaste lijst, maar deze onderdelen komen in vrijwel elk serieus harnas terug:
- De agentlus. Blijft het model aanroepen en tool-resultaten teruggeven tot de taak klaar is of een grens bereikt wordt.
- Contextbeheer. Bepaalt wat in het beperkte contextvenster past: wat blijft staan, wat wordt samengevat, wat wordt naar een bestand weggeschreven.
- Tools en skills. Toegang tot bestanden, shell, web, API's en databases, plus beschrijvingen die het model vertellen wanneer het welke tool gebruikt.
- Systeemprompt-assemblage. Stelt per taak de instructies, projectregels en relevante context samen.
- Subagents. Laten deeltaken door aparte agents uitvoeren, elk met een eigen, schoon contextvenster.
- Sessie-persistentie. Slaat de toestand op, zodat een onderbroken taak verder kan waar hij was.
- Hooks. Vaste momenten waarop deterministische code draait, bijvoorbeeld een linter na elke bewerking of een menselijke goedkeuring vóór een betaling.
- Permissies en sandbox. Bepalen wat de agent mag: welke mappen, welke commando's, welke netwerktoegang.
Framework of harnas?
In 2023 en 2024 bouwde je een agent met een framework zoals LangChain: een doos bouwstenen die je zelf aan elkaar zet. Een harnas is het resultaat van zo'n bouwproces, klaar voor gebruik. Je geeft een doel en de lus, de tools en de veiligheidsregels zijn al geregeld.
Voor wie agents inzet, verschuift het werk daarmee. Je bouwt minder zelf en richt meer in: welke instructies, welke tools, welke controles. Dat inrichten heet inmiddels harness engineering.
Minder tools, betere agent
Een harnas verbeteren betekent niet automatisch dingen toevoegen. Vercel bouwde een interne agent die vragen over hun data beantwoordt met SQL. Na maanden werk had die agent een reeks gespecialiseerde tools, zware promptengineering en zorgvuldig contextbeheer, en hij was fragiel en traag. Het team verwijderde vrijwel alles en hield één tool over: willekeurige bash-commando's uitvoeren in een sandbox.
Op hun eigen testset van vijf representatieve vragen ging het slagingspercentage van 80 naar 100 procent, met ongeveer 40 procent minder tokens en stappen, en 3,5 keer zo snel. Vercel noemt er zelf een belangrijke voorwaarde bij: het werkte omdat hun datadefinities al goed gedocumenteerd waren in overzichtelijke YAML-bestanden. Een rommelige datalaag los je niet op met een simpeler harnas.
Vijf vragen is een kleine test, dus trek er geen harde conclusie uit. Het patroon is wel herkenbaar: elke extra tool is iets waar het model over moet nadenken, en tools die samenvatten wat het model zelf ook kan lezen, voegen vooral ruis toe.
Gidsen en sensoren: een agent bijsturen
Omdat een taalmodel niet volledig voorspelbaar is, heb je twee soorten sturing nodig. Birgitta Böckeler van Thoughtworks beschrijft ze in haar artikel over harness engineering (april 2026) als gidsen en sensoren.
Gidsen sturen vooraf (feedforward). Ze vergroten de kans dat het de eerste keer goed gaat: instructies, projectconventies, voorbeelden, templates.
Sensoren controleren achteraf (feedback). Ze laten de agent zijn eigen fouten zien, zodat hij ze kan herstellen voordat een mens ernaar kijkt.
Beide kunnen computationeel zijn (deterministisch en snel, zoals tests, linters en typecheckers) of inferentieel (een tweede model dat beoordeelt, trager en minder voorspelbaar, maar geschikt voor zaken die een linter niet ziet).
Een voorbeeld: een coding-agent werkt in een PHP-project. Een gids is een instructiebestand met de conventies van het project: waar de klassen staan, hoe migraties heten, welke functies niet gebruikt mogen worden. Een sensor is een hook die na elke wijziging PHPStan en de testsuite draait en de foutmeldingen teruggeeft aan de agent. Zonder die sensor ontdek jij de fout pas bij de review, en met de sensor ontdekt de agent hem zelf binnen een paar seconden.
Wat dit verandert als je een agent kiest of bouwt
Vergelijk bij het kiezen van een agent niet alleen modellen, maar ook wat eromheen zit: hoe gaat hij om met context, welke tools heeft hij, en welke controles draaien er automatisch? En als je een agent inzet in je eigen project, is de snelste verbetering vaak geen duurder model, maar een goede sensor: een test of linter die de agent na elke stap zelf draait.
Stand van september 2026.


