Agent Harnesses: de infrastructuur achter betrouwbare AI-agents

Veel AI-agentdemo's lijken in het begin op elkaar: een sterk model aansluiten, een paar tools toevoegen, een goede prompt schrijven en het systeem een taak laten uitvoeren. Dat kan genoeg zijn voor een demo. Voor productie is het niet genoeg. Productie-agents moeten relevante context onthouden, tools veilig gebruiken, herstellen van fouten, permissies respecteren, hun eigen werk verifieren en blijven werken wanneer een taak langer duurt dan een enkel schoon modelantwoord. Het model is belangrijk, maar het systeem rond het model bepaalt of de agent dagelijks echt bruikbaar is. Dit systeem wordt vaak de agent harness, agent runtime, orchestration layer, execution environment of agent scaffolding genoemd. In dit artikel gebruiken we "agent harness" voor de runtime- en orchestratielaag rond het model. Andere teams kunnen dezelfde laag agent framework, orchestration layer, execution runtime of agent scaffolding noemen.

Wat een agent harness is

Een agent harness is de software-infrastructuur die een stateless taalmodel verandert in een werkende agent. Het model voorspelt, plant en voert reasoning-achtige inferentie uit. De harness geeft het een gecontroleerde omgeving waarin het kan handelen. Een productieharness bevat meestal:

orchestratielussen
toolregistratie en tooluitvoering
contextbeheer
kortetermijn- en langetermijngeheugen
statuspersistentie
permissiecontroles
sandboxed execution
retries en foutafhandeling
verificatielussen
tracing en observability
modelrouting
subagentdelegatie

Zonder deze laag blijft een AI-agent meestal dichter bij een chatachtige interface of een single-step assistant. Met deze laag kan hij een workflow-engine worden. Als een gebruiker bijvoorbeeld vraagt om een checkoutbug te fixen, kan een model misschien alleen aangeven waar te kijken. Een harness laat de agent het repository inspecteren, bestanden doorzoeken, code aanpassen, tests draaien, fouten lezen, de patch herstellen, de diff controleren en pas stoppen nadat het resultaat is geverifieerd. Dat verschil is het product.

Waarom de harness belangrijker wordt

AI-teams leren dat twee producten met hetzelfde model heel verschillende resultaten kunnen opleveren. De reden is infrastructuur. Frontier-modellen verbeteren snel. Naarmate mogelijkheden zoals tool use, structured output, long context, code generation en reasoning-achtige inferentie bij meer aanbieders beschikbaar komen, verschuift meer productvoordeel naar de omgeving rond het model. Werk aan de harness stapelt zich ook op. Elke fout kan een blijvende systeemverbetering worden:

Slechte toolargumenten leiden tot strakkere schema's en validatie.
Vergeten beslissingen leiden tot beter context- en geheugenontwerp.
Riskante wijzigingen leiden tot permission gates.
Te vroege afronding leidt tot extra verificatie.
Dure herhalingen leiden tot betere caching of routing.
Slechter gedrag bij lange context leidt tot compaction en retrieval.

Promptfixes helpen, maar zijn niet genoeg. Duurzaam gedrag komt uit runtime-ontwerp.

Prompt engineering, context engineering en harness engineering

Deze termen hangen samen, maar betekenen niet hetzelfde. Prompt engineering is de instructielaag. Die vertelt het model welke rol het moet volgen, welke beperkingen belangrijk zijn en hoe het moet antwoorden. Context engineering is de informatielaag. Die bepaalt wat het model ziet, wanneer het dat ziet en hoeveel daarvan in het huidige venster hoort. Harness engineering is de volledige uitvoeringslaag. Die bevat prompts en context, maar ook tools, state, veiligheid, geheugen, verificatie, queues, observability en lifecycle management. Dit onderscheid is belangrijk, omdat prompts gedrag vragen terwijl harnesses gedrag afdwingen. Een prompt kan zeggen: "Verwijder geen bestanden zonder toestemming." Een harness kan destructieve commando's blokkeren totdat de gebruiker ze goedkeurt. Een prompt kan zeggen: "Controleer je werk." Een harness kan de testsuite draaien, de output inspecteren en afronding voorkomen als verificatie faalt.

