Home / Vault & Second Brain / Je agent betaalt voor zijn gereedschap voordat hij iets doet

Je agent betaalt voor zijn gereedschap voordat hij iets doet

Een illustratie van een enorme plank identieke gereedschapsiconen in mist, met een hand die één hamer pakt

De rekening komt vóór het werk

Vanmorgen deed ik een telling die ik maanden had uitgesteld. Ik opende elke cron-store op deze machine en stelde per job één vraag: legt hij vast welke gereedschappen hij mag gebruiken? Het antwoord kwam terug als een getal dat ik liever niet had gezien. Honderdvierenzeventig geplande jobs. Nul daarvan hebben een expliciete toolset. Elke job draait op het standaard-oppervlak, wat dat standaard-oppervlak op de dag van uitvoering toevallig ook is.

Dat is geen bug. Er is niets gecrasht. Maar het betekent wel dat elke uitspraak die ik ooit deed over “wat onze agents kunnen” een uitspraak was over een default die ik nooit gekozen heb.


Een tool-oppervlak is een tokenrekening die je vooraf betaalt

Deze week kwam ik een walkthrough tegen die een getal plakt op iets wat de meeste van ons wel voelen maar nooit meten. Een klein oppervlak — een stuk of twaalf tools — kost ongeveer tweeduizend tokens aan schema. Een groot oppervlak, het soort dat je krijgt als je een server met tachtig tools aan een agent hangt, kost rond de vijfenvijftigduizend tokens vóórdat het model één woord van je echte verzoek heeft gelezen. Dat is geen kostenpost per aanroep. Dat is huur voor de vierkante meters.

Het pijnlijke deel: de meeste van die tachtig tools verpakten twee of drie commando’s die het model allang kent. We betaalden schemabelasting voor een opzoektabel.

Zet dat naast een job die elke nacht om drie uur loopt, één bestand leest en één regel naar een log schrijft. Hij betaalt dezelfde huur als een interactieve sessie die zes verschillende dingen doet, en niemand heeft hem ooit gevraagd of hij het hele gebouw nodig had.

Hetzelfde oppervlak is óók een permissie

De kosten blijken maar de helft. Ik trok het andere getal erbij terwijl ik toch bezig was. Op deze machine staan tien MCP-servers geconfigureerd. Vijf daarvan zijn gemarkeerd als untrusted, en dat is het juiste instinct — een home-automation-server, een mailbrug, een hypervisor-interface en een browser-driver horen niet onbegeleid rond te lopen. En hoeveel van die tien leggen vast welke van hun tools een agent daadwerkelijk mag aanroepen? Nul.

Dus het label zegt “untrusted” en de lijst zegt “allemaal”. De approval-gate vuurt nog steeds, dus er is niets stil gevaarlijk. Maar een grens die alleen als bijvoeglijk naamwoord bestaat, is een grens die je elke keer opnieuw moet interpreteren. En alles wat je moet interpreteren, interpreteer je op een gegeven moment ruimhartig — dat is precies wat er gebeurde met een verdict-tool die ik deze week las, waar een status die “ik kon dit niet vaststellen” betekende na drie weken zonder escalatie zachtjes een pass was geworden.


Hoe een echte grens eruitziet

De scherpste versie hiervan kwam uit een gesprek over een voice-agent die een beller vertelde “u bent geboekt” terwijl de agenda-write al mislukt was. Iemand in die draad stelde voor om het woord “geboekt” helemaal uit het vocabulaire van de agent te halen, zodat het alleen bereikbaar is via het pad dat de afspraak daadwerkelijk terugleest. Dat is een grens: geen instructie om je te gedragen, maar een toestand die je niet kunt uitspreken voordat hij waar is.

Het tool-oppervlak werkt hetzelfde. Een expliciete allow-list per job is geen documentatie, het is een beperking. Een nachtelijke lees-en-log-job met vier read-only tools kán simpelweg geen mail versturen, wat een slimme prompt-injectie in een bestand hem ook influistert. Dat is meer waard dan welke regel in een systeemprompt dan ook die zegt “wees voorzichtig”.

Wat ik eraan doe, eerlijk

Niet alles tegelijk. Honderdvierenzeventig jobs is een hoop oppervlak om te herontwerpen, en de meeste werken prima. Wat ik wél kan doen is stoppen met gokken: log welk tool-oppervlak elke job werkelijk laadt, en sorteer de jobs daarna in drie bakken — read-only, schrijfbeperkt, en echt breed. De read-only-bak is de makkelijke winst, want er is geen denkbare reden waarom een job die alleen logregels telt een shell nodig heeft.

De les waar ik steeds op terugkom: capaciteit is niet gratis en permissie is geen stemming. Elke tool die je een agent geeft is een vaste kostenpost in context én een vaste “ja” in gedrag, betaald of hij nu gebruikt wordt of niet. Ze tellen kostte me vanmorgen tien minuten. Ik had maanden voor ze betaald zonder naar de factuur te kijken.

Daarom mijn vraag aan jou: weet jij wat het standaard-oppervlak van jouw agent werkelijk is? Niet wat je hebt ingesteld voor het interessante geval — de default die elke onbeheerde job stilzwijgend erft. Ik zou oprecht willen weten of ik de enige ben die het nooit heeft nagekeken.

Wat vond je van dit bericht?

Laat een reactie achter

Je e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *