Harness voor LLM's is de nieuwe ontwikkeling in 2026

Leestijd: 8 min

Kernpunten

• De term “AI-harness” gaat over alles dat je rondom een taalmodel bouwt: context, tools, orkestratie en feedback-loops.

• Voor het MKB is de modelkeuze (Claude, GPT, Gemini) verrassend onbelangrijk geworden; de harness eromheen bepaalt vrijwel volledig of een AI-implementatie waarde oplevert.

• Een AI-systeem in productie bestaat uit vier bewegende delen: het model, de context die het krijgt, de tools die het mag gebruiken, en de orkestratie tussen taken.

• Een harness wordt belangrijk zodra een taak terugkomt, meerdere stappen heeft, of door meerdere mensen wordt gebruikt; voor wegwerptaken volstaat een gewone ChatGPT-sessie.

• Het concurrentievoordeel zit niet in het kiezen van het beste model, maar in het organiseren van de context, tools en feedback eromheen: iets waarin een goed georganiseerd MKB een grotere concurrent kan verslaan.

Inhoudsopgave

• Inleiding: waarom modelkeuze de verkeerde discussie is

• Wat is een AI-harness?

• Waarom de harness belangrijker is dan het model

• De vier onderdelen, concreet gemaakt

• Wanneer heb je geen harness nodig?

• Hoe begin je hier praktisch aan?

• Concurrentievoordeel zit in de uitvoering

• Tot slot

• Veelgestelde vragen

Inleiding: waarom modelkeuze de verkeerde discussie is

Bijna elk MKB-gesprek over AI dat ik voer begint met een modelkeuze. “We willen iets met Claude doen.” “We hebben een ChatGPT-licentie aangeschaft.” “Wat denk je, Gemini of GPT-4?”

Dat is een logisch beginpunt: modellen zijn waar het nieuws over gaat. Maar het is ook het verkeerde beginpunt. De vraag welk model je gebruikt is voor de meeste bedrijfstoepassingen verrassend onbelangrijk geworden. Wat er echt toe doet, is de harness eromheen.

In dit artikel leg ik uit wat een AI-harness is, waarom hij bepaalt of je AI-project waarde oplevert of stilletjes doodbloedt, en hoe je er als MKB praktisch over kan nadenken.

Wat is een AI-harness?

De term komt uit de wereld van AI-engineering en is begin februari 2026 echt op de kaart gezet door Mitchell Hashimoto, mede-oprichter van HashiCorp en de bedenker van Terraform. In een blogpost over zijn eigen ervaring met AI-agents introduceerde hij wat hij “engineering the harness” noemde: elke keer dat een agent een fout maakt, repareer je niet de fout zelf, maar de omgeving eromheen, zodat dezelfde fout niet meer kan voorkomen (mitchellh.com). Een paar dagen later publiceerde OpenAI een uitgebreid verslag over een intern experiment waarin een team van drie engineers met deze aanpak een softwareproduct van ongeveer een miljoen regels code bouwde: zonder een enkele regel handmatig geschreven code (openai.com). De term verspreidde zich binnen weken door het hele veld.

Een harness is, letterlijk vertaald, een tuig: het beslag dat een paard met de wagen verbindt. Zonder harness is een paard nog steeds een paard, maar het trekt geen wagen. Het is een metafoor die goed werkt: je kunt het krachtigste model van de wereld hebben, maar zonder de structuur eromheen levert dat geen werkend systeem op.

Concreet bestaat een AI-systeem in productie uit ruwweg vier bewegende delen:

1. Het model. Claude, GPT, Gemini, een open-source variant zoals Llama of Qwen. Het ding dat tekst produceert.

2. De context. Wat het model per taak meekrijgt: documenten, eerdere gesprekken, klantgegevens, bedrijfsbeleid, processen, tone of voice.

3. De tools. Wat het model kan doen behalve praten: mailen, een database raadplegen, een agenda lezen, een factuur aanmaken, een PDF genereren.

4. De orkestratie. Hoe taken worden opgeknipt en doorgegeven. Welke agent doet wat. Wie controleert wie. Wat gebeurt er als iets misgaat.

De harness is alles behalve het model. Het is de infrastructuur die ervoor zorgt dat het model in jouw bedrijf, voor jouw klanten, met jouw data, op jouw manier werkt. Birgitta Böckeler van Thoughtworks vat dit samen in de korte formule die nu in de hele industrie circuleert: Agent = Model + Harness (martinfowler.com).

Een handige analogie: het model is de motor. De harness is de auto eromheen. Een Ferrari-motor zonder versnellingsbak, stuur, remmen, dashboard en stoelen is geen auto. Het is een spannend metalen blok in je garage. En toch praat het halve MKB over AI alsof je de motor koopt en klaar bent.

