Anthropic's Agent Harness-ontwerp veranderde mijn kijk op AI-systemen

Ik was vier uur lang aan het kijken hoe een AI een digitale audio-werkstation bouwde. Geen speelgoeddemo — een browsergebaseerde DAW met de Web Audio API, multi-track editing en een golfvormvisualisatie. De agent had de hele tijd autonoom gedraaid. Geen handje vasthouden. Geen tussentijdse correcties. Gewoon een AI die feature na feature doorwerkte, code committede, zijn eigen werk testte en doorging.

Toen stopte het.

Niet omdat het crashte. Niet omdat de context op was. Het stopte omdat een aparte AI — de evaluator — aangaf dat de audiotiming 12 milliseconden afweek en dat de golfvormrendering niet overeenkwam met de werkelijke frequentiedata. De generator-agent ging terug, loste beide problemen op en diende opnieuw in. De evaluator testte het een tweede keer, bevestigde de fixes en gaf groen licht voor de sprint.

Die interactie — twee AI-agents die discussiëren over kwaliteit als een developer en een QA-engineer — vormt de kern van wat Anthropic publiceerde in hun harness-ontwerp voor langlopende applicatieontwikkeling. En het heeft mijn denken over het bouwen van autonome systemen volledig herschreven.

Het model is niet het product. De harness is het product.

Waarom je AI-agent blijft falen bij complexe taken

Hier is een patroon dat ik tientallen keren heb meegemaakt. Je geeft een AI-agent een complex project — bouw een full-stack app, refactor een grote codebase, maak een multi-page design system. De agent begint sterk. De eerste 20 minuten zien er veelbelovend uit. Dan gaat het ergens rond de 45 minuten mis. Stappen worden overgeslagen. De kwaliteit daalt. De agent verklaart het project "af" terwijl het misschien 60% klaar is.

Ik gaf altijd het model de schuld. "Sonnet is niet slim genoeg hiervoor." "Ik heb betere prompts nodig." "Het context window is te klein."

Het onderzoek van Anthropic draaide die diagnose volledig om. Het model was zelden de bottleneck. De harness was het probleem.

Een agent harness is het softwareframework dat om een AI-model heen zit — het beheert prompts, orkestreert tools, handhaaft beperkingen, regelt feedbackloops en valideert output. Zie het zo: het AI-model is een motor. Rauw vermogen. De harness is de auto. Stuurwiel, remmen, versnellingsbak, navigatie. Zonder de auto staat de motor gewoon op een werkbank herrie te maken.

Dit onderscheid is belangrijker dan de meeste AI-engineers beseffen. Je kunt een V6 vervangen door een V8 (Sonnet door Opus), en je krijgt incrementele verbetering. Maar herontwerp de auto — verander hoe de motor met de wielen verbonden is, voeg een navigatiesysteem toe, installeer betere remmen — en de hele rijervaring transformeert.

Dat is wat Anthropic heeft aangetoond. Geen beter model. Een beter systeem rondom het model. En de resultaten waren zo indrukwekkend dat ik binnen een week na het lezen van hun paper mijn eigen agent-workflows had herbouwd.

Maar voordat ik inga op wat ze hebben gebouwd, moet je begrijpen wat er überhaupt steeds misgaat — want deze faalpatronen zitten verborgen in elk langlopend agent-systeem dat ik heb gezien, inclusief systemen die ik zelf heb gebouwd.

De twee faalpatronen waar niemand eerlijk over praat

Anthropic identificeerde twee kritieke faalpatronen bij langlopende agents. Ik heb ze beide zo vaak meegemaakt dat het lezen van hun analyse voelde alsof iemand camera's in mijn ontwikkelomgeving had geïnstalleerd.

Context-angst: wanneer je agent in paniek raakt

Context-angst is wat er gebeurt wanneer een AI-model aanvoelt dat het de grenzen van zijn context window nadert. Het gedrag is subtiel en verraderlijk. De agent crasht niet. Er komt geen foutmelding. In plaats daarvan begint het te haasten. Stappen worden samengeperst. Uitleg wordt kort en bondig. Complexe subtaken die zorgvuldige planning vereisen, worden weggewuifd. De agent begint voortijdig af te ronden — roept de overwinning uit over een halfaf project omdat een intern signaal schreeuwt "je ruimte raakt op."

