Harness engineering: wat betekent het voor agencies en opdrachtgevers?

Wat is een agent harness?

De korte formule die je bij LangChain en bij Birgitta Böckeler (Thoughtworks / martinfowler.com) terugziet:

Agent = Model + Harness

Het model levert de intelligentie. De harness is alles wat géén model is: system prompts, tools en MCP-koppelingen, sandbox, orkestratie, hooks, geheugen, tests en reviewstappen. Een los model is nog geen agent. Pas als de harness state, tools, feedback en grenzen toevoegt, wordt het een werkbare agent.

LangChain formuleert het zo: het model bevat de intelligentie, de harness maakt die intelligentie bruikbaar. Böckeler vernauwt de term voor coding agents: een deel van de harness zit al in het product (system prompt, code retrieval), maar teams bouwen daarnaast een outer harness voor hun eigen codebase en werkwijze.

Guides en sensors: sturen vóór en ná de actie

Böckeler splitst die outer harness in twee richtingen:

• Guides (feedforward) sturen de agent vóór die handelt. Voorbeelden: AGENTS.md, skills, bootstrap-scripts, coding conventions.
• Sensors (feedback) kijken daarna of het resultaat klopt, en geven fouten terug zodat de agent zichzelf kan corrigeren. Voorbeelden: tests, linters, type-checkers, structurele checks, AI-code review.

Alleen feedback geeft een agent die dezelfde fouten blijft herhalen. Alleen feedforward geeft regels zonder te weten of ze werken. Beide samen vormen een stuurloop.

Daarbinnen onderscheidt ze twee uitvoeringsvormen:

• Computational: deterministisch en snel (CPU). Tests, linters, type-checkers, structurele analyse. Betrouwbaar genoeg om bij elke wijziging mee te draaien.
• Inferential: semantisch en probabilistisch (vaak GPU/NPU). AI-review, "LLM as judge". Duurder, trager, minder deterministisch, maar bruikbaar voor rijkere sturing en oordeel.

Het menselijke werk zit in de steering loop: als dezelfde fout vaker terugkomt, verbeter je de harness. Niet "probeer harder", maar een betere guide of een scherpere sensor.

Waarom dit voor agencies telt

Voor agencies verschuift de waarde. Uren besteden aan code kloppen blijft bestaan, maar het verschil zit steeds vaker in het ontwerpen en onderhouden van de harness: conventies, tests, architectuurgrenzen, reviewloops en contextbeheer.

Sam Black (Towards Data Science) zet dat scherp: de verbetering komt vaak harder aan als je de harness versterkt dan als je alleen een iets beter model probeert te forceren. Domeinkennis zit in de workflow: hoe je werk opknipt, waar je checkpoints zet, wat "klaar" betekent. Patronen als ReAct, plan-then-execute, reflexion en sub-agents zijn bouwstenen; de kunst is ze te laten passen bij jouw domein.

Praktische lessen uit productieteams (samengevat door o.a. Study Notes / snowan):

1. Begin klein. Eerst een werkende loop, dan pas extra infrastructuur.
2. Minder tools kan beter werken. Een agent met een kleinere, scherpere set tools presteert vaak beter dan een agent die overal toegang toe heeft.
3. Beheer context, state en observability. Wat in de context zit, wat op schijf leeft, en of je elke toolcall kunt traceren, bepaalt of je een agent kunt verbeteren of alleen kunt aankijken.

Dat maakt harness engineering een senior specialisme: je moet weten hoe het systeem hoort te werken, welke fouten je accepteert, en welke checks afdwingbaar zijn. Junior prompten is iets anders dan een stuurbaar leverproces bouwen.

Wat opdrachtgevers moeten vragen

Voor eindklanten met een IT- of digitaal team is "gebruiken jullie AI?" een zwakke vraag. Die zegt niets over kwaliteit, traceerbaarheid of reviewlast.

Een harness is ook governance. Wie AI-output in productie laat landen zonder tests, linting, architectuurchecks en een heldere reviewroute, koopt snelheid in zonder rem.

Vragen die je een leverancier kunt stellen:

1. Welke checks draaien automatisch voordat een AI-wijziging bij een mens belandt (tests, types, linters, architectuurregels)?
2. Waar staan jullie conventions (AGENTS.md, skills, service-templates) en wie houdt die bij?
3. Kunnen jullie een wijziging traceren? Welke toolcalls, welke falende checks, welke herstelpogingen?
4. Wie mag verwachtingen wijzigen? Als de agent code én tests schrijft, hoe voorkomen jullie dat dezelfde mislezing in beide landt?
5. Wat gebeurt er bij herhaalde fouten? Verbeteren jullie dan de harness, of blijft iemand handmatig opruimen?

Je hoeft geen ML-team te zijn om dit te vragen. Je vraagt naar hetzelfde als bij elke serieuze leverancier: hoe borgen jullie kwaliteit als het volume omhooggaat.

Eén experiment: goedkoop model, sterke harness

HastCode beschrijft een experiment van Naresh Jain (Specmatic). Coding agents bouwden dezelfde API-service, met en zonder harness. De harness gebruikte specificaties (OpenAPI/AsyncAPI), voorbeelden en contractchecks; een aparte suite van 178 acceptatietests die de harness niet zag, beoordeelde elk resultaat.

Met een kosten-geoptimaliseerd model:

• zonder harness: 3 van 10 runs geaccepteerd
• met harness: 10 van 10 runs geaccepteerd
• tokens: ongeveer 3,9× meer bij de geharnessde runs (ruim 5,8M → bijna 23M tokens gemiddeld)

Dit is één experiment: tien gepaarde runs op één greenfield Java-service. Geen algemene wet. Wel een bruikbaar signaal: bij een zwakker of goedkoper model kan de harness het verschil zijn tussen "vaak bijna" en "structureel voldoende". In dezelfde tabel haalde een sterker model 10/10 ook zonder die harness, met minder tokens. De les is dus niet "altijd meer tokens", maar "meet of jouw harness het model beter maakt voor jouw taak".

Hoe je klein begint

Je hoeft geen platformteam van twintig mensen. Een minimale outer harness voor coding agents ziet er vaak zo uit:

1. Guides: korte, door mensen geschreven projectregels (AGENTS.md), plus skills voor terugkerende taken.
2. Snelle sensors links: type-check, linter, gerichte tests vóór of bij commit.
3. Zwaardere sensors later: bredere review, mutation testing of AI-review in CI, niet bij elke toetsaanslag.
4. Observability: log toolcalls, falende checks en tokengebruik, anders kun je de harness niet verbeteren.
5. Steering: elke herhaalde reviewopmerking wordt een regel of een check.

Böckeler noemt ook de grens: functioneel gedrag blijft lastig. Groen op AI-geschreven tests is nog geen bewijs dat de applicatie doet wat jij bedoelde. Houd daarom verwachtingen (contracts, fixtures, featurelijsten) buiten bereik van de agent waar dat kan.

Veelgestelde vragen

Tot slot

Harness engineering is hoe je AI coding agents van demo naar leverproces brengt. Voor agencies is het een nieuw senior vak: workflows, conventies en checks ontwerpen. Voor opdrachtgevers is het een governancevraag: hoe borgen jullie de kwaliteit van AI-output?

Digital Tribes werkt met Nederlandse senior freelance specialisten via contractuele tussenkomst of directe bemiddeling, en met teams die onder jouw regie werken.

Zoek je een senior specialist die een harness in jouw stack kan opzetten of die de AI-werkwijze van je leverancier kan beoordelen? Plan een intake.