De operations lead van een Rotterdams logistiek bedrijf mailde op een maandag: "We hebben een AI-agent nodig die onze support-inbox afhandelt. Kun je dat scopen?" Twee alinea's, geen bijlages, geen voorbeeldtickets. We stuurden geen offerte terug. We stuurden een call van 40 minuten en een gedeeld document met tien vragen. Op vrijdag hadden we een schriftelijke ja of nee, met reden. Dat document is de audit. Het is het waardevolste uur werk in het hele traject.
De meeste agent-projecten lopen vast op deze stap, niet bij de build. Bouwen is het makkelijke deel. Het bepalen-wat-je-bouwt is waar het budget verdampt, en waar de agent zes maanden later iets gênants doet in productie. Dus hebben we opgeschreven waar we naar kijken, elke keer, voor er een agent live gaat.
Wat de audit is, en wat niet
Het is geen discovery-workshop met plakbriefjes en geprinte persona's. Het is een checklist met tien vragen die we draaien voor elke agent-build, ongeacht de omvang. Het doel is om het project te vinden dat niet zou moeten bestaan, voor we er iemand voor laten betalen. Drie van de tien audits eindigen met "niet bouwen, eerst het onderliggende proces fixen". Dat is de audit die zijn werk doet, niet die faalt.
De vragen hieronder zijn saai. Ook dat is het punt. Er is dit jaar een vloedgolf aan AI-agent content geweest, en een developer schreef deze week op r/webdev dat hij zich massaal had uitgeschreven voor elke AI-nieuwsbrief en dat zijn hoofd eindelijk weer werkte. De audit is gebouwd voor de lezers in die thread: mensen die de demo's al kennen en alleen willen weten of een build het geld waard is.
Volume en herhaalbaarheid
De eerste schifting is de goedkoopste: hoe vaak per week gebeurt het werk, en hoe vergelijkbaar zijn de instances?
Onder de 20 instances per week, met flinke variatie ertussen, en het antwoord is bijna altijd nee. Niet omdat een agent het niet kan. Wel omdat de kosten van bouwen, monitoren en onderhouden van de agent jarenlang harder lopen dan de uren die je bespaart. We hebben founders €15k zien uitgeven aan het automatiseren van een taak die hun office manager in 90 minuten per week doet. Die som komt nooit meer goed.
We geven klanten een one-liner mee die ze kunnen draaien op een export van hun mail-archief:
find ./inbox -name "*.eml" -print0 \
| xargs -0 grep -h "^Subject:" \
| sed 's/Re: //gi; s/Fwd: //gi' \
| sort | uniq -c | sort -rn \
| head -50We willen zien dat de long tail instort. Als 40% van de inkomende mail valt onder vijf onderwerppatronen, hebben we een agent-project. Als de top 50 patronen elk 2% van het volume vertegenwoordigen, hebben we dat niet, en zeggen we dat hardop.
De realiteit van datatoegang
De helft van de agent-projecten sneuvelt hier. De klant wil een agent die leest uit Systeem A, schrijft naar Systeem B, en kruisrefereert met CRM C. Wij vragen om API-keys. Systeem A heeft geen API. Systeem B vereist een SOAP-login die sinds 2019 niet meer is gebruikt. Het CRM is een Notion-workspace waar één persoon admin is, en die persoon zit op ouderschapsverlof.
Dus dwingt de audit ons om voor elk systeem dat de agent raakt een spec van vijf regels op te schrijven: lezen of schrijven, transport (API, IMAP, scraping, database, file drop), rate limit, auth-mechanisme, en wie de credential-rotatie beheert. Als drie van die antwoorden terugkomen als "dat zouden we moeten scrapen", is het project eerst een back-end rebuild, en daarna pas misschien een agent. Dat zeggen we tegen de klant. Soms bedanken ze ons. Soms huren ze iemand anders in die wel gaat scrapen, en bellen ze ons zes maanden later als de scraper kapot is.
De decision boundary
Hier valsspelen de meeste agent-demo's stilletjes. De demo-agent in de YouTube-video neemt beslissingen omdat de consequentie van fout zitten is "de demo ziet er slecht uit". Jouw productie-agent neemt beslissingen waarbij fout zitten betekent: een factuur naar de verkeerde klant, een antwoord aan een journalist met een gehallucineerd citaat, of een refund van €4.000 aan een klant die er nooit om heeft gevraagd.
Dus trekken we een lijn. Aan de ene kant: dingen die de agent zonder toezicht doet. Aan de andere kant: dingen die hij opstelt zodat een mens ze kan goedkeuren. Die lijn wordt opgeschreven, getekend, en woordelijk overgenomen in de system prompt van de agent zelf.
Als de kosten van een verkeerde beslissing bij een bepaalde actie hoger zijn dan de kosten van één goedkeuringsklik door een mens, hoort die actie achter een approval gate. Geen uitzonderingen, ook niet voor klanten die zeggen dat ze het model vertrouwen.
Source of truth en het schrijfpad
Waar staat het canonieke antwoord voor elk stukje data dat de agent raakt? Als het adres van een klant in drie systemen staat en die zijn het oneens, kiest de agent er één en heeft hij ongelijk tegenover de andere twee. We moeten weten welke wint, en dat moeten we opschrijven voor er code wordt geschreven.
Schrijfpaden krijgen extra aandacht. De audit stelt één vraag: als de agent naar dit systeem schrijft, kan een mens die schrijfactie binnen vijf minuten terugdraaien? Zo nee, dan gaat de schrijfactie door een draft-and-approve gate. Die regel hebben we nog niet één keer betreurd.
Observability voor de release, niet erna
Elke agent die wij opleveren draait met gestructureerde logging op elke tool-call, elke prompt, elke response, elke beslissing. Niet omdat we van plan zijn om naar de logs te kijken, maar omdat er een dag komt dat we naar de logs móéten kijken, en dat is een dinsdag, en de founder zit op dat moment in een call met zijn grootste klant.
Een redelijke logregel ziet er zo uit:
{
"ts": "2026-05-13T09:14:22Z",
"agent": "invoice-chase",
"run_id": "rn_01HXY8R3K2",
"tool": "send_email",
"input_hash": "sha256:9f2b8c…",
"decision": "draft_for_approval",
"approver": "anna@client.nl",
"latency_ms": 1840,
"tokens_in": 3204,
"tokens_out": 412
}De launch van Voker die deze week Hacker News haalde gaat precies hierover: agent-specifieke analytics wordt een eigen productcategorie, omdat logs uit een chat-model geen logs zijn uit een Rails-app. Je moet de prompt kunnen replayen, de tool-calls in volgorde zien, en elke beslissing kunnen koppelen aan een specifieke commit en een specifieke approver. Als je agent-leverancier dat overzicht niet kan tonen, is dat een rode vlag die de audit oppikt voor procurement dat doet.
Security en credentials
Dit is het deel dat niemand wil lezen. Lees het toch.
Open de CISA known-exploited vulnerabilities catalog en elke week komen er nieuwe CVE's bij, vaak in de CMSes, plugins en ERP's waar kleine bedrijven op draaien. Een agent met credentials voor een kwetsbaar systeem is een credential-lekkende versneller, geen magisch schild. De audit checkt waar de secrets van de agent staan, wie ze kan roteren, en wat er gebeurt als de host van de agent om 3 uur 's nachts op zondag wordt gecompromitteerd.
We gebruiken scoped service-accounts met de minimale rechten om het werk te doen. Geen gedeelde admin-keys. Geen langlevende OAuth-tokens die in een .env-bestand staan in een private GitHub-repo. (Dat hebben we gezien. De repo was niet zo privé als de founder dacht.) De OWASP Top 10 voor LLM Applications dekt de meeste categorieën die het checken waard zijn; wij behandelen die als basislijn, niet als plafond.
Handoff en de kill switch
Elke agent die we bouwen heeft een noodluik. Drie dingen moeten kloppen. De agent moet kunnen herkennen dat hij buiten zijn competentie zit en stoppen. De handoff heeft een specifieke menselijke eigenaar, geen gedeelde mailbox. De handoff bevat genoeg context dat die mens het werk niet helemaal opnieuw hoeft te doen.
Kun je die mens niet bij naam noemen, dan heb je geen agent-project. Dan heb je een demo voor de school-techbeurs.
De kill switch is hetzelfde idee, opgeschaald: één commando, één plek, één persoon kan het uitvoeren. Geen PagerDuty-page van vijf stappen. Geen "vraag het de developer die het gebouwd heeft". Eén regel in een runbook die elke operations lead op zaterdagavond om 23:00 kan draaien, zonder de studio te bellen.
De shadow run van twee weken
De laatste vraag voor we tekenen: mogen we de agent twee weken in shadow mode draaien? Dezelfde inputs als productie, maar de outputs gaan naar een review-queue in plaats van naar klanten. We vergelijken de queue met wat de mensen daadwerkelijk deden. Als shadow het in meer dan 15% van de routinegevallen oneens is met de mensen, gaat hij niet live. Dan tunen we. Soms tunen we nog twee weken. Soms concluderen we dat de workflow lastiger is dan de audit suggereerde, en heronderhandelen we de scope.
De r/artificial thread van deze week met de titel "an enormous crash just waiting to happen" gaat vooral over waarderingen en capex, maar dezelfde logica geldt een verdieping lager op agent-niveau. De meeste productie-failures die we hebben gezien komen van agents die zonder shadow run live zijn gezet, verkocht op de kracht van een demo. De audit is de goedkope verzekering tegen dat patroon.
Het kleinste wat je vandaag kunt doen
Pak één workflow in je team waar iemand dit kwartaal drie keer over heeft geklaagd. Open een leeg document. Beantwoord voor die workflow de tien vragen hierboven: volume, herhaalbaarheid, datatoegang, decision boundary, source of truth, schrijfpad, observability, security, handoff, shadow run. Ben je binnen een uur klaar, dan heb je nog geen agent-project. Dan heb je een procesdocumentatie-project, en dat is goedkoper, en sowieso een voorwaarde.
Toen we de inbox-triage agent voor dat Rotterdamse logistiek bedrijf bouwden, liepen we ertegenaan dat twee van hun drie systems of record het in 8% van de gevallen oneens waren over klanttelefoonnummers. We hebben dat opgelost door de agent het conflict aan een mens te laten voorleggen in plaats van te gokken, en de oplossing terug te loggen naar één canoniek record. De printbare versie van deze checklist is dezelfde die we bij elk AI-agent-traject gebruiken. Mail ons en we sturen 'm op.
