Agenten zijn altijd nieuwkomers. Het is tijd dat we er voor ontwerpen.

Tegen 2027, 74% van de bedrijven zal naar verwachting agents in enige mate gebruiken, volgens een recent Deloitte‑onderzoek. Jarenlang hebben we software ontworpen en gebouwd om de menselijke ervaring bij het navigeren door onze apps, websites, besturingssystemen en documenten te verbeteren. Nu is de gebruiker helemaal geen mens meer. Dit heeft bredere implicaties dan alleen de verschuiving van dashboards en de gecontroleerde werkstromen die we voor menselijke taken ontwerpen. We bevinden ons in een moment waarin we de operationele omgevingen van agents moeten ontwerpen, terwijl ook menselijke werkstromen ontwerpen om de agent‑ervaring binnen deze omgevingen effectief te begeleiden.  

We staan nog in de beginfase van ons leerproces over wat agents daadwerkelijk van ons nodig hebben om herhaalbaar en betrouwbaar succesvol te zijn. De instinctieve neiging is om agentintegratie puur als een prompting‑ of UI‑probleem te zien. Het ontwerpen van een goed beheerde uitvoeringsomgeving is nieuw terrein voor ons als cultuur. De onderliggende principes van goed ontwerp en goed management zijn echter onveranderd: we verschuldigen agents duidelijke context, ondubbelzinnige richting en expliciete intentie.

Context: Waarom coderen eerst kwam

Context is waarschijnlijk de belangrijkste invoer als we willen dat agents consistent leveren op het niveau dat we voor ogen hebben. Software‑ontwikkeling heeft er meer van vastgelegd dan bijna elk ander vakgebied: repositories, API‑schema’s, de relaties tussen systemen, code‑reviews en community‑discussies. Het is dan ook logisch dat AI‑frontier‑labs begonnen met coderen. Het is een van de weinige domeinen waarin al een aanzienlijke hoeveelheid context schriftelijk is vastgelegd. 

Maar zoals elke nieuwe medewerker in een softwareteam je zal vertellen, zelfs met al die data blijven agents de institutionele herinnering missen die is ingebed in de ongeschreven regels die niemand ooit heeft gedocumenteerd. Die kloof is wijdverspreid: 43% van de ontwikkelaars maakt zich zorgen dat AI‑tools onvoldoende context hebben over hun specifieke project of codebase. Taciete kennis omvat alles van alledaagse conventies, zoals favoriete bibliotheken voor bepaalde taken, tot kritieke operationele “spook‑” situaties: een nachtelijke hotfix die voor altijd blijft hangen, of een ogenschijnlijk lege databasekolom die in het geheim een aangepast omzetrapport ondersteunt. Deze context leeft in het hoofd van een senior engineer, een recente Slack‑thread, of nergens. Ze staat zelden in de codebase zelf.  

Als dit waar is in software, een van de best gedocumenteerde vakgebieden, is het makkelijk te begrijpen waarom agents moeite hebben om vanaf dag één effectief te presteren in vele andere sectoren. In de gezondheidszorg en de juridische wereld wordt een groot deel van de institutionele kennis die het dagelijkse werk vormt, geleerd en geïnternaliseerd. Ze leeft in de ervaring van mensen in plaats van in formele documentatie. Een juridische agent kent bijvoorbeeld de voorkeurstructuur, toon of argumentatie van een bepaalde partner niet, terwijl een zorg‑agent de lokale werkstromen en escalatiepraktijken van een drukke kliniek die klinisch‑geleide triage ondersteunt, niet begrijpt. Alleen documentatie kan die kloof niet dichten, want de uitdaging is niet alleen toegang tot informatie; het gaat om de overdracht van context. Om agents te geven wat ze nodig hebben om te slagen, moeten we ze onboarden zoals we een nieuwe medewerker zouden inwerken.

Richting: Waarom osmose niet werkt

Het onboarden van een nieuw teamlid vereist meer dan alleen het leveren van de juiste materialen en toegang. Wanneer we geïnvesteerd zijn in het succes van onze omgeving, geven we duidelijke richting over wat er met de nieuwe materialen en toegang moet gebeuren: verwachtingen, helderheid over wat we willen bereiken, en feedback onderweg. Ik breng dezelfde mentaliteit mee bij het ontwerpen voor agents. Ik geef duidelijke, specifieke richting (ten opzichte van de taak die voorhanden is). Dat geldt voor elk teamlid, ongeacht hun anciënniteit. In een nieuw‑medewerker‑scenario moet de richting echter verder gaan, omdat ze nog geen institutionele context hebben.

Beschouw een agent als een nieuwe medewerker die nooit ophoudt nieuw te zijn. Hij is leergierig en bekwaam (en eerlijk gezegd heeft hij grenzeloze energie), maar hij kan niet evenveel ongeschreven regels oppikken en behouden als een mens dat in de loop van de tijd kan. Mensen leren via osmose en ervaring, terwijl agents leren van een architectuur die expliciet in hun werkomgeving is ingebouwd.

Bij een nieuwe medewerker kun je die kloof in de loop van de tijd dichten met vragen, feedback en nieuwe inzichten die ze opdoen over de processen en voorkeuren van de organisatie. Letterlijk koffiemachine‑gesprekken of team‑lunches. Bij een agent moet je die kloofdichting in het ontwerp zelf integreren. Dit kan omvatten: 