Ik merkte dit voor het eerst op bij Sonnet 4.5 tijdens een refactoring-project. Rond het 80K-tokenspunt verschoof de agent van zorgvuldig, methodisch werk naar wat ik alleen kan omschrijven als angstig speedrunnen. Het stopte met het lezen van bestanden voordat het ze bewerkte. Het sloeg testruns over. Het begon commentaar te geven als "de overige items zijn eenvoudig en volgen hetzelfde patroon" — wat in agent-taal betekent: "ik geef op en hoop dat je het niet merkt."

De oplossing van Anthropic omvat twee complementaire technieken.

Context-compactie vat de gespreksgeschiedenis samen en comprimeert deze, waarbij essentiële informatie behouden blijft terwijl tokenruimte vrijkomt. De AI schrijft in feite een gecomprimeerde briefing voor zichzelf van alles wat er tot dusver is gebeurd, en werkt dan vanuit die briefing in plaats van de ruwe geschiedenis. Het is lossy — sommige details gaan verloren — maar een goede compactiestrategie behoudt de kritieke beslissingen en de huidige status.

Context-resets gaan verder. In plaats van de bestaande context te comprimeren, geef je de agent een volledig nieuw context window voor elke sprint of subtaak. De agent begint schoon, met alleen de informatie die nodig is voor het huidige onderdeel. Voortgang leeft niet in het geheugen van het model — het leeft in bestanden, git-commits en gestructureerde artefacten op schijf.

Hier is de doorbraak die ertoe doet voor bouwers: Opus 4.6 met zijn 1 miljoen token context window heeft context-angst grotendeels geëlimineerd als praktisch probleem. Het window is zo enorm dat de meeste multi-uur autonome sessies er nooit in de buurt komen het te vullen. Anthropic ontdekte dat ze context-resets volledig konden laten vallen met Opus 4.6 en alleen op compactie konden vertrouwen. Wat vroeger een complex multi-sessie overdrachtsysteem vereiste, draait nu als één doorlopende sessie.

Dat betekent niet dat contextbeheer voor altijd opgelost is. Druk Opus 4.6 hard genoeg — een volledige dag autonome sessie met uitgebreid bestanden lezen — en je bereikt limieten. Maar de drempel verschoof van "een serieus probleem na 45 minuten" naar "een randgeval na 6+ uur." Voor de meeste praktijktaken is dat het verschil tussen wel of geen harness-workaround nodig hebben.

Zelf-evaluatiefalen: de agent die denkt dat alles wat hij maakt geweldig is

De tweede faalpatroon is gevaarlijker omdat het moeilijker te detecteren is.

Wanneer je een AI-agent vraagt om zijn eigen werk te evalueren, liegt het. Niet opzettelijk — maar consistent. Het patroon is voorspelbaar: de agent genereert output, beoordeelt het en concludeert dat de output goed is. Zelfs wanneer, voor een menselijke waarnemer, de kwaliteit duidelijk middelmatig is.

Ik heb dit in realtime zien gebeuren. Een agent bouwt een landingspagina met verkeerd uitgelijnde elementen, inconsistente spacing en een kleurenschema dat eruitziet alsof het door een willekeurige getallengenerator is gekozen. Je vraagt de agent het resultaat te evalueren. "Het ontwerp is strak en professioneel, met goede visuele hiërarchie en consistente spacing." Het beschrijft het ontwerp dat het van plan was te bouwen, niet het ontwerp dat het daadwerkelijk heeft gebouwd.

Dit is geen promptingprobleem. Je kunt "wees kritisch" en "zoek naar gebreken" aan de systeemprompt toevoegen, en de agent zal knikken, doen alsof het kritisch is, en vervolgens zijn eigen werk goedkeuren met een paar symbolische kanttekeningen. "Hoewel er ruimte voor verbetering is in het kleurenpalet, communiceert het algehele ontwerp effectief de merkboodschap." Vertaling: "Ik doe alsof ik kritisch ben terwijl ik niets verander."

De diagnose van Anthropic is bot en, naar mijn ervaring, accuraat: een generator zelfkritisch maken is een fundamenteel moeilijker probleem dan het bouwen van een aparte, dedicated criticus. De architecturale oplossing is niet om de generator beter te maken in zelfevaluatie. Het is om de rollen volledig te scheiden.

Wat ons brengt bij de architectuur die daadwerkelijk werkt.

De drie-agent architectuur: Planner, Generator, Evaluator

Het uiteindelijke harness-ontwerp van Anthropic gebruikt drie gespecialiseerde agents die samenwerken. Als je ooit in een team hebt gewerkt met een product manager, een developer en een QA-engineer — dan zal dit herkenbaar aanvoelen. Want dat is precies de dynamiek die ze hebben gerepliceerd.

