Wat is een Agent Harness? Beheerde Agents Uitvoeren in Productie

Een model kiezen en dit verbinden met tools kan een AI-agent werkend krijgen. Die agent gereedmaken voor productie is een heel andere uitdaging.

U heeft een betrouwbare uitvoeringslus nodig, een veilige omgeving voor het uitvoeren van code, goedkeuringsstappen voor gevoelige acties en traces die laten zien wat er tijdens elke run is gebeurd. Deze functionaliteiten bevinden zich in een laag die de agent harness wordt genoemd. En zodra u agents op schaal bouwt, moet u beslissen of u deze laag zelf bouwt of een beheerde oplossing gebruikt.

Hier is een voorbeeld: Sofia, een platform engineer, erfde het werk aan agents van drie verschillende teams, samen met het verzoek om ze gereed te maken voor productie. 

Elk team had zijn eigen runtime gebouwd. Het ene team schreef een orchestratielus in Python, een ander gebruikte een agent-framework en het derde riep een model rechtstreeks aan vanuit een cron job. API-sleutels waren opgeslagen in agent-configuraties en gecommit naar repositories. Goedkeuringsprocessen verschilden per team en twee teams hadden geen betrouwbare manier om de acties van een agent te traceren.

Het ontbrak de agents niet zozeer aan betere modellen of meer tools. Ze misten een gemeenschappelijke runtime om taken uit te voeren, referenties te beheren, goedkeuringen af te dwingen en bij te houden wat er gebeurde. Sofia had een agent harness nodig.

Dit is een veelvoorkomende uitdaging zodra de initiële demo werkt. Een agent bouwen is één probleem; deze betrouwbaar en veilig laten werken is iets anders. Zonder een gedeelde harness eindigt elk team met het opnieuw bouwen van dezelfde mogelijkheden, vaak met verschillende lacunes in beveiliging en observabiliteit. In dit artikel leggen we uit wat een agent harness doet, welke mogelijkheden het geschikt maken voor productie en waar u op moet letten bij de beslissing om uw eigen harness te bouwen of een beheerde harness te gebruiken.

Breng uw AI-agents naar productie met TrueFoundry

Bouw, deploy en beheer AI-agents met gecentraliseerde referenties, gecontroleerde toegang tot tools en end-to-end observabiliteit.

Boek een demo

Wat is een Agent Harness?

Een agent harness is de runtime-laag rond een large language model (LLM) die het transformeert van een tekstgenerator naar een agent die taken kan uitvoeren. Het beheert de uitvoeringslus: het model beslist wat er moet gebeuren, de harness roept de vereiste tool aan, observeert het resultaat en voedt dat resultaat terug aan het model. De lus gaat door totdat de taak is voltooid of een geconfigureerde limiet is bereikt.

De harness verwerkt ook de onderdelen die nodig zijn om agents betrouwbaar te laten draaien, waaronder tool-uitvoering, geheugen, contextbeheer, beveiligingscontroles, menselijke goedkeuring en observabiliteit.

Zie de harness als de infrastructuur die het werk van een agent op koers houdt. Het model levert het denkvermogen en tools bieden externe mogelijkheden. De harness verbindt ze, beheert de uitvoering en dwingt de grenzen af die de workflow bruikbaar maken in productie.

Hoe werkt een agent harness?

Een agent harness coördineert de stappen tussen het ontvangen van een taak en het opleveren van een resultaat. Dit is hoe het werkt: 

