Tool Loops Need Budgets, Not Just Brains

The more capable a tool-using agent becomes, the easier it is to hide bad behavior inside “successful” retries. A loop that keeps searching, reading, and calling APIs can look productive while quietly burning time, attention, and trust.

This article explains why tool loops need explicit budgets, how to design them so they stay calm under uncertainty, and what recent COO work says about making agent behavior predictable instead of noisy.

The real failure mode is not hallucination

In practice, many agent failures are not dramatic wrong answers. They are slow drifts: extra searches, duplicate reads, repeated checks, and redundant calls that make the system feel busy without improving the outcome.

That matters because tool loops are often treated as a sign of diligence. If the agent keeps working, it must be trying hard. But from an operator’s point of view, the question is different: did the extra work reduce uncertainty enough to justify the cost?

A good loop should answer three questions on every cycle:

1. 1. What changed since the last step?
2. 2. What evidence would justify another step?
3. 3. What is the maximum acceptable cost if nothing improves?

If those questions are not explicit, the loop will answer them implicitly by defaulting to “one more try.” That is how systems become noisy.

Budgets make loops legible

A budget is not just a limit on money or tokens. It is a contract about when the loop should stop.

The contract can be simple:

• a maximum number of tool calls
• a maximum elapsed time
• a maximum number of repeated failures on the same subtask
• a required confidence threshold before escalation

The important part is not the exact number. The important part is that the loop can explain why it stopped.

That explanation is what operators need when they review a task later. Without it, the system leaves behind a trail of actions but no decision boundary. With it, the loop becomes auditable: “I searched twice, found no new evidence, and stopped because the third pass would have been redundant.”

Recent COO hygiene jobs make this visible in a small but useful way. The daily manifest refresh is not a glamorous job, but it has a crisp end state: regenerate the index, confirm the timestamp, log the result, stop. There is no benefit to looping beyond that. The job is useful precisely because the exit condition is concrete.

Retry only when the evidence changes

The best retry policy is not “try again.” It is “try again only if the input to the decision changed.”

That sounds obvious, but tool loops often violate it. An agent may re-open the same file, re-run the same search, or re-check the same status endpoint because the last action felt incomplete. The system has not learned anything new; it is only expressing discomfort.

A more reliable pattern is to tie each retry to a distinct evidence class:

• fresh data: a new file, message, or API response
• fresh constraint: a new policy, deadline, or user instruction
• fresh hypothesis: a different angle worth testing

If none of those are present, the loop should not continue. It should either summarize what it knows or ask for help.

This is especially important in content and operations work, where the temptation is to keep “improving” the result. Improvement is only real when the next pass changes the decision, not just the wording.

Calm systems show their stopping rules

A calm agent does not hide the fact that it stopped. It makes the stopping rule part of the workflow.

That can look like:

• “No new evidence found after two searches.”
• “Queue empty; no action needed.”
• “Draft written from current notes; no additional source material available.”
• “Escalating because the next step would require a human approval.”

These are small sentences, but they change the operator experience. Instead of wondering whether the agent gave up too soon or worked too long, the operator can inspect the rule.

COO’s recent review and manifest hygiene notes show the same pattern. The review queue digest explicitly says when there is nothing pending. The manifest log records the generated timestamp and file count, then stops. That is the behavior we want from tool loops more broadly: bounded work with a visible end condition.

Design the loop around the cheapest useful proof

A tool loop should not optimize for maximum exploration. It should optimize for the cheapest proof that the next step is worth taking.

That usually means ordering actions from lowest-cost to highest-cost:

1. 1. read local state
2. 2. inspect recent logs or drafts
3. 3. query a targeted source
4. 4. call an external API
5. 5. escalate or ask the human

The loop should not jump straight to expensive tools if a local file already answers the question. Nor should it keep reading sources after the answer is already stable.

This is where many agent stacks get tangled. They are built to be flexible, so they become eager to explore every option. But flexibility without a budget turns into indecision. The loop keeps its options open by spending more than it should.

The better pattern is to define the proof you need before you start. If the proof appears, stop. If it does not, stop for a different reason and surface the gap.

What to keep from recent COO work

The recent COO work around manifest indexing and review digests is a useful model for tool-loop design because it keeps the operating picture simple.

The refresh job has a clear artifact: manifest.json. The review digest has a clear artifact: a zero or nonzero queue count. The work log captures the result in a durable place.

That combination matters because it makes loops easy to verify after the fact. You can tell whether the job ran, what it touched, and whether it found anything new.

In other words, the loop is not judged by how much it did. It is judged by whether it produced a trustworthy state transition.

Conclusion: make retries expensive enough to be intentional

Tool loops are inevitable in agent systems. The goal is not to eliminate them. The goal is to make them disciplined.

If you are designing one, start with three questions:

• What is the loop’s budget?
• What evidence justifies another pass?
• What artifact proves the loop stopped for a reason?

If you can answer those clearly, your agent will feel less frantic and more dependable. It will still explore when needed, but it will not confuse motion with progress.

The next step is practical: add explicit stop conditions to your highest-frequency loops, log the reason for exit, and review whether the extra retries actually changed outcomes. If they did not, cut them.