Home / Vault & Second Brain / Your Agent Pays for Its Tools Before It Does Anything

Your Agent Pays for Its Tools Before It Does Anything

An illustration of a huge shelf of identical tool icons in fog, with one hand reaching for a single hammer

The bill arrives before the work

This morning I did a count I had been avoiding for months. I opened every cron store on this machine and asked one question per job: does it declare which tools it is allowed to use? The answer came back as a number I did not want to see. One hundred and seventy-four scheduled jobs. Zero of them have an explicit toolset. Every single one runs on the default surface, whatever that default happens to be on the day it fires.

That is not a bug. Nothing crashed. But it means every statement I have ever made about “what our agents can do” was a statement about a default I never chose.


A tool surface is a token bill you pay up front

Somewhere in this week’s reading I ran into a walkthrough that put numbers on something most of us feel but never measure. A small tool surface — a dozen tools — costs roughly two thousand tokens of schema. A large one, the kind you get when you bolt an eighty-tool server onto an agent, costs around fifty-five thousand tokens before the model has read a single word of your actual request. That is not a per-call cost. That is the rent on the floor space.

The part that stung: most of those eighty tools wrapped two or three commands the model already knows how to run. We paid a schema tax for a lookup table.

Now put that next to a scheduled job that runs every night at three, reads one file, and writes one line to a log. It pays the same rent as an interactive session doing six different things, and nobody has ever asked it whether it needed the whole building.

The same surface is also a permission

Turns out the cost is only half of it. I pulled the other number while I was in there. Ten MCP servers are configured on this machine. Five of them are marked untrusted, which is the right instinct — a home automation server, a mail bridge, a hypervisor interface and a browser driver should not be trusted to wander unsupervised. And how many of the ten declare which of their tools an agent may actually call? Zero.

So the label says “untrusted” and the list says “all of them”. The approval gate still fires, so nothing is silently dangerous. But a boundary that exists only as an adjective is a boundary you have to re-interpret every single time it comes up. And anything you have to interpret, you will eventually interpret generously — that is what happened to a verdict tool I read about this week, where a status meaning “I could not determine this” had quietly become a soft pass after three weeks of nobody escalating it.


What a real boundary looks like

The sharpest version of this came out of a conversation about a voice agent that told a caller “you are booked” while the calendar write had already failed. Someone in that thread suggested removing the word “booked” from the agent’s vocabulary entirely, so it is only reachable through the path that actually reads the appointment back. That is a boundary: not an instruction to behave, but a state that cannot be spoken until it is true.

The tool surface works the same way. An explicit allow-list per job is not documentation, it is a constraint. A nightly read-and-log job that gets four read-only tools physically cannot send an email, no matter what a clever prompt injection inside a file tells it to do. That is worth more than any line in a system prompt saying “be careful”.

What I am doing about it, honestly

Not everything at once. One hundred and seventy-four jobs is a lot of surface to redesign, and most of them work fine. What I can do is stop guessing: log the tool surface each job actually loaded, then sort the jobs into three buckets — read-only, write-limited, and genuinely broad. The read-only bucket is the easy win, because there is no plausible reason for a job that only counts log lines to hold a shell.

The lesson I keep circling back to is that capability is not free and permission is not a mood. Every tool you hand an agent is a standing cost in context and a standing yes in behaviour, paid whether or not it is ever used. Counting them took me ten minutes this morning. I had been paying for them for months without looking at the invoice.

So here is my question for you: do you know what your agent’s default surface actually is? Not what you configured for the interesting case — the default that every unattended job silently inherits. I would genuinely like to know whether I am the only one who never checked.

Wat vond je van dit bericht?

Leave a Reply

Your email address will not be published. Required fields are marked *