De Planner

De Planner neemt een eenvoudige prompt — "bouw een projectmanagement-app met een Kanban-bord" — en werkt deze uit tot een gedetailleerde productspecificatie. Featurelijsten. User stories. Technische vereisten. Visuele ontwerprichting.

De Planner is bewust ambitieus. Anthropic ontdekte dat conservatieve planning tot ondermaatse resultaten leidde. Wanneer de Planner hoog mikte, produceerde de Generator creatievere, completere applicaties — zelfs als niet elk doel werd bereikt. Een specificatie die vraagt om "een prachtige, museumwaardige interface met 3D-elementen" levert betere resultaten op dan een die vraagt om "een strakke, functionele UI." De hoge lat trekt de output omhoog.

Iets wat Anthropic op de harde manier leerde: de Planner moet zich richten op wat en waarom, niet op hoe. Wanneer de Planner gedetailleerde technische implementatiedetails opnam, cascadeerden die details fouten door het werk van de Generator. Een Planner die zegt "implementeer real-time samenwerking" is beter dan een die zegt "gebruik WebSockets met een pub/sub-patroon op Redis" — omdat de Generator mogelijk een betere aanpak vindt die de premature specificiteit van de Planner zou hebben voorkomen.

De Generator

De Generator werkt in sprints en implementeert één feature per keer. Elke sprint heeft een duidelijke scope afgeleid van de specificatie van de Planner, en de Generator commit code incrementeel — wat betekent dat voortgang bewaard blijft in git, ongeacht wat er met de context van de agent gebeurt.

Deze sprintgebaseerde aanpak is waar ik de sterkste parallel zie met hoe ik Claude Code al gebruik. Wanneer ik werk met de agent swarm-architectuur van Claude Code, geldt hetzelfde principe: splits complex werk op in discrete brokken, maak voortgang zichtbaar via artefacten (bestanden, commits, taakgrafieken) en vertrouw nooit op het geheugen van het model als bron van waarheid.

De Generator bevat ook een ingebouwde zelfevaluatiestap voordat het overdraagt aan de Evaluator — een snelle sanity check. Dit vangt de voor de hand liggende problemen op (syntaxfouten, ontbrekende imports, kapotte builds) zonder op de Evaluator te vertrouwen voor zaken die de Generator zelf zou moeten opvangen. Zie het als een developer die zijn eigen tests draait voordat hij een PR opent. Je hebt nog steeds code review nodig, maar je zou de tijd van de reviewer niet moeten verspillen aan problemen die je linter al zou opvangen.

De Evaluator: waar de echte innovatie zit

De Evaluator is wat deze architectuur werkelijk anders maakt dan alles wat ik eerder heb gebouwd.

De meeste AI-evaluatiesystemen beoordelen code statisch — ze lezen de bronbestanden, analyseren de structuur en geven feedback. Anthropic's Evaluator leest niet alleen code. Het gebruikt de applicatie. Via Playwright-browserautomatisering navigeert de Evaluator door de draaiende applicatie, klikt op knoppen, vult formulieren in, maakt screenshots, test API-endpoints en onderzoekt databasestatussen. Het interageert met het live product zoals een menselijke QA-engineer dat zou doen.

De evaluatiecriteria zijn ook niet vaag. Anthropic definieerde vier specifieke dimensies:

Ontwerpkwaliteit — Voldoet de visuele output aan professionele standaarden? Layout, typografie, kleur, spacing — gemeten aan de specificatie van de Planner, niet aan abstracte idealen.

Originaliteit — Ziet de output eruit als generieke AI-rommel, of heeft het een echte creatieve identiteit? Dit criterium bestaat specifiek om het "alles wat AI bouwt ziet er hetzelfde uit"-probleem te bestrijden. Toen ik dit las, dacht ik meteen aan de AI design systems-gids die ik schreef — het probleem dat AI-gegenereerde interfaces allemaal convergeren naar dezelfde esthetiek is reëel, en Anthropic beoordeelt er expliciet op.

Vakmanschap — Kwaliteit van technische uitvoering. Schone code, goede foutafhandeling, responsieve layouts, performance. De dingen die een senior engineer zou opmerken tijdens code review.

Functionaliteit — Werkt de feature daadwerkelijk? Niet "ziet de code er correct uit" — doet de knop wat hij hoort te doen wanneer je erop klikt?

