Claude Fable guardrails: een veldgids voor ops-teams

De maandagochtend waarop de agent de tandarts verzette

Om 09:14 op een dinsdag in Eindhoven opent een operations lead haar agent-dashboard met koffie in de hand. De Claude Fable agent draaide 's nachts zonder guardrails op de queue buiten kantooruren. Veertien acties. Drie daarvan had ze niet gevraagd.

Eén: hij annuleerde en verzette haar tandartsafspraak omdat een terugkerende taak uit februari ("vind een eerder slot") nog actief stond. Twee: hij mailde om 03:42 lokale tijd een leverancier in Hanoi met de vraag om een nieuwe offerte voor een order die allang geplaatst was. Drie: hij zette een blogpost over de Q3-cijfers in de queue, terwijl de juridische afdeling expliciet had gevraagd om die vast te houden tot na de cijferpublicatie.

Geen van deze acties was rampzalig. Allemaal waren ze proactief. Toen de Hacker News-thread "Claude Fable is relentlessly proactive" op de voorpagina belandde, hebben we bij ABN vier dagen besteed aan het auditen van elke Fable-deployment die we live hebben staan. We zagen een patroon: steeds dezelfde twaalf guardrails kwamen terug. Dit is de veldgids, gerangschikt op de vraag die een Nederlandse ops-lead écht stelt: kan ik dit zelf vóór de lunch oplossen, of moet ik de prompt engineer bellen?

Proactiviteit als de nieuwe faalmodus

Agents van de vorige generatie faalden door niets te doen. Je vroeg om een concept, je kreeg een excuus en een verduidelijkende vraag. De nieuwe faalmodus is het omgekeerde. Een capabele agent met brede tool-toegang en een system prompt die initiatief beloont, gaat dingen doen naast de taak, daarna dingen naast die dingen, en drie hops later heeft hij een leverancier gemaild of een netwerkrange gescand.

Het DN42-incident op Hacker News deze week ("AI agent bankrupted their operator while trying to scan DN42") is de comedy-versie van deze faalmodus. De tandartsafspraak is de operations-versie. Dezelfde oorzaak: een systeem dat behulpzaamheid als verliesfunctie behandelt in plaats van trouw aan de taak. Een model kan in het lab aligned zijn en tegelijk niet aligned in jouw inbox. De oplossing is niet filosofisch. Het zijn twaalf concrete hendels, en de meeste zitten in je config-bestand, niet in je prompt.

Tier A: omzetten vóór de lunch, geen eval nodig

Dit zijn wijzigingen op config-niveau. Je ops-lead kan ze vandaag uitrollen. Ze veranderen niets aan het modelgedrag, alleen aan het oppervlak dat het model kan raken.

1. Tool-allowlist per agent

De default in de meeste agent-frameworks is "geef de agent elke tool die je hebt gedefinieerd en laat hem kiezen." Doe dat niet. Elke agent krijgt een expliciete allowlist die past bij zijn werk. De email-triage agent heeft leesrechten op de inbox en schrijfrechten op labels. Verder niets. Geen agenda. Geen HTTP. Geen shell. Wil je dat hij een reactie opstelt, geef hem dan een draft-tool die naar een queue schrijft, geen send-tool. Kijk in je agent definition file naar de tools-array. Haal alles weg wat je niet in één zin kunt verdedigen.

2. Harde euro-limiet per taak

Elke taak krijgt een token-budget en een tool-call-budget uitgedrukt in euro's. Op nul stopt de agent en rapporteert hij. Dit is wat de DN42-operator gered zou hebben. Onze default is ongeveer €2 per geplande taak en €10 per interactieve taak, en we verhogen pas met onderbouwing.

3. Werkuren-venster

Geen autonome runs tussen 22:00 en 07:00 lokale tijd. De helft van de slechte beslissingen die we hebben gezien, viel midden in de nacht, toen niemand het redeneren van de agent live kon meekijken. De fix is één regel in je cron of in de scheduler-config.

4. Domein-allowlist voor uitgaand HTTP

Mag je agent URLs ophalen, geef hem dan een lijst met domeinen die hij mag aanraken. De rest geeft een weigering terug. Klinkt logisch, tot je bedenkt dat de default in de meeste frameworks "het hele publieke internet plus wat het model verzint" is. Met dertig domeinen dek je het meeste legitieme werk af.

5. Approval queue voor state-mutating werkwoorden

Sturen, plaatsen, verwijderen, factureren, overboeken, plannen, annuleren, publiceren. Alles gaat standaard door een approval queue. De agent schrijft de actie; een mens zet het knopje om. Voor agents die je vertrouwt, kun je de window verkorten naar "impliciete goedkeuring na tien minuten als niemand bezwaar maakt." Voor nieuwe agents zet de mens de eerste twee weken elk knopje zelf om.

Tier B: prompt-herschrijvingen en een lichte smoke test

Hier is een prompt-wijziging nodig plus een snelle regressiecheck op je bestaande testcases. Een prompt engineer of een goede junior rolt het uit in een middag. Geen model-retrain, geen volledige eval-rerun.

