Betrouwbaarheid van agents is een guardrails-probleem, geen modelprobleem
Ik heb twee jaar lang een autonoom multi-agent-systeem onbeheerd gedraaid over ruim 40 van mijn eigen projecten — agents die code schrijven, sites deployen, DNS aanpassen, geld-gerelateerde config wijzigen, en zonder mijn toezicht hun eigen volgende taak kiezen. Lang genoeg om het ene ding te leren dat elke demo verbergt: in productie falen agents bijna nooit omdat het model dom was. Ze falen op de operationele laag rondom het model.
Een slimmer model erin schuiven lost een categorie fouten op die ik zelden tegenkom. Het doet niets voor de fouten die echt pijn doen.
Wat er echt kapotgaat
De echte storingen herhalen zich, en geen enkele is een redeneerfout:
- Onbegrensde scope. Een agent die "fix de build" krijgt, besluit dat de schoonste oplossing is om een directory te verwijderen, of grijpt naar een tool die hij nooit had mogen aanraken.
- Op hol geslagen kosten. Een retry-loop die er in de tests prima uitzag, brandt om 3 uur 's nachts stilletjes door een budget heen omdat niets hem begrensde.
- Destructieve acties.
rm -rf, een force-push naar main, eenDROP— één token verwijderd van een prima commando, en het model heeft geen ingebouwd besef dat dit er anders aan toe is. - Gelekte secrets. Een key belandt in een log, een commit of een uitgaande call, omdat niemand keek naar de bytes die vertrokken.
- Geen noodstop. Wanneer de agent ontspoort, staat er niets tussen zijn beslissing en de echte wereld.
Elk van die gevallen heeft dezelfde vorm: de agent besloot iets te doen wat hij nooit toegestaan had mogen krijgen, en er was geen laag om het te weigeren. Een beter model neemt nog steeds beslissingen. De vraag is wat er gebeurt tussen de beslissing en de actie.
Waarom een slimmer model je niet redt
Capaciteit en veiligheid zijn verschillende assen. Een capabeler model is, als er al iets, juist gevaarlijker wanneer het onbegrensd is — het is eerder bereid om een grote, zelfverzekerde, onomkeerbare actie te ondernemen. Betrouwbaarheid is niet "het model heeft vaker gelijk". Het is "wanneer het model fout zit, gebeurt er niets catastrofaals". Die twee koop je apart, en de tweede bouw je zelf.
Je maakt een agent niet betrouwbaar door hem meer te vertrouwen. Je maakt hem betrouwbaar door hem minder te hoeven vertrouwen.
De drie eigenschappen van agents die echt leveren
In elk van mijn systemen dat onbeheerd heeft gedraaid zonder incident, duiken dezelfde drie eigenschappen op — en ze zijn architectonisch, niet prompt-niveau:
- Begrensde scope. De agent heeft een expliciete allowlist van wat hij mag doen. Al het andere wordt standaard geweigerd, niet op hoop. Deze ene eigenschap voorkomt meer incidenten dan welke andere ook.
- Guardrails als code. Invarianten die bij elke actie draaien — destructieve commando's weigeren, secrets blokkeren, kosten en aantal calls begrenzen, outputs valideren tegen een schema. Geen instructies in een prompt waar het model zich uit kan praten; checks in het uitvoeringspad die het niet kan omzeilen.
- Een harde stop bij overtreding. Wanneer een guardrail afgaat, wordt de actie gestopt voordat hij draait — niet gelogd nadat de schade is aangericht. De faalmodus is "er is niets gebeurd", niet "we draaien het terug".
Merk op dat hier niets AI aan is. Het is de saaie operationele discipline die we al kennen uit databases, betalingen en infra — toegepast op een nieuw soort actor die toevallig zijn eigen beslissingen neemt. De teams die agents betrouwbaar laten leveren, gebruiken geen geheime modellen. Ze hebben het model verpakt in een laag die nee zegt.
De laag, geëxtraheerd
Ik bleef deze laag per project opnieuw bouwen totdat ik de minimaal bruikbare versie eruit trok in één klein bestand. Je beschrijft wat de agent mag doen; het blokkeert de rest, en weigert de actie nog voordat hij ooit wordt uitgevoerd.
agent-guardrails →
Verpak de acties van een agent met invarianten, kostenlimieten en een begrensde tool-scope. Een blokkerende overtreding stopt de actie voordat hij draait. ~3 KB, geen deps, geen telemetrie — gebouwd op de patronen hierboven.
@paulodevries/agent-guardrails · binnenkort open-source
Het is bewust piepklein. Het punt is niet de code — het is het idee dat de veiligheid van een agent hoort te leven in een laag die je zelf bezit en in één keer kunt doorlezen, niet verspreid door prompts waarvan je hoopt dat het model ze respecteert.
Als je met agents bouwt
Audit deze week één ding: wanneer je agent iets doet wat hij niet zou moeten doen, wat houdt hem dan tegen? Als het eerlijke antwoord "de prompt vraagt hem het niet te doen" is, dan heb je geen betrouwbaarheidslaag — dan heb je een suggestie. Het gat tussen die twee is waar productie-incidenten leven.
Ik zoek dit in het openbaar uit, één systeem tegelijk. Worstel je met hetzelfde probleem, dan vergelijk ik echt graag aantekeningen.
