Put a Budget Around Agent Loops
An agent can create its own demand. Once the model is allowed to decide that it needs another turn, another tool call, another repair, or another search, the business needs a hard definition of how much autonomy one task is allowed to buy.
- Turn limits
- Token and currency budgets
- Tool-call budgets
- Retry policies
- Loop detection and cancellation
The situation
A single request-response feature has a relatively obvious upper bound. An agent does not. It can inspect a file, run a command, see an error, modify code, rerun validation, hit another error, and continue until something external stops it.
The naive solution
Let the agent keep working until it says the task is done because more autonomy should mean a better result.
The hidden constraint
Without a budget, a difficult or broken task can consume an open-ended amount of model and tool spend. Worse, repetitive loops may look like productive work because events keep streaming even though the agent is no longer making meaningful progress.
The decision
Every autonomous run gets a budget before it starts. That budget can include maximum turns, model spend, elapsed time, tool calls, retries, and expensive-tool use. The system, not the prompt, enforces the boundary.
The implementation
I would maintain counters at run level and check them before each new turn or tool invocation. Repair loops should have their own smaller retry budget. Repeated identical errors, repeated file edits, or oscillating actions can trigger loop detection. When a budget is nearly exhausted, the agent should be told to summarise state and ask for user intervention rather than simply terminating with no explanation.
The tradeoff
Hard limits mean some tasks stop before completion. That is still preferable to invisible runaway spend. The product can offer an explicit 'continue' action if the user decides more compute is justified.
The evidence I would look for
The metric I would monitor is cost distribution per run. A small number of extreme outliers often matters more than shaving a few percent from normal requests. Budgeting should compress that tail.
The reusable lesson
Agent autonomy without an execution budget is an uncapped liability. Give every loop a wallet, not just a prompt.
The consultant's questions
- What is the maximum one user action can spend without another approval?
- How many repair attempts are allowed for the same failure?
- What detects an agent that is repeating itself rather than progressing?
- Can a user see why a run stopped and choose whether to continue spending?