Vervang GPT-5 door Claude in een werkende agent en in de meeste gevallen verandert er nauwelijks iets. Verander hoe hij omgaat met herhalingspogingen, wat je in zijn contextvenster stopt of wanneer hij besluit te stoppen, en de hele agent gedraagt zich anders. Die kloof is het signaal: het model is het kleinste en meest vervangbare onderdeel van een werkende agent. De interessante engineering zit in alles wat eromheen zit.
Die wrapper heeft nu een naam. Practitioners kozen voor "harness" voor de laag die een tekstgenerator omzet in iets dat na verloop van tijd acties onderneemt in plaats van een vast script uitvoert. De term verspreidde zich begin 2026 snel op Twitter en engineering-blogs, wat ook betekent dat hij losjes gebruikt werd, waarbij hetzelfde woord in elk bericht dat je leest iets anders doet. Dit artikel legt het vast: wat een harness is, waaruit hij bestaat, hoe hij verschilt van een "framework" en een "scaffold", en waarom het grootste deel van de kwaliteit van je agent verborgen zit in de harness, niet in het model.
De korte versie
- Een agent harness is de software rondom een LLM die de uitvoeringsloop, tools, geheugen, context, toestand, foutafhandeling en vangrails beheert. Het model genereert tekst; het harness beslist wat het model ziet, wat het kan doen, wanneer te stoppen en wat er gebeurt als er iets stukgaat.
- In productie is de modelaanroep vaak het kleinste zichtbare deel van het systeemoppervlak. Een zwakker model in een goed gebouwde harness kan een sterker model in een slordige verslaan, vooral bij langlopende, toolintensieve taken.
- Een harness heeft ruwweg negen tot elf terugkerende componenten. De meeste ervan zijn dingen die het model nooit direct aanraakt.
- "Harness" is niet hetzelfde als "framework". Een framework (LangGraph, een agents SDK) is de bibliotheek waarmee je bouwt; het harness is de draaiende laag die die bibliotheek je helpt samen te stellen.
Wat is een Agent Harness?
Een agent harness is de software-infrastructuur rondom een taalmodel die de uitvoeringsloop, toegang tot tools, geheugen, context, toestandspersistentie, foutafhandeling en vangrails beheert. Het model genereert tekst. Het harness beslist wat het model elke beurt ziet, welke acties het kan ondernemen, wanneer het stopt en wat er gebeurt als een stap mislukt.
De duidelijkste formulering komt van LangChain, die het terugbrengt tot een vergelijking: Agent = Model + Harness. Het model levert de intelligentie. De harness is wat die intelligentie in staat stelt om daadwerkelijk iets in de wereld te doen.
"Een harness is elk stuk code, configuratie en uitvoeringslogica dat niet het model zelf is."
— LangChain, De anatomie van een agent harness
Ik vind de grens het gemakkelijkst te voelen via één vraag: wanneer je agent iets verkeerds doet, was dan de eigen redenering van het model onjuist, of gaf het systeem eromheen het model de verkeerde context, de verkeerde tools, of geen manier om te herstellen? Meestal is het in een echt systeem het tweede. Het model redeneerde goed over slechte invoer. De harness controleert de invoer.
Kernpunt: Het model genereert; de harness bestuurt. Die splitsing is het hele concept.
Wat zijn de componenten van een agent harness?
Elke productie-harness assembleert dezelfde terugkerende onderdelen: een uitvoerlus die het model beurt voor beurt aanstuurt, tooltoegang waarmee het kan handelen, geheugen over beurten heen, contextbeheer voor wat het nu ziet, toestandspersistentie zodat werk sessies overleeft, foutafhandeling voor mislukte stappen en vangrails die beperken wat het kan doen. Productiesystemen voegen verificatielusvs en subagent-orkestratie toe.
Een nuttige inventaris, samengesteld uit hoe beoefenaars echte systemen beschrijven:
- Uitvoerings- / controlloop: wat de agent beurt voor beurt aanstuurt. Het model aanroepen, de uitvoer lezen, elk gevraagd tool uitvoeren, het resultaat teruggeven, herhalen tot de stopconditie.
- Tool-toegang: de functies, API's, code-uitvoering en het bestandssysteem dat het model kan bereiken.
- Memory: wat de agent bewaart over beurten en sessies heen.
- Contextbeheer: wat bij elke beurt in het venster van het model wordt geladen en wat wordt samengeperst als het overstroomt.
- Statuspersistentie / checkpointing: de status van de agent opslaan zodat een gecrashte of gepauzeerde run hervat kan worden.
- Foutafhandeling: herhaalpogingen, fallbacks en herstel wanneer een tool-aanroep of model-aanroep mislukt.
- Vangrails: beperkingen op wat de agent kan doen, zoals toegestane tools, staplimieten en uitvoervalidatie.
- Verificatielussen: de agent (of de harness) controleert zijn eigen werk voordat het als voltooid wordt beschouwd.
- Subagent-orkestratie: subagenten starten, taken delegeren en resultaten verzamelen bij grotere opdrachten.
Niet alle hiervan zijn universeel. De uitvoeringsloop, tools, contextverwerking en foutafhandeling komen zelfs voor in een weekendprototype. Toestandspersistentie, verificatie en subagent-orkestratie zijn waar prototypes en productiesystemen uiteenlopen. Een prototype kan ze overslaan; een langlopende productieagent niet. Anthropic's beschrijving over langlopende agenten is een rondleiding door de productie-exclusieve onderdelen: hoe een agent zijn begrip herbouwt vanuit een voortgangsbestand nadat zijn contextvenster is gereset, en hoe testen in de loop worden ingebouwd.
Voor wie de academische brug wil, een recente overzicht van agentarchitecturen vouwt dezelfde machinerie samen in een kleiner formeel tuple van kerncomponenten. De practitioner-lijst en het kader van het overzicht zijn twee zoomniveaus op dezelfde structuur: het overzicht comprimeert, de inventarisatie hierboven breidt uit. Behandel het negen-tot-elf-aantal als de componenten die de meeste productie-harnesses delen, niet als een geratificeerde standaard; het veld heeft nog niets geratificeerd.
Kernpunt: De meeste bewegende onderdelen van een agent leven in de harness, niet in het model. Het model is één component onder de vele.
Waarom is het harness belangrijker dan het model?
Een zwakker model in een goed ontworpen harness overtreft regelmatig een sterker model in een slecht ontworpen harness. De reden is mechanisch, niet magisch: end-to-end betrouwbaarheid van een agent is het product van de betrouwbaarheid van elke stap, en de meeste van die stappen (toolselectie, contextassemblage, foutherstel) zijn de taak van het harness, niet van het model. Verbeter ze en de hele keten wordt betrouwbaarder, ongeacht welk model erin zit.
De rekenkunde maakt het concreet. Stel dat elke stap in een taak van tien stappen 99% van de tijd slaagt. End-to-end succes is niet 99%. Het is 0,99 tot de tiende macht, ongeveer 90%. Duw elke stap naar 99,9% en end-to-end springt naar ongeveer 99%. Betrouwbaarheid per stap accumuleert, en betrouwbaarheid per stap is overwegend een harness-eigenschap. Dat is waarom het optimaliseren van foutafhandeling en contextbeheer meer oplevert dan het inwisselen voor een model dat op een benchmark een half punt beter scoort.
Er is productiesignaal dat dezelfde kant op wijst. MongoDB, met verwijzing naar Vercel's casestudy, meldt dat Vercel het grootste deel van de tools van hun agent heeft geschrapt en zag dat de slagingspercentage scherp steeg op hetzelfde model, met een kleiner en schoner harness. Lees het als convergent bewijs in plaats van bewijs: het is één productiecase, geen gecontroleerd experiment, maar het wijst dezelfde kant op als de samengestelde rekenkunde en het onderzoekswerk hierboven.
Dit is de heuristiek waarnaar ik als platform-engineer steeds terugkeer: context is de bottleneck, niet de ruwe modelcapaciteit, en steigers die gebouwd zijn om de huidige modelgebreken te maskeren, worden doorgaans opgeslokt naarmate modellen verbeteren. Bouw de duurzame onderdelen van het harness (de lus, de toestand, het herstel) en laat het onderliggende model op zijn eigen tempo beter worden.
Kernpunt: Als uw agent faalt, verdacht dan eerst het harness, niet het model. De kansen pleiten daarvoor.
Wat is het verschil tussen een harness, een scaffold en een framework?
Deze drie worden door elkaar gebruikt, en dat zou niet moeten. A framework is de bibliotheek of SDK waarmee je bouwt, zoals LangGraph of een agents SDK. Een harness is de draaiende uitvoerings- en governance-laag rondom het model, die een framework je helpt samen te stellen. Een scaffold is de losste van de drie: soms bijna een synoniem voor harness, soms de prototype-versie ervan, soms specifiek de prompt-en-tool-beschrijvingslaag.
Het vocabulaire is echt ongeregeld, en het schoonste is om de gebruiken in kaart te brengen in plaats van er één op te leggen. Die van HuggingFace Agent-woordenlijst zegt dit direct:
"Veel van deze termen hebben nog geen universeel geaccepteerde definities, en verschillende frameworks gebruiken hetzelfde woord op een andere manier."
— HuggingFace, Agent-woordenlijst
| Term | Waar het naar verwijst | Relatie |
|---|---|---|
| Framework | De bibliotheek of SDK waarmee je bouwt (LangGraph, een agents SDK) | Een tool voor het samenstellen van een harness |
| Harness | De uitvoeringslaag rondom het model: loop, tools, context, toestand, guardrails | Wat je uitrolt en draait |
| Scaffold | Losjes gebruikt: een bijna-synoniem voor harness, of de prototype-versie / prompt-laagversie | Overlapt met harness; minder precies |
| Loop | De uitvoeringscyclus binnen de harness | Een component van de harness |
De praktische conclusie voor het redeneren over je eigen systeem: wanneer iemand "framework" zegt, vraag dan of ze de bibliotheek bedoelen of het lopende ding. Wanneer iemand "scaffold" zegt, vraag dan of ze de hele harness bedoelen of alleen de prompt-en-tool-laag. De waarde hier is de disambiguering, niet een aanspraak op het laatste woord.
Hoe implementeert LangGraph het Harness-patroon?
LangGraph is een populaire open-source Python-implementatie van het harness-patroon. Het modelleert agentuitvoering als een gerichte graaf van knooppunten en kanten, met getypeerde toestand die ertussen stroomt en elke overgang die checkpointbaar is. Als de abstracte componenten hierboven ongrijpbaar aanvoelen, is LangGraph een plek om ze concrete vorm te zien aannemen in een echt gereedschap.
De mapping is bijna een-op-een. De knooppunten en kanten zijn de uitvoeringslus: elk knooppunt doet werk, elke kant beslist waar de controle vervolgens naartoe gaat. Het getypeerde toestandsobject dat tussen knooppunten wordt doorgegeven is de context-en-toestand-component expliciet gemaakt. Checkpointing (LangGraph behoudt toestand via savers zoals zijn Postgres-gebaseerde implementatie) is de toestandspersistentie-component. Een configureerbare staplimiet is een stopconditie-guardrail, die voorkomt dat een slecht werkende agent eeuwig in een lus blijft. Dezelfde componenten, benoemd en bedraad door een specifieke bibliotheek.
Als je een LangGraph-agent op je eigen server wilt draaien, de klok rond, is dat een deployment-vraag eerder dan een conceptuele. Zie onze Linux VPS-gids voor dat pad. Hier is LangGraph slechts het uitgewerkte voorbeeld: bewijs dat "uitvoeringslus", "toestandspersistentie" en "guardrail" geen abstracties zijn, maar dingen die je in echte code kunt aanwijzen.
Veelgestelde vragen
Wat is een Agent Harness?
Een agent-harness is de software rond een taalmodel die het in een agent verandert. Het beheert de uitvoeringslus, toegang tot gereedschappen, geheugen, context, toestandspersistentie, foutafhandeling en guardrails. Het model genereert tekst; de harness beslist wat het model ziet, wat het kan doen, wanneer te stoppen en wat er gebeurt als iets mislukt.
Is een agent harness hetzelfde als een agent framework?
Nee. Een framework is de bibliotheek of SDK waarmee je bouwt, zoals LangGraph of een agents SDK. De harness is de actieve uitvoerings- en governance-laag rondom het model (de loop, tools, context, staat en guardrails) die een framework je helpt samen te stellen. Je gebruikt een framework om een harness te bouwen.
Welke componenten heeft elke agent harness?
De meeste harnesses delen een terugkerende kern: een uitvoeringsloop, toegang tot tools, geheugen, contextbeheer, toestandspersistentie, foutafhandeling en guardrails. Productie-harnesses voegen verificatieloops en subagent-orkestratie toe. Prototypes kunnen de productie-specifieke onderdelen overslaan, maar de loop, tools, contextverwerking en foutafhandeling komen bijna overal voor.
Wat betekent "De LLM is het kleinste onderdeel van uw agentsysteem"?
Het betekent dat het grootste deel van het gedrag en de betrouwbaarheid van een agent uit de harness komt, niet uit het model. End-to-end betrouwbaarheid is het product van de slagingsgraad van elke stap, en de meeste stappen zijn harness-werk. MongoDB meldt, onder verwijzing naar Vercel's casestudy, een sprong in slagingsgraad door harness-wijzigingen alleen, op hetzelfde model. Dat is bewijs dat het repareren van de harness het repareren van het model overtreft.
Waar de kwaliteit van uw agent zich bevindt
De harness is de plek waar het grootste deel van de kwaliteit van een agent zich bevindt, en u heeft nu het vocabulaire om problemen in uw eigen systeem te lokaliseren. U kunt een harness definiëren, de componenten benoemen, het onderscheiden van een framework en een scaffold, en redeneren of een bepaalde fout een modelproblem of een harness-probleem is.
Dus de volgende keer dat uw agent zich misdraagt, controleer dan eerst de harness-laag: de context die u hem geeft, de tools die u hebt blootgesteld, de stopcondities die u hebt ingesteld, de manier waarop hij herstelt van een mislukte stap. Grijp pas naar een groter model nadat die laag is gecontroleerd. De meeste tijd zal dat niet nodig zijn.