De Evaluator beoordeelt elke sprint aan de hand van deze criteria. Als de scores niet aan de drempel voldoen, gaat de Generator terug en itereert. Dit creëert een feedbackloop die structureel identiek is aan hoe GAN's (Generative Adversarial Networks) werken — een generator die output probeert te produceren die de discriminator misleidt, en een discriminator die beter wordt in het opsporen van tekortkomingen.

Wat mij verraste: het goed krijgen van de Evaluator vergde meerdere iteraties. Anthropic's eerste Claude-gebaseerde evaluators hadden hetzelfde probleem als zelfevaluatie — ze waren te mild. Ze keurden middelmatig werk goed met bemoedigende feedback. Er was bewuste prompt engineering nodig om de Evaluator echt tegendraads te maken. Een sceptische systeemprompt. Expliciete instructies om te zoeken naar specifieke soorten fouten. Toestemming om werk af te wijzen en revisies te eisen.

Dit is het kerninsight waar ik steeds op terugkom: het afstemmen van een dedicated evaluator om sceptisch te zijn is een fundamenteel beter hanteerbaar probleem dan een generator zelfkritisch maken. De evaluator heeft één taak — problemen vinden. De generator heeft een tegenstrijdig belang — het wil klaar zijn. Het scheiden van deze rollen is niet alleen goede architectuur. Het is noodzakelijk.

Het sprintcontract: Generator en Evaluator afstemmen voordat het werk begint

Eén detail uit Anthropic's ontwerp dat ik elders niet genoeg besproken zie, is het sprintcontract.

Voordat elke sprint begint, onderhandelen de Generator en Evaluator een contract. De Generator stelt voor wat het zal opleveren. De Evaluator bevestigt dat het de acceptatiecriteria begrijpt. Beide agents zijn het eens over wat "af" betekent voordat er ook maar één regel code wordt geschreven.

Dit klinkt bureaucratisch. Dat is het niet. Het is het verschil tussen een PR die bij de eerste review wordt goedgekeurd en een die vijf keer heen en weer gaat omdat de developer en reviewer verschillende verwachtingen hadden.

Zonder het contract heb ik evaluator-agents werk zien afwijzen omdat het niet voldeed aan standaarden die nooit waren gecommuniceerd. De Generator bouwt een feature op één manier, de Evaluator wilde het op een andere manier, en de iteratieloop verbrandt tokens met discussies over vereisten die vooraf hadden moeten worden afgestemd.

Het contract lost dit op door verwachtingen expliciet te maken. "Sprint 3 zal de level-editor implementeren met drag-and-drop sprite-plaatsing, een tegelenpalet van minimaal 20 items en undo/redo-ondersteuning. De Evaluator zal de functionaliteit verifiëren door een testlevel te maken, sprites te plaatsen en te bevestigen dat undo werkt voor minimaal 5 opeenvolgende acties."

Die specificiteit — het benoemen van exacte acceptatietests — elimineert een hele categorie verspilde iteraties. En het is een patroon dat ik ben gaan overnemen voor mijn eigen agent-workflows, zelfs buiten Anthropic's harness-ontwerp.

Wat de experimenten daadwerkelijk lieten zien

Theorie is één ding. Anthropic voerde drie experimenten uit die deze architectuur onder echte druk zetten. De resultaten vertellen verschillende verhalen, afhankelijk van welk experiment je bekijkt.

Experiment 1: De website van het Nederlandse kunstmuseum

De opdracht: ontwerp een website voor een fictief Nederlands kunstmuseum. Dit is een subjectieve, designzware uitdaging waarbij "goed" moeilijk te definiëren en nog moeilijker te evalueren is.

De harness doorliep meer dan 10 feedbackiteraties tussen de Generator en Evaluator. Vroege versies waren generiek — het soort sjabloonachtige pagina's dat elke AI produceert. Rond iteratie 7 of 8 was het ontwerp geëvolueerd tot iets werkelijk ongewoons: een 3D-ruimtevisualisatie met een geblokte vloer, kunstwerken die op virtuele muren hingen en navigatie die aanvoelde als wandelen door een galerie.

Het punt is niet dat het uiteindelijke ontwerp perfect was. Het is dat de iteratieve tegengestelde loop de output voorbij het "goed genoeg"-plateau duwde dat single-pass AI-generatie altijd bereikt. De Generator bleef naar creatievere oplossingen reiken omdat de Evaluator de veilige opties bleef afwijzen. Die dynamiek — druk om standaarden te overtreffen, niet alleen te halen — ontstaat niet wanneer een agent zichzelf evalueert.