1. De applicatie of agent-interface ontvangt het verzoek van de gebruiker en geeft dit door aan de agent-runtime. De harness maakt een run aan en combineert het verzoek met de instructies van de agent, relevante gespreksgeschiedenis, beschikbare tools en eventueel opgehaalde context. Het bereidt deze informatie voor in het formaat dat het model verwacht.
2. De harness stelt de context samen die het model nodig heeft om te reageren. Dit kan systeeminstructies, het verzoek van de gebruiker, eerdere berichten, opgehaalde documenten, tool-beschrijvingen en outputs van eerdere tool-aanroepen omvatten. Een onderdeel voor contextbeheer kan deze informatie ophalen, filteren, samenvatten of compacter maken om deze relevant te houden. De harness stuurt de samengestelde context vervolgens naar het LLM via de model-API.
3. Het LLM verwerkt het verzoek en de context en retourneert vervolgens een antwoord of een voorgestelde tool-aanroep. Een coding-agent kan bijvoorbeeld besluiten dat hij een bestand moet inspecteren voordat hij een bug oplost. Het model specificeert de tool die het wil gebruiken en de vereiste argumenten. De harness ontvangt deze output en bepaalt of de voorgestelde actie mag worden uitgevoerd.
4. Wanneer het model om een tool vraagt, stuurt de harness de aanroep door naar de juiste API, MCP server, database of code-uitvoeringsomgeving. Vóór de uitvoering kan het rechten controleren, argumenten valideren, guardrails toepassen en menselijke goedkeuring vragen voor gevoelige acties. De tool voert de gevraagde bewerking uit en retourneert het resultaat aan de harness. Het model stelt de actie voor; de harness en tool-infrastructuur verzorgen de gecontroleerde uitvoering.
5. De harness geeft de output van de tool terug aan de context van de agent, meestal als een bericht met het resultaat van de tool. Het stuurt de bijgewerkte context opnieuw naar het model, zodat het model het resultaat kan interpreteren en de volgende actie kan kiezen. De agent kan deze lus herhalen over meerdere tool-aanroepen totdat er voldoende informatie is of de taak is voltooid. Als de context te groot wordt, kan de harness eerdere informatie samenvatten of compacter maken voordat hij doorgaat.
6. Wanneer het model een definitief antwoord retourneert in plaats van een nieuwe actie aan te vragen, beëindigt de harness de run en geeft het resultaat terug aan de applicatie voor levering aan de gebruiker. Het legt ook uitvoeringsdetails vast zoals model-aanroepen, tool-activiteit, latentie, token-gebruik en kosten, afhankelijk van het geconfigureerde observabiliteitssysteem. De harness kan de uitvoering ook stoppen als het een staplimiet, timeout, budgetlimiet of andere geconfigureerde beperking bereikt.

Een coding-agent die wordt gevraagd een bug op te lossen, kan bijvoorbeeld een repository inspecteren, tests uitvoeren, een bestand wijzigen en de tests opnieuw uitvoeren. De agent harness coördineert deze acties en beheert hoe de agent toegang krijgt tot de code en de uitvoeringsomgeving.

Wat beheert een Agent Harness?

Een agent harness brengt verschillende onderdelen samen die anders afzonderlijk geïmplementeerd en onderhouden zouden moeten worden.

• Tool-routing en -uitvoering verbinden het model met API's, MCP-servers, databases en code-uitvoeringsomgevingen. Wanneer het model om een tool vraagt, stuurt de harness de aanroep door, ontvangt het resultaat en geeft dit terug aan het model om de volgende actie te bepalen.
• Geheugen- en contextbeheer onderhouden de gespreksgeschiedenis, taakstatus en relevante informatie over meerdere stappen. De harness kan informatie ophalen, eerdere interacties samenvatten en context compacter maken om deze relevant te houden tijdens langere workflows.
• Beveiliging en rechten beheren tot welke tools, referenties, bestanden en systemen een agent toegang heeft. De harness kan toegangsbeleid afdwingen en sandboxes gebruiken om code-uitvoering te isoleren en toegang tot gevoelige bronnen te beperken.
• Menselijke goedkeurings-workflows onderbreken de uitvoering wanneer een actie beoordeling vereist, zoals het wijzigen van productiedata of het verwijderen van bestanden. De harness hervat of stopt de workflow op basis van het goedkeuringsbesluit en het geconfigureerde beleid.
• Betrouwbaarheid en uitvoeringslimieten verwerken tool-fouten, retries, timeouts en iteratielimieten. Deze controles helpen voorkomen dat agents mislukte acties blijven herhalen en oneindig blijven draaien.
• Observabiliteit en tracing volgen model-verzoeken, tool-aanroepen, fouten, latentie, token-gebruik en kosten. End-to-end traces helpen teams elke stap van een run te begrijpen en prestatieproblemen of storingen te identificeren.