Hoe een agent harness werkt

De meeste agent harnesses volgen een lus. Eerst stelt de harness de modelinput samen. Die input kan bestaan uit de system prompt, developer instructions, de vraag van de gebruiker, tooldefinities, geheugen, de huidige taakstatus en geselecteerde context uit bestanden of databases. Daarna reageert het model. Het kan tekst, gestructureerde data, tool calls of een verzoek om werk aan een andere agent over te dragen teruggeven. Vervolgens classificeert de harness de output. Als het model een definitief antwoord gaf, kan de lus stoppen. Als het een tool aanvroeg, valideert de harness die call. Validatie is cruciaal. De harness controleert of de argumenten aan het schema voldoen, of de tool beschikbaar is, of de actie veilig is en of de gebruiker of het systeem toestemming heeft gegeven. Daarna draait de tool. Die kan bestanden lezen, een database bevragen, documenten doorzoeken, een API aanroepen, code uitvoeren, een browser openen of een patch schrijven. Het resultaat keert terug naar het model als observatie. Als de tool faalt, moet de fout duidelijk genoeg verpakt zijn zodat het model kan herstellen. De lus gaat door totdat de agent een geverifieerd stoppunt bereikt, een budgetlimiet raakt, menselijke input nodig heeft of wordt onderbroken. Dat klinkt eenvoudig. Productiekwaliteit zit in de details rond deze lus.

Kernonderdelen van een productieharness

1. Orchestratielus

De orchestratielus bestuurt de beurten van de agent. Veelgebruikte patronen:

ReAct: denken, handelen, observeren, herhalen
plan and execute: eerst een plan maken, daarna uitvoeren
generate, test, repair: resultaat maken, controleren, fouten herstellen
gather, act, verify: context verzamelen, handelen, resultaat verifieren

De lus zelf kan technisch klein zijn. Het moeilijke deel is bepalen welke context in welke beurt hoort, welke acties zijn toegestaan, wat fouten betekenen en wanneer een taak echt af is.

2. Toollaag

Tools zijn de manier waarop de agent de wereld raakt. Goede tools worden ontworpen voor modellen, niet alleen voor mensen. Een mens kan ruisige CLI-output, verborgen defaults, dubbelzinnige flags en gedeeltelijke fouten interpreteren. Een agent heeft duidelijkere grenzen nodig. De toollaag moet omgaan met:

namen en beschrijvingen
argumentschema's
permissiecontroles
sandboxing
uitvoering
outputformattering
retries
auditlogs

Toolontwerp bepaalt vaak de kwaliteit van de agent. Te veel tools verwarren het model. Vage parameters leveren onbetrouwbare calls op. Brede permissies vergroten het risico. Sterke harnesses bieden de kleinste bruikbare set tools voor de huidige stap.

3. Contextbeheer

Context is geen opslag. Het is een schaarse werkruimte. Grote contextvensters helpen, maar vervangen selectie niet. Als irrelevante logs, oude outputs, verouderde plannen en herhaalde inhoud het venster vullen, wordt het model minder betrouwbaar. Productieharnesses gebruiken strategieen zoals:

eerst kleine indexen laden
exacte bestanden of records on demand ophalen
eerdere conversatierondes samenvatten
oude tooloutputs maskeren
beslissingen en open problemen bewaren en ruis verwijderen
verkenning delegeren aan subagents die compacte samenvattingen teruggeven

Het doel is niet maximale context. Het doel is de kleinste high-signal context die het model helpt om de volgende stap goed uit te voeren.

4. Geheugen

