The standard pitch for AI agents is autonomy: give the system a goal and let it run until the job is done. That sentence hides a procurement problem. "Until done" is a condition the model declares, and you pay for every turn it takes to declare it.
When I built the question-answering path in Team-X, an open-source, local-first desktop app for running AI-agent organizations, I took the opposite position. As of v3.2.1 the loop stops on whichever limit trips first: 8 tool turns, 8,000 tokens, or 120 seconds, with a 64-step ceiling behind them. When one trips, the run ends with a typed reason and no synthesized answer.
What the budgets are, and why there are four
The defaults live in one file. Tool turns, emitted steps, summed tokens, and wall clock each have a cap, and each has its own error reason, so a post-mortem can say which one fired.
There are two counters for turns and steps because my first version had one and it misled operators. An internal audit dated 2026-05-07 found that each reasoning iteration consumed three step entries, so an operator who asked for 8 tool turns got only two or three. The fix split the knob: one number means turns, a larger one is a safety net against a single iteration fanning out.
The lesson for operators is general. A budget is only a control if the number on the dashboard means what the person reading it thinks it means.
Why the industry advice points the same way
This is not a contrarian outlier. Anthropic's guidance on building effective agents says it is "also common to include stopping conditions (such as a maximum number of iterations) to maintain control." It also states that "The autonomous nature of agents means higher costs, and the potential for compounding errors."
The cost side is measurable. Anthropic's engineering team reports that agents typically use about 4 times more tokens than chat interactions, and multi-agent systems about 15 times more. Budget your pilots against that multiple, not against the chat bill you already know.
On reliability, METR's 2025 paper on long tasks defines a 50% time horizon, the task length a model completes half the time, and puts Claude 3.7 Sonnet at "around 50 minutes". A coin flip is a poor reason to leave a meter running.
Security guidance agrees. The OWASP entry on unbounded consumption lists "Apply rate limiting and user quotas to restrict the number of requests a single source entity can make in a given time period" among its mitigations. A step cap is the same control applied to one request. Frameworks such as Microsoft's AutoGen ship termination conditions for the same reason: a run can go on forever.
What happens at the limit is a policy decision
Most teams set a cap and never decide what the cap returns. In Team-X the answer is explicit. A tripped run ends with a status of budget exhausted, a typed reason such as budget_tokens, and no answer. The loop does not make a last model call for a best-effort summary. Every step already taken stays on a thread as a message, so the operator keeps the evidence trail.
That is a trade. You paid for the tokens and you did not get a conclusion. I prefer it to asking a model that has run out of room to improvise a summary of evidence it never finished reading. Your business may choose differently. What matters is that someone chose.
Read access is a policy too
The question-answering loop has six query tools that only read: employees, tickets, projects, meetings, files, and audit events. On the default path it also receives three write-side tools, and the one that matters most, delegation, does not create work. It parks a pending row that a human must approve. The copilot path gets the read tools plus a single insights query and nothing that writes. Those boundaries are enforced by which tools are in the registry, not by a sentence in a prompt.
Where my own limits leak
I would rather name these than have an operator find them. The checks run at the top of each pass, so a model call that crosses the token cap still finishes and is still billed. I found no timer in the loop that interrupts a call already in flight. And at v3.2.1 the Settings screen saves budget values that the running loop does not read, so the defaults above are the effective numbers. Treat any vendor's stated limits the same way: ask where they are checked, not only what they are.
Four questions to ask before you deploy an agent
- What is the maximum bill of one run? If nobody can state it, there is no budget.
- Which unit does the limit count? Make the binding cap the one your operators understand, such as tool turns, and keep the raw count as a backstop.
- What does a tripped run return? A typed reason, a partial trail, or a best-effort answer. Write it down before launch.
- What can the agent change? Separate read and write tools in the registry, and put irreversible actions behind an approval step.
The full engineering write-up, with the code references, is in the Team-X post on agent loop budgets. The cost of an agent is not what it does when it works. It is what it does when nobody tells it to stop.
-Rocky
#TeamX #AIAgents #AgentGovernance #EngineeringDreams #StrategiaX
Originally published on Team-X Blog.