I once handed an agent thirty seed URLs and a crawler and went to make coffee. It came back with four thousand. Nothing had malfunctioned. Every page it fetched was a page I'd asked for, more or less. Every link it followed existed. By every metric I had at the time, it was working exactly as designed.
The bug was that the tool result doubled as a work order.
That's the part I want to pull on, because the spend argument gets all the attention and this one sits upstream of it. Before an agent can run up an invoice it has to have more to do than you gave it. And the way that happens, almost every time, is that we let the model append to its own frontier.
Discovery is a multiplier, not an addition
Fetch one page, get forty links. Fetch those forty, get sixteen hundred. The queue isn't growing linearly and it isn't the model's fault for noticing — you built a loop where the output of step N is the input to step N+1, then acted surprised that it didn't stop.
The model isn't being greedy. It has no representation of "how much is left." It has a list. The list has items. It does the next item. There's no step where it looks at the queue and decides the queue is too long, because nothing in its context says what long means.
A human in the same seat stops for reasons that have nothing to do with the target: they get bored, they get hungry, they have a standup in twenty minutes. Stamina is the control we never write down. The agent doesn't have it, and no amount of prose in a system prompt installs it.
The queue isn't the agent's to write
What I ended up with is embarrassingly structural. The agent doesn't own its task list. It reads from a queue the harness controls, and it can propose additions, but it can't commit them.
Admission rules, roughly:
- Items from the seed set go straight in. That's the job.
- Items discovered by a tool land in an outbox, not the frontier.
- The harness drains the outbox up to a per-step fan-out cap and a total-growth cap, then drops the rest and logs how many it dropped.
- A high drop count is a signal about your seed set, not your agent.
Not one line of that mentions money. It works just as well for a free tool that takes ten minutes a call, which is how I knew it was the right layer. Cost was a symptom. Self-amplifying work was the disease.
This makes the agent worse, and that's the trade
The uncomfortable sell here is that you are deliberately removing capability. The crawler that can follow anything is strictly more powerful than the one that can follow twelve things per page. You're paying for that in coverage.
You get it back in two places. First, runs become reproducible — same seeds, same caps, and two runs look roughly like each other instead of diverging into whatever corner of the graph the model happened to wander into. Debugging an agent that explores a different subtree every time is not a debugging exercise, it's a séance.
Second, the failures get small. When the fence is on the frontier, an over-eager agent burns twelve extra fetches, not twelve thousand. I'd rather read a log with a drop count in it than a bill.
Boredom is the safety property
The whole value proposition of putting a model in a loop is that it doesn't get tired. It'll do step nine hundred with the same enthusiasm as step nine. That's genuinely the thing you're buying.
It's also, precisely, the thing you have to fence. You can't have unbounded stamina and an unbounded task list at the same time and expect the invoice to be your alarm clock. One of them has to be small on purpose.
So decide now, before the run, who's allowed to add work to the queue. If the answer is "the agent, whenever it finds something," you've delegated your scope to a text predictor having a productive afternoon.
Top comments (0)