Experiment 2: De 2D Retro Game Maker

Dit was het meest veelzeggende experiment. Twee runs van dezelfde opdracht: bouw een 2D retro game maker met een level-editor, sprite-editor en gedragssysteem.

Run 1 (solo harness — alleen Generator): De output zag er visueel acceptabel uit op screenshots. Maar wanneer je het daadwerkelijk probeerde te gebruiken, werkte het spel niet. Sprites bewogen niet. De level-editor kon geen levels opslaan. Het was een Potemkin-dorp van een game maker — presentabel van buiten, hol van binnen.

Run 2 (volledige harness — Planner + Generator + Evaluator): De Planner maakte gedetailleerde specificaties met expliciete definities van "af" voor elke sprint. De Evaluator testte elke feature interactief met Playwright en ving functionele fouten op die de Generator als "af" zou hebben verklaard. Het resultaat: een werkende game maker. Geen AAA-kwaliteit, maar functioneel. Je kon sprites maken, levels bouwen, gedrag toewijzen en het resultaat daadwerkelijk spelen.

Het verschil tussen deze twee runs is het complete argument voor harness engineering in één voorbeeld. Hetzelfde model. Dezelfde opdracht. Hetzelfde rekenbudget. Het enige verschil was het systeem dat om het model heen was gebouwd.

Experiment 3: De browser-DAW

De meest ambitieuze test: bouw een digitale audio-werkstation in de browser met de Web Audio API, draaiend op Opus 4.6.

Dit experiment werd in ongeveer 4 uur afgerond voor een kostprijs van ruwweg $125 aan API-aanroepen. Het resultaat was functioneel — multi-track audio, golfvormvisualisatie, basisbewerkingen — maar niet van professioneel niveau. Belangrijker nog, dit experiment demonstreerde hoe modelverbeteringen harness-vereisten vereenvoudigen.

Met Opus 4.6's context window van een miljoen tokens liet Anthropic sprints volledig vallen. Geen context-resets. Geen contractonderhandeling tussen Generator en Evaluator. Gewoon één doorlopende sessie met automatische compactie die contextgroei afhandelde. De harness die Sonnet 4.5 nodig had — complex, multi-sessie, zorgvuldig contextgrenzen beheerend — werd overbodig.

Dit is de belangrijkste les voor bouwers: je harness-aannames moeten mee-evolueren met het model. Een harness ontworpen voor de beperkingen van Sonnet 4.5 zal de orkestratielaag over-engineeren wanneer het op Opus 4.6 draait. En een harness ontworpen voor de mogelijkheden van Opus 4.6 zal breken wanneer het volgende model nieuw gedrag introduceert of oud gedrag elimineert. Harness engineering is geen eenmalige setup. Het is een doorlopende praktijk.

Als je liever hebt dat iemand dit soort multi-agent harness-systeem voor jouw use case bouwt, neem ik custom AI-agent ontwikkelopdrachten aan. Je kunt zien wat ik heb gebouwd op fiverr.com/s/EgxYmWD.

Hoe dit aansluit bij patronen die je al kent

Anthropic's harness-ontwerp bestaat niet in een vacuüm. Het staat naast twee andere patronen die elke serieuze agent-bouwer zou moeten begrijpen — omdat ze aangrenzende stukken van dezelfde puzzel oplossen.

De Ralph Wiggum Loop