Waarom de harness belangrijker is dan het model

Drie redenen.

Eén: modellen worden snel een commodity. De afstand tussen de top van Claude, GPT en Gemini wordt op de meeste taken kleiner, niet groter. Voor specifieke benchmarks wisselt de leider per maand. Voor het soort werk dat MKB doet (samenvatten, schrijven, classificeren, simpele analyses) zijn alle grote modellen al ruim goed genoeg. Je kunt vandaag Claude kiezen en over een halfjaar zonder verlies van kwaliteit naar GPT switchen, mits je harness daarop is voorbereid.

Twee: het model weet niets van jouw bedrijf. Een vers gestart taalmodel weet alles over de Franse Revolutie en niets over jouw klantenservice-beleid, je leveranciersprijzen, of dat Marcel uit het magazijn op donderdag vrij is. Wat het model produceert is hooguit zo goed als de context die het krijgt. Slechte context, slechte output. Dat geldt ongeacht welk model je gebruikt.

Drie: één antwoord is geen workflow. Een AI die een nette mail schrijft is leuk. Een AI die een binnenkomende klacht herkent, het juiste klantdossier opzoekt, controleert of er al eerder is gereageerd, een passend antwoord opstelt, dat antwoord laat checken door een collega als het een gevoelig dossier is, en het na goedkeuring verstuurt: dát is iets waardevols. Het verschil is bijna volledig harness.

Dit principe wordt in de engineering-wereld inmiddels breed onderschreven. Ryan Lopopolo van OpenAI beschrijft hoe zijn team bij elke fout van een agent niet vroeg “hoe prompten we beter?” maar “welke capability, context of structuur ontbreekt?” (openai.com). De rode draad in de literatuur is duidelijk: een gedisciplineerde harness op een zwakker model verslaat een ongedisciplineerde aanpak op een sterker model, elke keer.

Met andere woorden: de modelkeuze beïnvloedt misschien 10% van de uitkomst. De harness beïnvloedt de andere 90%.

De vier onderdelen, concreet gemaakt

Context: wat weet de AI eigenlijk over jou?

De grootste gap die ik bij MKB zie is tussen wat een AI-tool zou moeten weten en wat hij daadwerkelijk weet als je hem een vraag stelt. Stel je zegt tegen ChatGPT: “Schrijf een offerte voor klant X.” Dan moet ChatGPT wel ergens weten:

• Wie klant X is en wat de geschiedenis is

• Welke producten of diensten je aanbiedt en tegen welke prijs

• Welke korting eventueel van toepassing is

• Hoe jouw offertes er normaal uitzien

• Of er nog openstaande punten zijn uit eerdere gesprekken

Bij de meeste MKB-implementaties zit hier helemaal niets. De AI begint elke taak vanaf nul. Het bedrijf hoopt dat de medewerker dat allemaal zelf in een prompt typt, wat betekent dat de medewerker eigenlijk het werk doet en de AI alleen de tekst opmaakt.

Een serieuze harness lost dat op. Bij ons gebruiken we onder andere gestructureerde Obsidian-vaults, ClickUp-data, e-mailgeschiedenis via Gmail-integraties, en transcripties van klantgesprekken via Fireflies: allemaal toegankelijk voor de relevante AI-agents. Niet alle data tegelijk, want dan ontstaat er ruis. Het OpenAI-team noemt dit principe “geef Codex een kaart, geen handleiding van duizend pagina’s”: context is een schaars goed, en alles tegelijk meegeven betekent in de praktijk dat het model niets gericht meekrijgt (openai.com).

Concreet: als ik een agent vraag een klantvoorstel te schrijven, haalt die zelfstandig het klantdossier op, kijkt naar onze vorige voorstellen, leest de meeting-transcripts terug, en produceert iets waar ik 80% mee verder kan. Niet omdat het model bijzonder is (het is hetzelfde Claude-model dat iedereen kan gebruiken), maar omdat de context er is.

Tools: wat kan de AI eigenlijk doen?

Een taalmodel zonder tools kan tekst produceren. Punt. Het kan geen mail versturen, geen factuur aanmaken, geen agenda lezen, geen klant aanmaken in je CRM. Daar heb je tools voor nodig: gestandaardiseerde verbindingen tussen het model en de buitenwereld.

In het MKB zie ik twee uitersten. Aan de ene kant bedrijven die helemaal geen tools toevoegen en hun medewerkers laten kopiëren-plakken tussen ChatGPT en de rest van hun software. Dat werkt voor incidentele taken, maar het is geen systeem. Aan de andere kant bedrijven die alles aan elkaar willen knopen, met als gevolg een spaghetti waar niemand meer doorheen komt.