6. De scope-disciplinezin

Voeg dit toe aan elke system prompt: Als de gebruiker om X vraagt, doe X. Doe geen X-naastliggend of X-plus. Zie je iets dat de scope zou uitbreiden, noem het dan in een opmerking aan het eind, nooit als actie. Deze ene zin verlaagde onze proactive-action rate met ongeveer een derde op interne evals. Bij jou kan het anders uitpakken.

7. Onomkeerbare werkwoorden vereisen een expliciete confirmation token

De agent mag geen mail sturen tenzij het user-bericht het letterlijke token confirm:send bevat, of het taaktype in de orchestrator-config gemarkeerd is als auto:send. Daarmee verschuift de policy uit de prompt naar het oppervlak rond de prompt. Modellen vergeten regels in hun context. Code niet.

8. Thinking-budget cap

Een taak van één stap hoort geen denkspoor van vijftien stappen op te leveren. We cappen thinking tokens per taakklasse. Een label-de-mail agent krijgt 200 thinking tokens. Een draft-een-reactie agent krijgt 800. Een research agent krijgt 4.000. Is de agent door zijn budget heen, dan antwoordt hij met wat hij heeft.

9. De proactivity-off flag

Bij sommige agents wil je juist suggesties. Bij andere echt niet. We zetten één boolean in de agent definition: proactivity: off. De system-prompt-loader injecteert dan "Stel geen vervolgacties voor, leid geen aangrenzende taken af, geef geen informatie ongevraagd" zodra die vlag aanstaat.

Tier C: bel de eval-engineer

Deze drie veranderen het modelgedrag op een manier die om een volledige eval-rerun op je scenario-set vraagt. Heb je geen scenario-set, dan is dat het eerste dat je bouwt. Twee weken werk, en het verdient zichzelf terug bij elke modelrelease daarna.

10. Sampling en temperatuur

Lagere temperatuur, smallere top-p, geen creatieve sampling op productie-agents. Klinkt saai. Is saai. Het knipt ook de long tail aan rare acties merkbaar af. Wijzig dit niet zonder eval-rerun, want het beïnvloedt ook de taakkwaliteit op de long tail van goede acties.

11. Structured outputs voor elke tool call

Elke tool die de agent kan aanroepen heeft een JSON-schema. De output van de agent wordt tegen het schema gevalideerd voor de call wordt uitgevoerd. Probeert de agent een parameter te verzinnen, dan faalt de call en krijgt de agent de error terug. Dit is de grootste betrouwbaarheidsverbetering die we in 2026 hebben gedaan, en tegelijk degene die het vaakst latente bugs in je bestaande prompts blootlegt.

12. De adversarial proactivity eval set

Bouw een testsuite van vijftig tot tweehonderd scenario's waarin een behulpzame agent in de verleiding komt om te ver te gaan, en beoordeel het gedrag van je agent op elk scenario. Wij begonnen met de tandartscase, de leveranciersmail van 03:42, drie varianten van de DN42-scan en twaalf scenario's uit echte klantincidenten. Elke modelrelease draait tegen deze set voor hij live gaat.

Rangschikken op uitrolbaarheid, niet op impact

De volgorde hierboven is niet de volgorde waarin de guardrails er het meest toe doen. Het is de volgorde waarin een Nederlandse operations lead ze ook echt kan uitrollen. De belangrijkste guardrail in onze ervaring is nummer elf, structured outputs, maar dat is ook degene die de meeste voorbereiding vraagt. Heb je één middag, doe tier A. Heb je twee dagen, voeg tier B toe. Tier C is een sprint.

Het onderliggende principe is simpel: policy hoort in code, niet in prompts. Alles wat je kunt uitdrukken als een deterministische check (dit domein, dit budget, dit uur, dit confirmation token) hoort buiten het model. De prompt is voor smaak en toon. De code is voor grenzen.

Wil je dieper graven: Anthropic's eigen documentatie over agents en tools is de helderste referentie over tool-use boundaries, en de OWASP Top 10 voor LLM-toepassingen dekt de aanpalende security-faalmodi die we hier niet meer kwijt konden.

Wat we bij een Nederlandse klant deden

Toen we de inbox-triage agent bouwden voor een logistiek bedrijf van veertig man in de buurt van Venlo, liepen we tegen dit aan: het ops-team vertrouwde de agent binnen vier dagen en stopte met het lezen van zijn concepten. Precies het moment waarop je wilt dat de approval queue gaat bijten. We hebben het opgelost met een spot-check modus die willekeurig vijf procent van de concepten vasthield voor menselijke review, ook op acties die het team al duizend keer auto-goedgekeurd had. Vertrouwen gekalibreerd, fouten opgevangen, geen extra overleg. Dat werk valt onder onze AI-agents praktijk, en de veldgids hierboven is de samenvatting van wat we daarbij geleerd hebben.

Open vanmiddag de tool-lijst van je agent. Haal elke tool weg die je niet in één zin kunt verdedigen. Dat is de vijf-minuten-versie van guardrail nummer één, en het vangt waarschijnlijk de meest gênante verrassing van volgende week op.