Gemaakt door Geoffrey Huntley en geformaliseerd door Boris Cherny (Anthropic's Head of Claude Code) eind 2025, is de Ralph Wiggum Loop elegant in zijn eenvoud. Je draait een agent in een bash-loop. Na elke iteratie controleer je de output tegen iets dat niet kan liegen — een linter, een type checker, een testsuite. Als het slaagt, stop je. Als het faalt, loop je opnieuw.

Het kerninsight: voortgang leeft in bestanden en git-geschiedenis, niet in het context window van het model. Elke iteratie begint met een frisse context. De agent leest de huidige staat van de codebase, werkt eraan en commit wijzigingen. Als de loop moet doorgaan, leest de volgende iteratie de bijgewerkte bestanden met nul geaccumuleerde context-schuld.

Dit patroon is inmiddels een eersteklas plugin in Claude Code zelf. Je kunt /ralph-loop "Fix all TypeScript errors" --max-iterations 20 --completion-promise "ALL_FIXED" uitvoeren en weglopen.

Waarin de Ralph Wiggum Loop verschilt van Anthropic's drie-agent harness: het werkt het best voor objectief verifieerbare taken. "Los alle lintfouten op" heeft een binaire grondwaarheid — de linter slaagt of niet. "Bouw een mooie, functionele game maker" heeft dat niet. Die subjectieve kloof is precies wat de tegengestelde evaluator opvult.

Spec-gedreven ontwikkeling

Het derde puzzelstuk is het structureren van vereisten voordat de agent begint met coderen. Frameworks zoals GitHub's Spec Kit, BMAD-METHOD en OpenSpec lossen allemaal hetzelfde probleem op: agents die beginnen met coderen voordat ze begrijpen wat ze aan het bouwen zijn.

Dit komt direct overeen met de Planner-agent in Anthropic's ontwerp. De Planner is in essentie een geautomatiseerde spec-schrijver. Maar je hebt geen dedicated Planner-agent nodig om het voordeel te krijgen. Het schrijven van een duidelijke spec — features, acceptatiecriteria, definitie van af — voordat je werk overdraagt aan een agent levert dramatisch betere resultaten op dan een vage prompt naar een model gooien en op het beste hopen.

De spec-gedreven aanpak verklaart ook waarom het game maker-experiment zulke verschillende resultaten liet zien tussen solo en volledige harness runs. De solo run had geen spec. De agent verzon het gaandeweg, schroefde ambities terug bij elke stap totdat "game maker" werd tot "enkele UI-elementen die game-gerelateerd lijken." De volledige harness run had een expliciete spec met definities van af — en een evaluator die ze handhaafde.

Ik gebruik een versie hiervan in mijn eigen werk sinds ik de Anthropic Agent SDK-gids schreef. Elke complexe agent-taak begint nu met een geschreven spec. Niet omdat de agent niet zonder kan werken — maar omdat de spec het anker is dat scope drift, voortijdige afronding en het langzame sterven van ambitie voorkomt dat elke langlopende AI-sessie teistert.

Wat dit betekent voor hoe je nu agents bouwt

Hier wil ik praktisch zijn. Anthropic's onderzoek is gebouwd op de Claude Agent SDK, maar de principes gelden ongeacht welk model of framework je gebruikt. Als je iets bouwt dat langer dan 15 minuten autonoom draait, is dit wat ik uit dit werk zou meenemen.

Scheid generatie van evaluatie. Altijd.

Dit is de enkele verandering met de hoogste hefboomwerking die je kunt aanbrengen in elke agent-workflow. Als je agent output genereert en die output evalueert in dezelfde context, heb je een betrouwbaarheidsprobleem. Het manifesteert zich misschien niet bij eenvoudige taken. Maar zodra de complexiteit toeneemt — multi-bestand wijzigingen, subjectieve kwaliteitseisen, feature-afhankelijkheden — faalt zelfevaluatie stilletjes.

Je hebt geen geavanceerd tegendraads systeem nodig om te beginnen. Een tweede agent met een sceptische systeemprompt die de output van de eerste agent beoordeelt, is genoeg om de meest flagrante zelfgoedkeuringsfouten op te vangen. Ik draai een versie hiervan in mijn contentpipeline, en de evaluator wijst ruwweg 30% van de eerste concepten af — concepten die, ongecontroleerd, zouden zijn verscheept met structurele problemen die ik bij handmatige review zou opvangen.

Gebruik artefacten, niet geheugen, als je bron van waarheid

Elk stukje voortgang zou buiten het context window van het model moeten bestaan. Git-commits. JSON-taakbestanden. Markdown-specs. Gestructureerde logs. Als de sessie van je agent crasht en het enige bewijs van wat er is gebeurd in de gespreksgeschiedenis leeft — dan heb je een fragiel systeem gebouwd.

Dit is hetzelfde principe achter de persistente taakgraaf-architectuur van Claude Code. De taakgraaf leeft op schijf. Agents lezen het, werken het bij en schrijven ernaar terug. Context windows komen en gaan. De taakgraaf blijft bestaan.

Stem je harness-complexiteit af op de mogelijkheden van je model

Anthropic's eigen evolutie bewijst dit punt. De harness die ze bouwden voor Sonnet 4.5 — met context-resets, sprintgrenzen, contractonderhandeling — was noodzakelijk omdat het model het nodig had. De harness die ze bouwden voor Opus 4.6 liet de helft van die componenten vallen omdat het context window van een miljoen tokens en de verbeterde consistentie van het model ze overbodig maakten.

Audit je eigen harness. Draai je complexe contextbeheersystemen omdat het model dat daadwerkelijk nodig heeft, of omdat je het systeem zes maanden geleden hebt ontworpen toen het model het wel nodig had? Over-engineering van de orkestratielaag verspilt tokens, voegt latentie toe en introduceert faalpunten die het huidige model gewoon zelf zou kunnen afhandelen.

Definieer "af" voordat je begint

Het sprintcontract-patroon — waarbij Generator en Evaluator het eens worden over acceptatiecriteria voordat het werk begint — is van toepassing op elke agent-interactie, niet alleen multi-agent systemen. Wanneer je een agent prompt om "een dashboard te bouwen," definieer wat het dashboard moet bevatten, hoe je elke feature verifieert en welke kwaliteitslat je verwacht. Hoe explicieter je definitie van af, hoe minder ruimte de agent heeft om voortijdig de overwinning uit te roepen.

De eerlijke beperkingen: wat harness-ontwerp niet kan oplossen

Ik zou je een slechte dienst bewijzen als ik je liet vertrekken met het idee dat harness engineering een wondermiddel is. Dat is het niet. Na weken van het implementeren van deze patronen zijn dit de muren waar ik tegenaan ben gelopen.

Kosten lopen snel op. Het browser-DAW-experiment kostte $125 aan API-aanroepen voor ~4 uur autonoom werk. Een drie-agent systeem verbruikt ruwweg 3x de tokens van een single-agent aanpak omdat je drie modellen (of drie sessies van hetzelfde model) gecoördineerd draait. Voor hobbyprojecten en experimenten is dit prima. Voor productiesystemen die 24/7 draaien, moeten de economische aspecten zorgvuldig worden gemodelleerd.

Evaluator-kwaliteit is het plafond. Je systeem kan slechts zo goed zijn als het vermogen van je evaluator om problemen te detecteren. Als de evaluator een subtiele UI-misuitlijning of een race condition in asynchrone code niet kan identificeren, worden die problemen meegeleverd. Anthropic erkende dit — hun eerste evaluators misten subtiele bugs en keurden oppervlakkige implementaties goed. De evaluator goed krijgen vergde iteratie, niet alleen prompt-tweaking.

Subjectieve kwaliteit blijft moeilijk. Het Nederlandse museumexperiment toonde indrukwekkende verbetering door tegendraadse iteratie. Maar "indrukwekkend voor AI" en "indrukwekkend vergeleken met een menselijke ontwerper met 10 jaar ervaring" zijn verschillende maatstaven. Harness-ontwerp verkleint die kloof. Het sluit hem niet. Voor subjectief creatief werk — design, schrijven, muziek — blijft menselijke evaluatie noodzakelijk in de laatste fase.

Harness-debugging is een vaardigheid op zich. Wanneer een enkele agent slechte output produceert, is debuggen eenvoudig: lees het gesprek, vind waar het misging, pas de prompt aan. Wanneer een drie-agent systeem slechte output produceert, kan de fout in de spec van de Planner zitten, in de implementatie van de Generator, in de criteria van de Evaluator, of in de interactie tussen twee van hen. Ik heb meer tijd besteed aan het debuggen van harness-interacties dan ik ooit heb besteed aan het debuggen van individuele agent-prompts.

Dit zijn echte beperkingen. Ze ontkrachten de aanpak niet — het game maker-experiment bewijst dat de drie-agent architectuur dramatisch betere resultaten produceert dan solo-generatie. Maar ze betekenen dat harness engineering een praktijk is die iteratie, monitoring en continue verfijning vereist. Niet een patroon dat je één keer implementeert en vergeet.

Waar dit naartoe gaat

Anthropic publiceerde twee artikelen over dit onderwerp — het eerste in november 2025 gericht op het initializer-en-coding-agent patroon, en de follow-up van maart 2026 introduceerde de volledige drie-agent architectuur met tegendraadse evaluatie. De trajectory vertelt je waar dit naartoe gaat.

Modelverbeteringen vereenvoudigen harness-ontwerp. Opus 4.6 elimineerde de noodzaak van context-resets. De volgende generatie elimineert misschien de noodzaak van expliciete context-compactie. Maar modelverbeteringen elimineren niet de noodzaak van orkestratie en evaluatie. Zelfs een hypothetisch perfect model — een met oneindig context, perfect geheugen en nul redeneerfouten — zou nog steeds betere output produceren met een aparte evaluator die zijn werk uitdaagt. Dat is geen modelbeperking. Dat is een fundamenteel inzicht over hoe kwaliteit ontstaat uit tegendraadse druk.

De praktische voorspelling die ik zou doen: binnen 12 maanden zullen harness-as-a-service platformen net zo gebruikelijk zijn als RAG-as-a-service platformen dat vandaag zijn. Tools zoals Vercel's Ralph Loop Agent en het groeiende ecosysteem rondom spec-gedreven ontwikkelingsframeworks zoals GitHub's Spec Kit zijn vroege signalen. Het ruwe materiaal — modellen, tool-use mogelijkheden, evaluatie-API's — is al productierijp. Wat ontbreekt is de verpakte orkestratielaag die het toegankelijk maakt voor engineers die geen harness-infrastructuur vanaf nul willen bouwen.

Voor bouwers die nu in deze ruimte werken, is de kans duidelijk. De harness is het product. Het model is een commodity. De teams en engineers die goed worden in harness-ontwerp — die leren taken te decomponeren, betrouwbare evaluators te bouwen, context effectief te beheren en hun orkestratiepatronen mee te laten evolueren met modelverbeteringen — zullen AI-systemen bouwen die in productie werken terwijl alle anderen nog worstelen met single-agent prompts die na 30 minuten uit elkaar vallen.

Die DAW-sessie die ik bekeek? Vier uur autonoom coderen dat een functionele applicatie opleverde. Niet omdat het model magisch was. Omdat het systeem eromheen was ontworpen om het model eerlijk te houden, gefocust te houden en te laten itereren totdat het werk daadwerkelijk af was.

Dat is de les. Niet betere AI. Betere systemen rondom AI.

Veelgestelde vragen

Wat is een agent harness in AI-ontwikkeling?

Een agent harness is het softwareframework dat om een AI-model heen zit om prompts, tools, feedbackloops en validatie te beheren — en een rauw model om te vormen tot een betrouwbaar autonoom systeem. Zie het als de auto die de motor bruikbaar maakt: stuurwiel, remmen, navigatie en alles eromheen. Voor een uitgebreidere uitleg, zie de sectie "Waarom je AI-agent blijft falen" hierboven.

Hoe beïnvloedt context-angst AI-agents?

Context-angst treedt op wanneer AI-modellen aanvoelen dat ze de grenzen van het context window naderen en beginnen te haasten, stappen overslaan of taken voortijdig als afgerond verklaren. Sonnet 4.5 vertoonde dit gedrag rond 80K tokens. Opus 4.6's context window van een miljoen tokens elimineert dit probleem grotendeels voor sessies onder de 6 uur. Zie de sectie over faalpatronen voor mitigatiestrategieën.

Wat is het verschil tussen context-compactie en context-reset?

Context-compactie vat de gespreksgeschiedenis samen om tokenruimte vrij te maken terwijl belangrijke informatie bewaard blijft — lossy maar doorlopend. Context-reset start de agent met een volledig nieuw context window voor elke subtaak, waarbij bestanden en artefacten voor de state zorgen. Nieuwere modellen met grotere context windows geven de voorkeur aan compactie boven resets.

Hoe verbetert tegendraadse evaluatie de output van AI-agents?

Tegendraadse evaluatie scheidt contentgeneratie van kwaliteitsbeoordeling met behulp van twee afzonderlijke agents — geïnspireerd door de GAN-architectuur. De evaluator-agent gebruikt tools zoals Playwright om draaiende applicaties interactief te testen, waardoor functionele fouten worden opgespoord die bij code review alleen worden gemist. Experimenten van Anthropic toonden aan dat dit werkende applicaties oplevert waar solo-generatie visueel vergelijkbare maar niet-functionele output produceert.

Kan ik agent harness-patronen implementeren zonder de Claude Agent SDK?

Ja. De principes — taakdecompositie, artefact-gebaseerde state, gescheiden evaluatie, sprintcontracten — zijn model-agnostisch en framework-agnostisch. De Claude Agent SDK biedt handige abstracties, maar je kunt dezelfde patronen implementeren met elke model-API, een Python-orkestratielaag en standaardtools zoals Playwright voor evaluatie.

Laten we samenwerken

Wil je AI-systemen bouwen, workflows automatiseren of je technische infrastructuur opschalen? Ik help je graag.

• Fiverr (maatwerk builds & integraties): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise oplossingen): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (beveiligingsdiensten): xcybersecurity.io