De afgelopen twee jaar ging carrièreadvies over AI-agents vooral over het leren om ze goed te prompten. Dat is niet langer de schaarse vaardigheid. De schaarse vaardigheid is het bouwen van de scaffolding waarin een agent zich bevindt — het ding dat steeds vaker een harness wordt genoemd — en het is specifiek genoeg, en lastig genoeg, dat het een eigen functieomschrijving wordt in plaats van een bijkomende verantwoordelijkheid van "de AI-persoon" in een team.

De duidelijkste publieke uitleg van wat dit in de praktijk inhoudt, komt van Lenny's Newsletter, die beschrijft hoe het productmanagementtool ChatPRD een harness bouwde om Sentry-bugs automatisch te debuggen. Het stuk is de moeite waard om helemaal te lezen als je overweegt je hierin te specialiseren, want het maakt een punt dat je makkelijk over het hoofd ziet: het model was nooit het knelpunt. Het team gebruikte de Claude Agent SDK als basis en stak vervolgens het grootste deel van hun engineeringinspanning in een aangepaste terminal-UI en een reeks adapters die de agent verbinden met Sentry, Linear, GitHub en Vercel. Dat is de baan, in het klein. Vier systemen, vier verschillende auth-schema's, vier verschillende datavormen, en een UI waarmee een mens kan meekijken en ingrijpen zonder elke stap te hoeven bewaken.

Waar 'harness' eigenlijk uit bestaat

Als je probeert te bepalen of dit een vaardighedenpakket is dat de moeite waard is om op te bouwen, helpt het om het op te splitsen in onderdelen waarvoor apart wordt aangenomen, of die in elk geval apart worden beoordeeld tijdens een sollicitatiegesprek:

  • Permissieontwerp. Bepalen wat een agent onbeheerd mag doen (een ticket lezen, een PR opstellen) tegenover wat een mens in de lus vereist (mergen, deployen, verwijderen, geld uitgeven) — en dat vastleggen als daadwerkelijk beleid in code, niet als een promptinstructie die het model onder druk zou kunnen negeren. Dit ligt dichter bij access-control-engineering dan bij prompt writing.
  • Tool-adapters. Dunne, goed geteste wrappers rond elk extern systeem (Sentry, Linear, GitHub, Vercel, of wat de stack van jouw bedrijf ook is) die de intentie van de agent vertalen naar een veilige, gevalideerde API-aanroep en het antwoord terugvertalen naar iets waar het model over kan redeneren. Dit is gewone software-engineering — foutafhandeling, retries, schemavalidatie — toegepast op een nieuwe consument.
  • Terminal- of console-UI. Een manier voor een mens om te zien wat de agent doet, acties goed te keuren of af te wijzen, en in te grijpen wanneer die vastloopt. ChatPRD bouwde een eigen versie; veel teams zullen in plaats daarvan kant-en-klare agentconsoles gebruiken, maar iemand moet nog steeds bepalen wat wordt getoond, wat verborgen blijft, en wat een klik vereist voordat het gebeurt.
  • Toolselectie op schaal. Een artikel van Machine Learning Mastery wijst op iets dat de moeite waard is om te weten als je iets bouwt dat verder gaat dan een demo: de nauwkeurigheid van agents bij tool-aanroepen neemt doorgaans af zodra de toolcatalogus ongeveer een dozijn opties overschrijdt — het model begint tools verkeerd aan te roepen, parameters te verzinnen, of vast te lopen op foute aanroepen. De maatregelen die het artikel noemt (bepalen welke tools in een gegeven context überhaupt zichtbaar zijn, retrieval-gebaseerde tool-lookup, doorverwijzen naar gespecialiseerde subagents, expliciete planningsstappen, fallback-logica, en benchmark-harnesses om regressies op te sporen) vormen zelf een checklist van dingen die een harness-engineer moet weten te implementeren, niet alleen moet kennen.
  • Context- en memory-engineering. Dezelfde bron maakt een onderscheid dat de moeite waard is om je eigen te maken: context-engineering (wat in één enkele inferentie-aanroep terechtkomt, en waar) en memory-engineering (wat blijft bestaan tussen sessies, hoe het wordt opgeslagen, hoe het wordt opgehaald) zijn verschillende disciplines met verschillende faalmodi. De bron stelt dat de meeste storingen in langlopende, multisessie-agents terug te voeren zijn op het door elkaar halen van de twee — sessiegeheugen behandelen alsof het gewoon meer context is, of andersom — vooral op het punt waar het systeem beslist wat het moet ophalen.