• De agent een gestructureerd context‑venster geven dat duurzame regels, taak‑specifieke feiten en relevante geschiedenis scheidt, in plaats van een stapel documenten in zijn schoot te gooien. 
• Zijn permissies en besluit‑grenzen vooraf definiëren: wat hij zelfstandig mag doen, wat goedkeuring vereist, en wat hij nooit mag benaderen. 
• Enkele concrete voorbeelden van sterke output direct in de ervaring embedden, zodat de agent een helder model heeft van hoe het werk moet worden uitgevoerd.
• Eerdere doodlopende wegen die je bent tegengekomen delen.

Het ontwerpen van een goed beheerde agent‑omgeving gaat niet over het makkelijker maken van het werk voor het model. Het gaat erom het menselijke engineeringteam te beschermen tegen onzichtbare technische schuld. Maar zelfs een goed geleide agent kan instructies perfect opvolgen en toch de kern missen. Richting vertelt wat te doen, maar niet hoe “goed” eruitziet. Die kloof wordt opgevuld door intentie.

Intent: Waarom agents naar het midden afdrijven

Het is belangrijk te onthouden dat agents patroon‑matchende machines zijn, getraind op enorme hoeveelheden kennis en van nature geneigd om het statistische gemiddelde te leveren. Zonder duidelijke, expliciete intentie is dat gemiddelde resultaat precies wat een agent teruggeeft. Vraag een agent om “een endpoint voor gebruikersauthenticatie toe te voegen,” en hij genereert een klassiek Express‑route‑voorbeeld met basis‑wachtwoord‑hashing. Het werkt, maar negeert volledig de op maat gemaakte authenticatieservice van je team, slaat verplichte telemetrie over en breekt je gestandaardiseerde foutopmaak. Het is een voldoende functie op papier, maar afhankelijk van de context een architecturale fout in de praktijk. De gemakkelijke introductie van zulke “bugs” kan niet genoeg benadrukt worden.

Om dit te voorkomen, moet richting worden gekoppeld aan actieve intentie‑verificatie en logging. Guardrails moeten niet alleen controleren of de code compileert, hoewel dat belangrijk is. Guardrails moeten expliciet de opinie‑gedreven standaarden, edge‑case‑regels en domein‑context handhaven die generieke output omvormen tot productieklaar werk. Logging is belangrijk als een systeemstatusindicator voor ons mensen. Deze traceerbaarheid is cruciaal voor vertrouwen. 

In menselijke interacties is er veel ruimte voor onzekerheid. Iemand kan een eerste versie met je delen, en samen kun je bespreken wat sterk is en wat verbetering nodig heeft. Dit werkt omdat we niet verwachten dat onze menselijke collega’s autonome machines zijn. Om de kracht en belofte van agent‑collega’s (die we wel autonomer moeten laten werken…) echt te benutten, kunnen we veel van deze directionele controles inbouwen. De uitwisseling moet nog steeds plaatsvinden, maar kan niet volledig op handmatige inspanning rusten. Door duidelijke acceptatiecriteria en verificatieregels vooraf in te bouwen, stel je de agent in staat eigen interne feedback‑loops te draaien. Ontwerpen voor foutpreventie is een ander solide UX‑principe dat we in deze nieuwe wereld kunnen toepassen: agents de mogelijkheid geven om lage vertrouwensniveaus te signaleren voordat ze zich aan een actie committeren, in plaats van stilletjes te defaulten naar een beste gok.

Waar de metafoor faalt

Het nieuw‑medewerker‑kader werkt, totdat het dat niet meer doet. Bij een menselijke aanwerving leidt ervaring tot competentie, wat leidt tot oordeel. Het zien van je nieuw‑medewerker die de “waarom” achter context en richting internaliseert, bouwt vertrouwen op over tijd, en over het algemeen is dit cumulatief. Een agent heeft nergens om die ervaring op te slaan en te accumuleren.

De eerste week en de honderdste week van een nieuw‑medewerker zien er verschillend uit. De eerste taak en de duizendste van een agent zien er identiek uit, tenzij je iets ontwerpt en bouwt om ze te onderscheiden. Dit is onze nieuwe ontwerpuitdaging.

Agentverantwoordelijkheid hangt af van ontwerp

Als verantwoordelijkheid niet in de agent kan leven, moet ze in de structuur eromheen bestaan. Het komt neer op dezelfde drie vragen die ik zou stellen voordat ik werk toevertrouw aan een nieuw‑medewerker: Welke context hebben ze? Welke richting heb ik hen gegeven? Wat is mijn werkelijke intentie?

De volgende keer dat je een taak aan een agent toevertrouwt, controleer dan niet alleen de output. Controleer eerst je eigen inputs. Heb je de context gegeven die een nieuw‑medewerker op de eerste dag nodig zou hebben? Was je richting specifiek genoeg om letterlijk genomen te kunnen overleven? Was je intentie duidelijk genoeg zodat “het mediane antwoord” niet het beste was dat het kon leveren?

Met deze duidelijke richtlijn in de hand (in bytes?), gebeurt er iets interessants: een agent heeft geen lange runway nodig om betrouwbaar te worden. De context, richting en verificatie die je vooraf inbouwt, bepalen hoe hij elke taak uitvoert. Een nieuw‑medewerker wint je vertrouwen over tijd; een agent moet dat vertrouwen elke keer verdienen via het systeem dat jij hebt ontworpen. Verantwoordelijkheid is niets wat het ontwikkelt, het wordt vanaf het begin ingebouwd. De vraag is niet wanneer je agent klaar is voor meer verantwoordelijkheid. Het is of je hem zo hebt ontworpen dat hij die verantwoordelijkheid bij elke afzonderlijke taak verdient.