Geheugen laat een agent nuttige informatie meenemen tussen beurten en sessies. Kortetermijngeheugen dekt de actieve taak. Langetermijngeheugen bewaart duurzame feiten, voorkeuren, projectregels en terugkerende beslissingen. Werkgeheugen kan bestaan uit voortgangsbestanden, todo-lijsten of gestructureerde scratchpads. Geheugen mag niet als waarheid worden behandeld. Het moet als hint worden behandeld. Als geheugen zegt dat een project een bepaald framework gebruikt, moet de agent het project alsnog inspecteren voordat hij frameworkspecifieke wijzigingen doorvoert. Dat voorkomt dat verouderd geheugen verandert in gefantaseerde zekerheid. Geheugen heeft ook isolatie en review nodig, omdat slechte of kwaadaardige opgeslagen feiten toekomstige runs kunnen beinvloeden. Een productiesysteem moet voorkomen dat geheugen lekt tussen gebruikers, teams, tenants of permissiegrenzen.

5. Statuspersistentie

Productietaken leven vaak langer dan een enkel modelantwoord. De harness moet bijhouden:

sessie-ID
run-ID
huidige status
openstaande tool calls
aangeraakte bestanden
child agents
gegeven goedkeuringen
kosten en tokengebruik
eindresultaat
afleverstatus

Status maakt het mogelijk een taak na onderbreking te hervatten. Het levert ook auditability: wat gebeurde er, wanneer, waarom en via welke tool.

6. Foutafhandeling

Fouten horen erbij in agentische workflows. Een sterke harness scheidt fouttypen:

tijdelijke fouten moeten met backoff opnieuw worden geprobeerd
fouten in argumenten moeten duidelijke feedback aan het model geven
permissiefouten moeten goedkeuring vragen of een veilig pad kiezen
onverwachte fouten moeten stoppen met bruikbare diagnostiek

Dit is belangrijk omdat taken met meerdere stappen fouten opstapelen. Zelfs een hoog slagingspercentage per stap kan over een lange reeks zwak worden. Herstellogica is niet optioneel.

7. Guardrails en permissies

Het model kan beslissen wat het wil doen. De harness moet beslissen wat het mag doen. Nuttige permissiegrenzen zijn:

read-only versus write access
workspace-scope
goedkeuring voor destructieve commando's
goedkeuring voor databasemutaties
limieten voor externe API's
beperkingen op toegang tot credentials
menselijke review voor user-facing acties

Deze laag moet door code worden afgedwongen, niet alleen in een prompt worden beschreven. Voor acties met hoog risico moet goedkeuring plaatsvinden voordat de tool draait, niet erna.

8. Verificatielussen

Verificatie is waar agents betrouwbaar worden. Voor softwaretaken kan verificatie tests, type checks, linters, builds, screenshots, browser checks en diff review omvatten. Voor bedrijfsworkflows kan verificatie schema-validatie, database-constraints, menselijke review, confidence thresholds, documentcitaten en trace-inspectie omvatten. Een deel van verificatie is deterministisch. Een ander deel gebruikt een model als judge. Deterministische controles verdienen de voorkeur wanneer objectieve ground truth beschikbaar is.

9. Observability

Teams moeten kunnen zien hoe agents zich gedragen. Een productieharness moet tracen:

prompts en modeloutputs
tool calls
toolresultaten
fouten
retries
approvals
tokengebruik
latentie
verificatieresultaten
eindresultaten

Zonder observability kunnen teams het systeem niet verbeteren. Ze kunnen alleen gokken waarom het faalde.

Subagents en multi-agent lifecycle management

Zodra een agent andere agents kan starten, verandert het probleem. Subagents zijn nuttig wanneer werk kan worden opgesplitst. Een agent kan documentatie onderzoeken terwijl een andere code reviewt. De ene kan UI testen terwijl de andere backendlogica patcht. De ene kan bronnen onderzoeken terwijl de andere de concepttekst schrijft. Maar subagents starten is niet hetzelfde als ze beheren. Multi-agent lifecycle management begint wanneer de runtime gedurende langere tijd eigenaar moet zijn van veel draaiende agents. Een serieus multi-agentsysteem heeft nodig:

duurzame child-agent-ID's
parent-child lineage
run-ID's
rollen en dieptelimieten
queues
cancellation
steering
completion events
cleanup policy
recovery na herstart

De kernvraag wordt dan: waar leeft de child agent, wie is eigenaar, hoe rapporteert die terug en wat gebeurt er als de parent al verder is gegaan. Eenvoudige delegatie geeft een samenvatting terug aan de parent. Multi-agent lifecycle management behandelt completion als een routeringsprobleem. Een child kan klaar zijn terwijl de parent actief, idle, herstart of verdwenen is. De runtime moet dat resultaat op de juiste plek afleveren met behoud van provenance. Daarom gaan geavanceerde agentsystemen lijken op procesmanagers. Ze hebben identiteit, lifecycle, queues, recovery en cleanup nodig.

Managed agents versus maatwerkharnesses

Managed-agentplatforms komen steeds vaker voor. Ze verpakken de harness en productie-infrastructuur zodat teams sneller kunnen starten. Dat kan waardevol zijn wanneer een team wil:

sneller lanceren
een gehoste runtime
ingebouwde schaalbaarheid
beheerde tooluitvoering
standaard observability
minder infrastructuurverantwoordelijkheid

Maar managed agents zijn ook een architectuurbeslissing. Teams kunnen nog steeds een maatwerkharness nodig hebben wanneer:

workflowkwaliteit kernproductwaarde is
domeintools sterk specifiek zijn
permissies en audit trails streng zijn
kosten per taak tellen
langlopende agents eigen lifecycleregels nodig hebben
vendor lock-in belangrijk is
standaard agentgedrag slecht presteert op interne evals

Voor veel teams is de praktische route niet "alles zelf bouwen" of "alleen managed runtime gebruiken". Het is stapsgewijs. Begin met bestaande tools. Bouw evals. Vind foutpatronen. Pas de harness aan waar herhaalde fouten of economie dat rechtvaardigen.

Wanneer je team hier aandacht aan moet geven

Je moet harnessontwerp serieus nemen zodra een AI-workflow verder gaat dan een prototype. Duidelijke signalen:

gebruikers zijn afhankelijk van de output
fouten veroorzaken operationele kosten
de workflow raakt private of gereguleerde data
de agent heeft tools nodig met side effects
de taak bevat veel stappen
de output heeft verificatie nodig
menselijke review heeft audit trails nodig
tokenkosten worden zichtbaar
het gedrag van de agent verandert onvoorspelbaar tussen runs

Vanaf dat punt is het model slechts een deel van het systeem. Betrouwbaarheid komt uit de harness.

Hoe wij dit bij Lunover aanpakken

Bij Lunover behandelen we AI-agents als productiesoftware, niet als promptexperimenten. Dat betekent dat we starten met workflowwaarde. We brengen het echte proces, databronnen, risico's, gebruikers en succescriteria in kaart voordat we bouwen. Daarna kiezen we het juiste niveau van harnesscomplexiteit voor het werk. Voor een eenvoudige interne assistant kan dat retrieval, tool use en basismonitoring betekenen. Voor een klantgerichte workflow kan het strengere permissies, evals, fallbacks, trace review en menselijke goedkeuring vereisen. Voor langdurige automatisering kan het durable state, job queues, recovery en duidelijke ownership van elke actie vereisen. Het doel is niet dat de agent indrukwekkend oogt in een demo. Het doel is dat het systeem na lancering nuttig blijft. Als je team AI-agents, copilots, RAG-systemen of workflowautomatisering bouwt, kan Lunover helpen via AI-ontwikkeling, Webapp-ontwikkeling en Bedrijfssystemen, met focus op de productielaag rond je model: tools, geheugen, permissies, verificatie, observability en deployment.