Het bewijs dat dit een echte, financierbare rol is — niet slechts een nichebezigheid voor hobbyisten

Sceptici zullen terecht vragen of 'harness-engineer' een baan is of slechts een taak binnen de baan van iemand anders. Twee datapunten uit het overzicht wijzen erop dat het richting het eerste beweegt. Ten eerste gebruikte het Aspire-team van Microsoft — een groep van tien personen — GitHub's Agentic Workflows om cross-repo documentatie-PR's te automatiseren, en over twee releases merged het team 82 PR's met een mediaan van 44,8 uur na het uitkomen van de bijbehorende product-PR, zonder extra personeel en zonder procesbijscholing. Dat is een klein team dat buitenproportionele hefboomwerking krijgt, specifiek omdat iemand investeerde in de scaffolding (de workflow-definities, de review-routering, de trigger-logica) in plaats van engineers documentatie-PR's met de hand te laten schrijven. Ten tweede behandelt het SkillOpt-project van Microsoft Research agent-'skill'-bestanden — de instructies en beperkingen die bepalen hoe een agent zich gedraagt binnen zijn harness — als iets dat systematisch geoptimaliseerd moet worden in plaats van met de hand bewerkt, en rapporteert dat het beste of gedeeld beste resultaat werd behaald in alle 52 cellen van een benchmarkraster (zes benchmarks, zeven modellen, drie uitvoeringsmodi), waarbij de geoptimaliseerde skills overdraagbaar bleken tussen verschillende modellen en verschillende harnesses. Of die specifieke tool nu wel of niet de standaard wordt, het is een signaal dat de industrie harness-configuratie begint te behandelen als een engineering-artefact met eigen tooling en benchmarks — hetzelfde traject dat 'DevOps' veranderde van een verzameling ad-hocscripts in een discipline.

Er wordt nu ook infrastructuur gebouwd die expliciet gericht is op deze laag. De nieuw aangekondigde 'Managed Agents'-mogelijkheden van Google in de Gemini API — achtergrond- en asynchrone uitvoering, integratie met externe MCP-servers, aangepaste function calling, credential-refresh tussen interacties — vormen in feite kant-en-klare loodgieterij voor precies de problemen die het ChatPRD-team met de hand oploste. Dat is een normaal patroon: wat het ene team dit jaar op maat bouwt, maakt een platformleverancier volgend jaar tot product. Dat maakt de rol van harness-engineer niet overbodig; het verhoogt de ondergrens en verschuift de baan richting het integreren en configureren van beheerde bouwstenen in plaats van elke adapter vanaf nul te schrijven — vergelijkbaar met hoe cloudinfrastructuur ops-engineers niet overbodig maakte, maar wel veranderde waar ze hun tijd aan besteedden.

Wat dit betekent als je deze rol ambieert

Een paar concrete, controleerbare dingen om op een portfolio of cv te zetten als je geloofwaardig wilt zijn voor dit werk: bouw één adapter end-to-end tegen een echte API die je niet zelf beheert (inclusief auth, foutafhandeling, rate limits — geen happy-path-demo); ontwerp en documenteer een permissiemodel voor een agent dat onderscheid maakt tussen read/propose/act-acties en laat zien waarom elke grens ligt waar hij ligt; en bouw of configureer een review-interface waarbij een mens agentacties goedkeurt voordat ze worden uitgevoerd, aangezien dat het onderdeel is waar de meeste bedrijven op zullen staan voordat ze een agent productie laten aanraken. Als je een aanbod voor een harness-engineeringfunctie beoordeelt of je eigen verantwoordelijkheden afbakent, vraag dan specifiek wie het permissiemodel bezit, wie de adapters bezit, en wie het human-review-oppervlak bezit — in veel teams hebben deze drie dingen op dit moment geen duidelijke eigenaar, en dat is precies het gat dat deze rol probeert op te vullen.

Eén kanttekening die het waard is om ronduit te maken: geen van de bovenstaande bronnen levert een cijfer over de arbeidsmarkt voor deze specifieke titel, en 'harness-engineer' is nog geen functietitel die je in vacatures zult tegenkomen — hij duikt op binnen titels als 'AI infrastructure engineer', 'agent platform engineer', of gewoon 'senior backend engineer, AI systems'. Zie dit als een vaardighedenpakket om op te bouwen en nauwkeurig te omschrijven, niet als een titel om op LinkedIn naar te zoeken.