Iemand vroeg me onlangs welk model ik gebruik voor mijn agents. Een redelijke vraag, en het antwoord doet er minder toe dan hij dacht.
Ik draai sinds februari 2025 agents in productie. In die tijd heb ik van model gewisseld, meerdere keren, en dat kostte me telkens een middag. De laag eromheen vervangen zou me maanden kosten, en die laag bepaalt of het werkt.
Die laag heet een harnas. Er is verrassend weinig over geschreven, terwijl bijna elke fout die ik heb opgelost daar zat en niet in het model.
De formule die het scherp stelt
Er gaat een formule rond die het in één regel zegt: Agent = Model + Harness.
Dat klinkt als een open deur tot je hem omdraait. Een model op zichzelf is geen agent. Het is een functie die tekst in tekst omzet. Het heeft geen bestanden, geen shell, geen geheugen tussen twee aanroepen, geen idee wat er de vorige keer gebeurde.
Alles wat een agent een agent maakt zit in het harnas.
Als je model een motor is, is het harnas de auto. De versnellingsbak, de remmen, het stuur, de dashboardlampjes. Je kunt de motor vervangen. Rijden doe je met de rest.
De acht taken van een harnas
In mijn eigen systeem heb ik dit uit elkaar getrokken omdat het anders niet te debuggen was. Deze acht komen in elk harnas terug, of het nu Claude Code is, Codex CLI, Gemini CLI of iets zelfgebouwds.
1. Context samenstellen. Wat gaat er in het venster? De instructie, ja. Maar ook: welke bestanden, welke eerdere stappen, welke projectregels. Dit is de laag waar de meeste kwaliteit wordt gewonnen of verloren, en waar bijna niemand naar kijkt.
2. Gereedschap aanbieden. Welke functies mag het model aanroepen. Lezen, schrijven, shell, zoeken, een API. De definitie van elk stuk gereedschap is zelf een stukje prompt, en een slecht beschreven tool wordt verkeerd gebruikt.
3. Rechten afdwingen. Mag deze agent naar die map schrijven? Dat commando draaien? Dit is niet hetzelfde als 2. Gereedschap aanbieden is een aanbod, rechten afdwingen is een grens.
Ik heb geleerd dat het verschil groter is dan het lijkt: mijn eigen rolprofielen bleken maandenlang een veld te dragen dat nergens werd gelezen.
4. De lus draaien. Model denkt, roept gereedschap aan, krijgt resultaat, denkt verder. Wanneer stopt dat? Wat als het gereedschap faalt? Wat als het model in een kringetje blijft hangen? Dit is de agent-loop, en de stopvoorwaarden zijn moeilijker dan de lus zelf.
5. Geheugen beheren. Het venster raakt vol. Wat gooi je weg, wat vat je samen, wat bewaar je buiten het venster om later terug te halen. Compaction, in het jargon.
6. Herstellen van fouten. Het model verzint een bestandsnaam. Een API geeft 500. De shell hangt. Een goed harnas onderscheidt een fout die je opnieuw kunt proberen van een fout die je moet melden, en dat onderscheid is verrassend subtiel.
7. Vastleggen wat er gebeurde. Welke stappen, welke aanroepen, welke uitkomst. Zonder dit heb je geen idee waarom iets misging, en bij agents gaat het genoeg mis dat je dat wilt weten.
8. De levenscyclus. Starten, isoleren, opruimen. Waar draait de agent, in welke map, wat gebeurt er met zijn werk als hij omvalt.
Acht taken, en het model doet er nul van.
Waar het in de praktijk misgaat
Wat mij het meest heeft geleerd is niet de theorie maar het patroon in de storingen. Drie vormen kom ik steeds tegen.
De stille lever-fout. Het harnas start een worker, meldt succes, en de instructie is nooit aangekomen. Dat is me in augustus nog overkomen: de agent bootte netjes op, in de juiste map, met de juiste rechten, en bleef daarna op een lege prompt staan. Twee keer.
Vanuit het harnas gezien is er niets fout gegaan. Het proces draait. Alleen doet het niets.
De controle die groen geeft op zijn eigen defect. Een test die meet of iets bestaat in plaats van of het werkt. Een gate die de helptekst van een commando voor de uitvoering aanziet. Een teller die op een verkeerd patroon zoekt en overal nul teruggeeft, netjes, zonder te klagen.
Dit is de gevaarlijkste vorm, want een storing zie je en een fout getal handel je naar.
De laag die een toestand eist zonder deur. Het harnas verlangt een veld dat je nergens kunt zetten. Ik heb er dit jaar drie gehad. Twee daarvan zijn opgelost door alsnog een commando te bouwen; de derde stond half augustus nog open.
Dat klinkt als slordigheid, en dat is het soms. Maar het is ook een structureel gevolg van hoe deze systemen groeien: de leeskant en de schrijfkant worden door verschillende wijzigingen geraakt, en niets dwingt af dat ze elkaar dekken.
Open harnas tegen gesloten harnas
Hier zit voor mij de belangrijkste keuze, en hij wordt zelden expliciet gemaakt.
Claude Code is een gesloten harnas. Codex CLI en Gemini CLI zijn open source, maar door de leverancier gestuurd. Hapert de levering in Claude Code, dan kun je er niets aan doen.
Mijn remedie voor die lege prompt was een regel in mijn eigen documentatie: druk Enter altijd als losse toetsaanslag, want gecombineerd mist de levering.
Dat was geen oplossing. Het was een omweg die ik elke keer opnieuw moest lopen. In september heb ik die hele terminal-route geschrapt. Mijn workers draaien nu headless, zonder toetsaanslagen.
Bij een open harnas kun je die klasse fouten bij de bron repareren, en die keuze bestaat allang. opencode staat op ruim 200.000 sterren onder MIT, Moonshot zet zijn eigen kimi-cli open onder Apache-2.0, en DeepSeek kwam er in augustus 2026 bij. De open kant is dus geen niche meer.
De prijs staat er wel tegenover, en die is niet klein. Een open harnas dat je zelf draait mag Claude alleen via een API-sleutel aanspreken. Anthropic verbiedt abonnement-tokens buiten de eigen tools.
Het platte abonnementsbedrag valt daarmee weg. Voor mij is dat het verschil tussen een vast bedrag per maand en een gemeten variabele die op piekdagen in de honderden loopt.
Hoe je test of jouw harnas deugt
Drie vragen die ik inmiddels standaard stel, en die je in een middag kunt beantwoorden.
Kun je zien wat het model precies zag? Niet de samenvatting achteraf, maar de letterlijke invoer. Bij mij landt elke stap van een worker in een eventlog per opdracht, en de uitkomst in een append-only grootboek. Kun je die vraag niet beantwoorden, dan debug je op gevoel zodra iets misgaat.
Faalt het luid of stil? Zet een verkeerde rolnaam in een opdracht. Wijs naar een bestand dat niet bestaat. Trek de netwerkverbinding eruit halverwege. Krijg je een duidelijke fout, of loopt het door met een stille terugval?
Mijn ervaring: de meeste harnassen vallen stil terug, en de meeste bouwers ontdekken dat pas als het al een tijdje fout ging.
Wat gebeurt er met het werk als de agent omvalt? Staat het in een map die wordt opgeruimd? Is het gepusht? Bij mij geldt een harde volgorde: gerichte tests groen, dan committen, dan pushen, en pas daarna alles wat langzamer is.
Een gepushte branch met een rode testsuite is een gewone toestand. Ongecommit werk in een opgeruimde map is verlies.
Lees ook: opencode en mijn eigen framework: één keuze splitst ze
Waarom dit de moeite is
Het aantrekkelijke aan modellen vergelijken is dat het meetbaar lijkt. Er zijn benchmarks, er zijn scores, er is een ranglijst.
Harnassen vergelijken is vervelender werk, want je moet het gedrag uitlokken in plaats van een getal opzoeken. Maar in negentien maanden productie is geen enkele van mijn dure fouten door het model veroorzaakt. Ze zaten allemaal in de acht taken hierboven.
Een beter model maakt je agent iets slimmer. Een beter harnas maakt hem betrouwbaar, en dat is wat je nodig hebt zodra er iets van waarde doorheen loopt.
Mijn eigen harnas staat open source op GitHub. Niet omdat het af is, wel omdat de acht lagen er zichtbaar uit elkaar zijn getrokken en dat het makkelijkst leest in code.
In een volgende post zet ik het nieuwe open harnas van DeepSeek naast de harnassen die je waarschijnlijk dagelijks gebruikt, en beschrijf ik wat ik ervan overneem.
Wil je weten hoe het harnas rond jouw AI-systemen in elkaar zit? Zo pak ik dat aan bij bedrijven die AI inzetten.