Harness engineering: bouw een werkomgeving rond je AI-agent

Je vraagt een AI-agent om een fout te herstellen. Hij verandert drie bestanden en meldt dat het is opgelost. Morgen ontdekt iemand dezelfde fout via een andere route. Was het model niet slim genoeg, of kon het niet zien wat er werkelijk moest kloppen?

Harness engineering gaat over die tweede vraag: de werkomgeving rond het model zo inrichten dat de agent gericht kan handelen, zijn resultaat kan controleren en bruikbaar werk achterlaat.

Een harness is de inrichting waarmee een model als agent kan werken: informatie ontvangen, gereedschap gebruiken, resultaten waarnemen en verdergaan. Harness engineering is het ontwerpen en onderhouden van die inrichting. Het gaat bijvoorbeeld om welke projectuitleg beschikbaar is, welke bestanden een agent mag wijzigen en hoe hij merkt dat een aanpassing verkeerd uitpakt.

LangChain beschrijft de harness als de code, configuratie en uitvoeringslogica rondom het model. Dat is een bruikbare invalshoek, geen verplicht boodschappenlijstje. Een kleine app kan genoeg hebben aan heldere startinstructies, beperkte toegang en een paar goede controles. Elke extra voorziening moet een concreet probleem oplossen.

De prompt beschrijft de opdracht: herstel bijvoorbeeld het annuleren van een reservering. Het model interpreteert die opdracht en doet voorstellen. De harness geeft het model toegang tot de bestaande annuleringslogica, laat tests uitvoeren en toont de fout die nog optreedt. Een beter geformuleerde prompt vervangt die toegang niet.

Scaffolding betekent letterlijk ondersteunende structuur. Binnen AI gebruiken auteurs het soms bijna als synoniem voor harness. In softwareprojecten kan scaffolding ook alleen de startstructuur van een app betekenen. Spreek daarom af wat je bedoelt. Onze begrippenpagina over scaffolding geeft de korte uitleg; hier gaat het om de volledige onderhoudsronde rond een model.

Neem een kleine app voor een gedeelde werkplaats. Medewerkers reserveren machines. Een annulering moet de machine weer beschikbaar maken, terwijl de oorspronkelijke reservering zichtbaar blijft als geannuleerd. Dit is een oefencasus: we ontwerpen het onderhoudsproces, zonder een uitgevoerd project te suggereren.

De foutmelding luidt: na annuleren blijft een tijdslot soms bezet. De eigenaar geeft de agent drie relevante bronnen: de gewenste reserveringsregels, de bestanden rond beschikbaarheid en een voorbeeld met verzonnen reserveringen. Daarnaast staan het startcommando en het testcommando klaar. De agent hoeft zo niet eerst een nieuwe architectuur te verzinnen voordat hij de fout onderzoekt.

Leg ook vast wat buiten de taak valt. De agent verandert geen login, betalingslogica of volledige kalenderweergave. Hij werkt aan annulering en het opnieuw berekenen van beschikbaarheid.

Laat de agent eerst beschrijven via welke route hij de fout verwacht. Bijvoorbeeld: de annuleringsactie werkt de reservering bij, maar de beschikbaarheidsberekening telt ook geannuleerde regels mee. Dat blijft een hypothese totdat een gerichte controle het laat zien.

Een bruikbare test reserveert een tijdslot, annuleert het en vraagt opnieuw de beschikbaarheid op. De controle moet vóór de reparatie om de verwachte reden falen. Lukt reproduceren niet, dan rapporteert de agent dat verschil en onderzoekt hij de invoer verder. Hij verklaart de gemelde fout niet opgelost op basis van een vermoeden.

OpenAI laat in zijn engineeringpublicatie over harness engineering zien hoe toegang tot onder meer UI en logs agents feedback kan geven. Mijn vertaling voor deze kleine app: geef de agent precies de waarneming die zijn aanname kan weerleggen.

De onderhoudsagent krijgt een eigen werkversie van de app met voorbeeldgegevens. Hij kan de relevante code lezen, wijzigingen voorstellen en de bestaande tests starten. Productiegegevens en het uitrollen naar gebruikers horen niet bij deze onderhoudsopdracht. De persoon die de app beheert blijft eigenaar van de releasebeslissing.

Ook de tools moeten begrijpelijke uitslagen geven. Een beschikbaarheidscontrole retourneert niet alleen 'succes', maar de onderzochte machine, het tijdslot en de berekende toestand. Een mislukte test toont de verwachte en gevonden waarde. Zo kan de agent zijn volgende stap baseren op een feitelijk verschil.

Je hoeft hiervoor geen heel platform te bouwen. Begin met de voorzieningen die het onderzoek mogelijk maken. De algemene bouwbegrippen staan in de gids over AI coding.

Na de reparatie draait dezelfde controle opnieuw. Controleer daarnaast dat een actieve reservering het tijdslot nog steeds bezet houdt. Anders kan een schijnbare oplossing simpelweg alle reserveringen negeren. Open vervolgens de kalender, annuleer een voorbeeldreservering en controleer wat de medewerker ziet na verversen.

De overdracht noemt de gewijzigde logica, de uitgevoerde controles en eventuele beperkingen. 'API gecontroleerd, browsercontrole nog niet uitgevoerd' is bruikbaarder dan 'alles werkt'. Bewaar voldoende verwijzingen om het resultaat terug te vinden, zonder stapels terminaltekst in elke volgende opdracht te stoppen.

Anthropic beschrijft bij langdurig agentwerk het belang van voortgang die een volgende sessie kan begrijpen. Voor deze app betekent dat: een volgende onderhoudsronde begint bij de actuele toestand en het bewijs van deze reparatie.

Als een agent steeds het verkeerde testcommando kiest, maak het juiste commando vindbaar. Als hij telkens een oud databestand gebruikt, verbeter de bronselectie. Als annuleren via de API werkt maar via het scherm misgaat, ontbreekt er een controle op de gebruikersroute. Harness engineering begint bij zo'n waargenomen tekort.

Je beoordeelt de inrichting dus aan het onderhoud dat ermee lukt. Kan iemand de fout reproduceren, een beperkte wijziging maken en aantonen wat is hersteld? Dan ondersteunt de omgeving het werk. Wil je die aanpak oefenen met agents, context en controles, bekijk de cursus Claude Code voor gevorderden.