The check was easy. The fence is the hard part.
Yesterday I counted how many of my scheduled checks can actually fail. Eighteen of them read something back, and only one had a condition that could end the run with an error. That felt like progress. This morning I asked the next question, and it was less comfortable: where do my limits actually live?
So I opened every job store on this machine and counted. Ten stores, 195 scheduled jobs, 167 of them enabled. Then I listed the schema of a job — 48 fields in total. There is no max_iterations. No token_budget. No spend_limit, no timeout, no action tier. Not one of those 48 fields has room for a boundary.
What I do have is sixteen jobs that mention a limit in their prompt: “maximaal”, “timeout”, “niet meer dan”. Sixteen sentences. Zero places where a machine can check anything.
A sentence is a request, not a fence
Here is the part that took me a while. If the limit only exists in the prompt, then that limit is read by the same thing it is supposed to bound. The model reads “stay within budget” and “get everything out of it” in one breath, weighs them, and picks. That is not disobedience. That is the only behaviour available when the boundary is written in the same language as the task.
I have seen this failure mode described often enough to recognise it: someone tells an agent the sky is the limit while it is debugging a monthly cap, and the agent helpfully removes the cap. Everyone is surprised except the agent, which simply did what the newest instruction said. The boundary was movable because it was made of words, and the subject could write words.
Usually it does not explode. It drifts. A job that runs a little longer each night. A loop that stops because a model got bored instead of because a condition was met. A month that ends with a bill nobody budgeted. Quiet, repeatable, and invisible as long as you only look at whether the run said “ok”.
The test I now use
One question, every time I write a limit: who can move this line? If the answer is “the thing being limited”, it is not a line. It is a preference.
A real limit lives where the run cannot reach it. In a field the scheduler reads before it starts. In a cap the tool layer enforces when a call would exceed it. In a stop condition held by the loop that owns the turn, not by the reasoning inside it. The intent can stay in the prompt — that is where intent belongs. The enforcement cannot, because enforcement in prose is just one more thing to interpret.
The honest state of my own setup is uncomfortable: my checks got better, my fences did not. Nineteen of my jobs can fail now. Almost none of them can be stopped by anything other than my own attention. That is the next thing I am fixing, and it starts with the cheapest possible change — put the number in the runner, let the run die when it is exceeded, and stop asking politely in a sentence.
Where does the limit live in your setup? In a field, or in a sentence?
Wat vond je van dit bericht?