Deze onderdelen helpen teams verder te gaan dan eenvoudige model-aanroepen, naar agents die meerstaps werk kunnen uitvoeren. Een harness maakt een agent echter niet automatisch veilig of betrouwbaar. De effectiviteit hangt af van hoe de rechten, runtime-controles en het uitvoeringsbeleid zijn geconfigureerd.

Agent Harness vs Agent Framework vs Agent Runtime

Een agent harness, agent framework en agent runtime spelen verschillende rollen bij het bouwen en uitvoeren van AI-agents. 

Een framework biedt de tools om een agent te bouwen, een harness beheert hoe deze taken uitvoert, en een runtime biedt de omgeving waarin deze draait. 

Een agent harness beheert hoe een AI agent een taak uitvoert. Het coördineert model-aanroepen, tool-uitvoering en de verwerking van resultaten totdat de taak is voltooid. Het kan ook rechten, retries, uitvoeringslimieten en logging beheren om de acties van de agent gecontroleerd en observeerbaar te houden.

Een agent framework biedt de onderdelen die ontwikkelaars nodig hebben om AI-agents te bouwen. Deze omvatten model-integraties, interfaces voor tool-aanroepen en workflow-orchestratie. LangGraph helpt ontwikkelaars bijvoorbeeld te definiëren hoe een agent beweegt tussen taken en tools. De harness beheert het uitvoeringsproces, hoewel sommige frameworks beide mogelijkheden bieden.

Een agent runtime biedt de omgeving waarin een AI-agent zijn taken uitvoert. Het beheert computing-bronnen, procesisolatie en deployment. Wanneer een coding-agent bijvoorbeeld een test moet uitvoeren, coördineert de harness de actie, terwijl de runtime de omgeving biedt waarin de test draait.

Waar past een Agent Harness in de AI Infrastructuur-stack? 

De harness is de sluitsteen van het control-plane-verhaal dat in deze reeks is verteld. De AI Gateway beheert model-verkeer; de MCP Gateway beheert tool-verkeer; de Agent Gateway beheert agent-tot-agent-verkeer; het Skills Registry beheert herbruikbare, geversioneerde skills; en de harness is de runtime die ze samenbrengt in een beheerde agent. Deze draait in hetzelfde plane, zodat orchestratie, governance en observabiliteit in één systeem blijven in plaats van verspreid te zijn over verschillende lagen.

Die co-locatie is de reden dat de harness referenties buiten definities kan houden, destructieve tools eenmalig kan afschermen en een run end-to-end kan traceren: het voegt niet achteraf governance toe aan een agent-runtime, het draait de agent-runtime binnen de governance-plane die er al was. Voor Sofia is dat het verschil tussen drie teams standaardiseren op één beheerde runtime, of drie maatwerk-runtimes blijven babysitten.

Hoe verhoudt een Agent Harness zich tot Beheerde Agent-platformen? 

TrueFoundry is niet de enige beheerde harness, en de alternatieven zijn goed. Anthropic's Claude Managed Agents en LangChain's LangSmith Managed Deep Agents zijn beide sterke gehoste runtimes, en voor veel teams passen ze uitstekend. De nuttige manier om ze te vergelijken is niet een scorebord; het is een verschil in ontwerpfilosofie, en welke filosofie past, hangt af van uw situatie.

Zoals gedocumenteerd op het moment van schrijven, leunen veel managed-cloud-runtimes op pro-code en API-first: u definieert agents, sessies en omgevingen via een SDK of REST API, registreert referenties per agent of workspace (vault ID's, header-arrays), stelt beleid voor tool-goedkeuring in per agent en draait in de beheerde cloud van de provider. 

Dat is een strak, nauw geïntegreerd model — vooral als u al gestandaardiseerd bent op één modelprovider of één orchestratie-framework, en uw team er ervaring mee heeft om agents in code te definiëren. De filosofie van TrueFoundry is anders: primair een no-code builder (met dezelfde definitie beschikbaar via SDK en REST), referenties gecentraliseerd in de gateway control plane in plaats van geregistreerd per agent, goedkeuring voor destructieve tools één keer organisatiebreed ingesteld, modeltoegang beheerd met RBAC en budgetten over alle providers heen, en deployment beschikbaar als SaaS, self-hosted of on-prem. De afweging is integratie-eenvoud binnen één ecosysteem versus gecentraliseerde governance over meerdere systemen.

Beheerde harness vs. zelf bouwen

Als u uw eigen agent harness bouwt, heeft u de controle over tool-uitvoering, contextbeheer, rechten en workflows. Maar uw team moet dan ook retries, foutafhandeling, beveiligingscontroles en observabiliteit bouwen en onderhouden.

Een beheerde harness biedt veel van deze mogelijkheden direct uit de doos, waardoor de hoeveelheid infrastructuurwerk afneemt en uw team zich kan richten op de logica van de agent. Zelf bouwen is logisch wanneer u gespecialiseerd gedrag nodig heeft en dit kunt onderhouden. Een beheerde optie is vaak beter wanneer u sneller wilt deployen en de operationele overhead wilt verminderen.

Waarom "Bouwen vs. Kopen" van de Harness de Echte Beslissing Is

Hier is de confronterende rekensom van agentic AI: het model kost een paar regels API-aanroep, de tools staan in een registry en de harness is de rest van het systeem. De orchestratielus met zijn stopvoorwaarden, de sandbox met zijn levenscyclus, het afhandelen van referenties, de goedkeuringsstappen, de tracing per stap en de kostenverantwoording — dat is waar de maanden aan engineering in gaan zitten, en vrijwel niets daarvan is specifiek voor uw use case. Het is niet-onderscheidend zwaar werk, dat telkens opnieuw wordt gebouwd als een team vanaf nul aan een agent begint.

Dat is de valkuil waar Sofia's drie teams onafhankelijk van elkaar in zijn getrapt. Elk team besteedde aanzienlijke inspanning aan de runtime-infrastructuur in plaats van aan de daadwerkelijke taak van de agent, en elk team leverde een andere, onvolledige versie op met eigen tekortkomingen — de gecommitte API-sleutel, de ontbrekende goedkeuringsstap, de afwezige trace. Het kopen van de harness (of het adopteren van een beheerde) is de beslissing om te stoppen met het opnieuw bouwen van de infrastructuur en deze één keer te standaardiseren, zodat teams hun tijd kunnen besteden aan instructies, tools en skills — de onderdelen die echt van hen zijn.

Beheer elke AI-agent vanaf één platform

Beheer modeltoegang, MCP-tools, referenties en goedkeuringsbeleid centraal zonder runtime-infrastructuur voor elke agent opnieuw te hoeven bouwen.

Boek een demo

De TrueFoundry Agent Harness: Model + MCP + Skills + Instructies

De Agent Harness van TrueFoundry is een beheerde harness gebouwd bovenop de AI Gateway en MCP Gateway. Het mentale model voor de bouwer is bewust compact gehouden: u kiest een model, verbindt MCP-servers, voegt skills toe en schrijft instructies. 

TrueFoundry levert de rest als beheerde functionaliteiten — orchestratie, sandbox-levenscyclus, tool-uitvoering, goedkeuringsflows, governance en observabiliteit — terwijl teams eigenaar blijven van de instructies, tools, het beleid en de deployment-status van de agent. Er is een no-code builder in de console voor niet-ontwikkelaars en een Python SDK en REST API voor dezelfde agent-definitie. Hierdoor is de weg van "kies een model" naar "werkende agent" kort en kan dezelfde definitie vanuit code worden aangestuurd.

Een declaratief gedefinieerde agent — model, tools, skills, instructies (ter illustratie)

Let op wat er niet in die definitie staat: geheimen. Het model is een naam, de MCP-servers zijn namen, de skill is een geversioneerde referentie. Die afwezigheid is precies waar het in het volgende gedeelte om draait, en het is het verschil tussen een agent-definitie die u veilig naar een repo kunt committen en een definitie waarbij dat niet kan.

Waarom Uw Agents Geen API-sleutels en Referenties Moeten Afhandelen

De meest ingrijpende ontwerpkeuze in een harness is de plek waar referenties zich bevinden. De verleidelijke oplossing — het plakken van de provider-sleutel en de tool-tokens in de agent-definitie — is precies wat de sleutels van Sofia in een repository deed belanden. Het schaalt niet (elke agent en elke gebruiker registreert geheimen opnieuw), het is niet schoon te roteren (een sleutelwijziging raakt elke definitie) en het blijft niet veilig (geheimen verspreiden zich naar overal waar definities worden opgeslagen).

De harness van TrueFoundry kiest voor de andere aanpak: er worden nooit API-sleutels of referenties in agent-definities geplakt. Provider-referenties bevinden zich in de AI Gateway en agents verwijzen naar modelnamen terwijl RBAC, budgetten en guardrails worden afgedwongen bij de gateway. 

MCP-authenticatie — OAuth-tokens, API-sleutels — bevindt zich in de MCP Gateway, die de injectie van referenties, het verversen van tokens en de delegatie per gebruiker afhandelt. Zo authenticeren gebruikers inline en roept de agent tools aan op naam. Skills worden gepubliceerd in de Skills Registry met versiebeheer en RBAC, zodat agents kunnen kiezen uit een beheerde catalogus. Platformteams configureren toegang eenmalig; agent-bouwers komen nooit in aanraking met geheimen.

De Mogelijkheden die het Productierijp Maken

Een agent harness heeft meer nodig dan alleen een lus die verzoeken naar een model stuurt en tool-aanroepen uitvoert. Om betrouwbaar te draaien in productie, moet het de context beheren, de uitvoering van tools controleren, storingen afhandelen en weten wanneer er menselijke invoer nodig is. De harness van TrueFoundry brengt deze mogelijkheden samen om veelvoorkomende problemen op te lossen die ontstaan wanneer agents echte taken verwerken.

Context- en Statusbeheer

Langdurig draaiende agents kunnen hun contextvensters vullen met tool-resultaten, gespreksgeschiedenis en tussenliggende outputs. Context-engineering helpt die informatie beheersbaar te houden. De harness van TrueFoundry ondersteunt subagents om deeltaken te isoleren, code-modus om gegevens programmatisch te verwerken, het uitbesteden van grote resultaten om te voorkomen dat te grote tool-outputs het contextvenster overweldigen, en compactie voor langere runs. Dit is een aanvulling op het sessiebeheer aan de gateway-zijde zoals beschreven in onze handleiding voor context-engineering.

Tool-uitvoering en Sandboxing

Een sandbox biedt een agent een gecontroleerde omgeving om code uit te voeren, bestanden te verwerken en taken uit te voeren zonder de host of gevoelige systemen rechtstreeks bloot te stellen. Dit is vooral belangrijk voor coding-agents en workflows die onbetrouwbare invoer verwerken. De harness moet ook tool-aanroepen en de resultaten daarvan beheren, zodat de agent kan blijven werken binnen de gestelde limieten.

Menselijke Goedkeuring en Guardrails

Sommige tool-aanroepen mogen niet worden uitgevoerd zonder expliciete goedkeuring. Human-in-the-loop-controles stellen de harness in staat een run te onderbreken totdat een geautoriseerd persoon een gevoelige actie goedkeurt. TrueFoundry kan destructieve tools centraal markeren bij de MCP Gateway, zodat de goedkeuringsvereiste geldt voor elke agent die die tools gebruikt, in plaats van te vertrouwen op elke individuele agent-bouwer om dit correct te configureren.

Foutafhandeling en Langdurige Taken

Productie-agents moeten mislukte tool-aanroepen, retries, uitvoeringslimieten en onderbrekingen kunnen afhandelen zonder het overzicht op de taak te verliezen. Tracing van runs helpt teams ook te begrijpen wat er bij elke stap is gebeurd en storingen te onderzoeken. Deze controles zijn bijzonder belangrijk wanneer een taak meerdere tools omvat of lang duurt om te voltooien.

Generatieve UI en Agent-interactie

Agents hebben soms meer nodig dan een tekstueel antwoord om een taak te voltooien. De harness kan interacties ondersteunen waarin een agent de gebruiker om verduidelijking vraagt of keuzes voorlegt voordat hij doorgaat. Generatieve UI gaat nog een stap verder door de agent in staat te stellen gestructureerde inhoud te streamen, zoals kaarten, tabellen en grafieken, die de client kan renderen. Dit maakt het voor gebruikers eenvoudiger om informatie te beoordelen en te reageren terwijl een taak wordt uitgevoerd.

Elke mogelijkheid richt zich op een specifieke foutmodus. De onderstaande tabel laat zien hoe ze bijdragen aan een productierijpe agent harness.

In dit voorbeeld streamt de harness run-events, logt tool-aanroepen en pauzeert wanneer een tool goedkeuring vereist. De code dient ter illustratie; de exacte event-namen en API-methoden hangen af van de implementatie.

De goedkeuringsstap verdient speciale aandacht omdat deze bepaalt wanneer een agent zelfstandig kan handelen. In plaats van aan elke agent-bouwer te vragen goedkeuring te configureren voor elke gevoelige actie, kunnen platformteams destructieve tools centraal markeren.

Hier vereist het uitvoeren van een terugbetaling goedkeuring, terwijl het lezen van een saldo dat niet vereist. Het centraliseren van dit beleid helpt om dezelfde regel toe te passen op alle agents die de tool gebruiken.

Het vereisen van goedkeuring is echter slechts een deel van de controle. Een nuttig beleid moet specificeren welke tools goedkeuring vereisen, wie kan goedkeuren, of goedkeuring geldt voor een individuele aanroep of een gehele sessie, welke informatie de beoordelaar ziet en hoe lang de goedkeuring geldig blijft. Een verzoek tot terugbetaling moet bijvoorbeeld het bedrag en de ontvanger tonen vóór de goedkeuring. Zonder die context kan een persoon geen geïnformeerde beslissing nemen.

Door deze regels af te dwingen op platformniveau, helpt een agent harness teams om consistente controles te handhaven naarmate ze meer agents bouwen en deployen.

Observabiliteit: Één overzicht voor Model-, Tool- en Agent-verkeer

Twee van Sofia's drie teams konden niet reconstrueren wat een agent tijdens een bepaalde run deed, wat het observability-gat is waar deze hele serie steeds naar terugkeert — nu op agent-niveau. Een harness moet per run een end-to-end trace uitsturen: elke LLM call, tool call, sandbox-uitvoering en subagent, waarbij kosten, tokens en latency per stap worden toegewezen. Zonder dat is een zich misdragende agent een black box, en het enige signaal dat je krijgt is de factuur of de klacht.

Wat de trace bevat is even belangrijk als het bestaan ervan. Een nuttig record per stap verbindt de run- en stap-identiteit, het betrokken model en de tool, het goedkeuringsbesluit, de sandbox-sessie en de kosten, tokens en latency van de stap — genoeg om elke run achteraf te reconstrueren, toe te wijzen en te beprijzen:

Een illustratief trace-record per stap (vorm is gateway-specifiek)

Een run is dan gewoon de geordende reeks van deze records onder één run_id — wat "de agent deed iets duurs" verandert in "stap 4 riep issue_refund aan na een goedgekeurde gate, wat dit bedrag kostte."

Omdat het harness van TrueFoundry op hetzelfde gateway-vlak draait als model- en MCP-verkeer, erft het de analytics, request logs, OpenTelemetry-export en Prometheus- en Grafana-integratie van de AI Gateway — één centraal overzicht over model-, MCP- en agent-verkeer in plaats van drie losstaande dashboards. 

Meld je aan om TrueFoundry in actie te zien.