De middenweg is gerichte toolkeuzes per use-case. Voor onze klantenservice-agent bijvoorbeeld zijn drie tools relevant: e-mail lezen, klantdossier ophalen, een conceptantwoord opslaan. Niet versturen: dat doet een mens, na controle. Voor onze offerte-agent zijn andere tools relevant: ClickUp lezen, eerdere voorstellen ophalen, een nieuwe Google Doc aanmaken. Elke agent krijgt alleen de tools die hij nodig heeft, niet meer.

Dat is een bewuste ontwerpkeuze. Hoe meer tools een agent heeft, hoe groter de kans op verkeerde keuzes en moeilijk te debuggen problemen. Beperking is een feature.

Orkestratie: hoe werken de stukken samen?

Zodra je meer dan één taak automatiseert, krijg je een orkestratie-vraag. Welke agent doet wat? Wie geeft wat door? Wat gebeurt er als stap drie faalt? Wie controleert het eindresultaat?

Hier zie ik veel MKB-projecten vastlopen. Ze beginnen met “we willen één AI-assistent die alles kan.” Dat klinkt mooi, maar in de praktijk is dat een generalist die alles middelmatig doet. Het werkt veel beter om gespecialiseerde agents te bouwen (eentje voor inkomende mail, eentje voor offertes, eentje voor planning) en die door een orkestratie-laag heen te laten samenwerken. Anthropic heeft dit principe expliciet getest: een opzet met een aparte planner, generator en evaluator presteerde beduidend beter dan één enkele agent op dezelfde taak (milvus.io).

Een concreet voorbeeld uit ons werk. We hebben een klant in de online retail waar binnenkomende klantvragen door drie verschillende agents lopen voordat er een conceptantwoord ligt. De eerste classificeert wat voor type vraag het is (klacht, retour, productvraag, anders). De tweede haalt op basis van die classificatie de juiste data op (orderhistorie bij retour, productspecs bij productvraag). De derde schrijft het concept. Pas daarna komt er een mens aan te pas voor goedkeuring.

Drie agents, elk goed in één ding, met heldere overdracht ertussen. Veel betrouwbaarder dan één megaprompt waar je alles in propt en hoopt dat het goed gaat. En veel makkelijker te onderhouden, als de classificatie fout gaat weet je precies waar je moet kijken.

Feedback en geheugen: leert het systeem ook iets?

Dit is het stuk dat het meest wordt overgeslagen en achteraf het verschil maakt tussen een AI-systeem dat goed wordt en een dat altijd middelmatig blijft. Het is ook precies het punt waarmee Hashimoto begon: elke fout van de agent is een aanleiding om de omgeving zo aan te passen dat die fout niet meer kán gebeuren (mitchellh.com).

Een typische AI-implementatie werkt zo: medewerker stelt vraag, AI antwoordt, medewerker corrigeert het antwoord handmatig, klant krijgt antwoord. De correctie verdwijnt in de wind. Volgende keer maakt de AI exact dezelfde fout.

Een harness met feedback-loops doet het anders. De correcties worden ergens opgeslagen, als voorbeelden, als regels, als context die meegaat in toekomstige prompts. Het systeem wordt beter terwijl je het gebruikt, niet alleen wanneer iemand de prompt aanpast.

Bij ons zijn dit gestructureerde memory-systemen die per agent en per klant bijhouden wat er werkt en wat niet. Geen magie: gewoon goed bijgehouden voorbeeldenbestanden, met versiebeheer, die op het juiste moment worden ingevoegd. Maar het verschil tussen een systeem dat dit heeft en een dat het niet heeft is na drie maanden gigantisch.

Wanneer heb je geen harness nodig?

Volledigheidshalve: niet elke AI-toepassing vraagt om een harness. Voor wegwerptaken (een mail vertalen, een tekst inkorten, brainstormen over een naam) is ChatGPT openen en typen prima. Daar is de harness het brein van de gebruiker zelf, en dat is genoeg.

De harness wordt belangrijk zodra een of meer van deze dingen waar zijn:

• De taak komt herhaaldelijk terug

• Het resultaat moet consistent zijn over tijd of over medewerkers heen

• Er zijn meerdere stappen of meerdere databronnen

• Meerdere mensen gebruiken het systeem

• Fouten hebben kosten (klant, geld, reputatie)

In die gevallen verkruimelt een ad-hoc opzet snel. Iemand vergeet een stap, iemand anders gebruikt een andere prompt, niemand weet meer waarom de output van afgelopen maand er anders uitzag.

Hoe begin je hier praktisch aan?

Niet door morgen een harness van nul af aan te bouwen. Wel door bij elk AI-idee dat in je bedrijf opkomt de vier vragen te stellen:

1. Welk model is hier eigenlijk voor nodig? Vaak een minder relevante vraag dan je denkt. Kies een goed model en parkeer de discussie.

2. Welke context heeft dit nodig? Welke data moet de AI kunnen raadplegen? Waar staat die data nu? Hoe komt hij erbij?

3. Welke tools zijn nodig? Wat moet de AI kunnen doen behalve antwoorden? Welke daarvan kan hij autonoom, en welke vereisen menselijke goedkeuring?

4. Hoe zit de orkestratie eruit? Is dit één taak of een keten? Wie controleert het resultaat? Wat gebeurt er bij fouten?

Als je die vier vragen voor elk AI-project stelt, ga je vanzelf van “we kopen ChatGPT-licenties” naar iets dat substantiëler is. Niet groter qua techniek per se, vaak juist kleiner en gerichter, maar substantieler qua effect.

Concurrentievoordeel zit in de uitvoering

Modellen zelf zijn voor iedereen beschikbaar. Het verschil zit in hoe je ze inzet. Mijn voorspelling: over een paar jaar wordt het model nog minder belangrijk dan nu. De grote spelers convergeren naar vergelijkbare prestaties op gangbare taken, prijzen dalen, en de meeste bedrijfssoftware bouwt modelkeuze in als configuratie-instelling die je per maand kan veranderen.

Wat overblijft als concurrentievoordeel is de harness. Bedrijven die hun context goed georganiseerd hebben, die gerichte tools hebben gebouwd voor hun specifieke workflows, die feedback-loops hebben gesloten, die memory-systemen hebben laten groeien: die zullen merkbaar betere AI-systemen hebben dan bedrijven die nog steeds aan modelkeuze blijven hangen.

Voor het MKB is dit goed nieuws. Het is geen wedstrijd om wie het grootste rekenbudget heeft. Het is een wedstrijd om wie het beste begrijpt hoe zijn eigen werk in elkaar zit. Dat is een spel waarin een goed georganiseerd MKB-bedrijf het van een veel grotere concurrent kan winnen: mits ze stoppen met op de motor staren en aan de auto beginnen te bouwen.

Tot slot

Een AI-harness is geen technisch hoogstandje. Het is gewoon hoe je deze technologie verantwoord en effectief inzet als je voorbij het experimenteer-stadium wilt komen. Context, tools, orkestratie en feedback zijn middelen, geen doelen op zich. Wat telt is dat het systeem doet wat het moet doen, betrouwbaar werkt, en past binnen jouw werkwijze.

Voor het MKB ligt daar de kans: niet de grootste implementatie, maar de slimste. Klein beginnen, leren wat werkt in jouw context, en stap voor stap uitbouwen.

In het vervolg op dit artikel werk ik dit verder uit met concrete voorbeelden uit ons werk: hoe we onze eigen harness hebben opgezet, welke fouten we daarbij hebben gemaakt, en wat we hebben geleerd door onszelf als eerste klant te behandelen.

Veelgestelde vragen

Wat is een AI-harness? +

Een AI-harness is alles wat je rondom een taalmodel bouwt om het bruikbaar te maken voor een specifieke bedrijfstoepassing: de context die het model krijgt, de tools die het mag gebruiken, de orkestratie tussen taken, en de feedback-loops die ervoor zorgen dat het systeem leert van fouten.

Waarom is de harness belangrijker dan het model? +

Omdat moderne taalmodellen voor de meeste bedrijfstaken inwisselbaar goed zijn geworden. Het verschil tussen een AI-implementatie die werkt en een die middelmatig blijft, zit bijna volledig in hoe je context, tools en feedback hebt georganiseerd, niet in welk model je hebt gekozen.

Heb ik altijd een harness nodig? +

Nee. Voor incidentele, eenmalige taken (een mail vertalen, brainstormen, een tekst inkorten) volstaat een directe ChatGPT- of Claude-sessie. Een harness wordt belangrijk zodra een taak terugkomt, meerdere stappen heeft, of door meerdere mensen wordt gebruikt.

Waar moet ik beginnen als MKB? +

Bij één concreet proces dat veel tijd kost of zichtbare frustratie oplevert. Bouw daar een werkende harness omheen (context op orde, juiste tools, duidelijke orkestratie) en schaal vanaf daar. Zo houd je grip op kosten en weet je snel of de aanpak werkt voor jouw situatie.

Hoe verhoudt dit zich tot AI-regelgeving zoals de EU AI Act? +

Een goed opgezette harness helpt om controle te houden over wat een AI-systeem wel en niet mag doen: denk aan welke data het ziet, welke acties het zelfstandig mag uitvoeren, en welke stappen menselijke goedkeuring vereisen. Dat soort controle is precies wat compliance-kaders zoals de EU AI Act van bedrijven vragen, zeker bij toepassingen met hogere risico’s.