A lack of error is not progress. The agent loop can spend tokens and tool quota indefinitely because every tool call returns something plausible. I would define progress in terms of the task: a required question answered with evidence, a hypothesis eliminated, a new source or version that changes the decision, or a verified effect completed. “The model says it is working” and “search calls increased” are not progress signals.

The runtime needs a hard ceiling on turns, elapsed time, tool calls, and money for this run, plus narrower per-tool budgets and a deadline inherited from the user request. OpenAI's Agents SDK runner exposes a maximum-turn limit, and Anthropic's agent guidance discusses stopping conditions for loops. Those are control mechanisms, not a universal number of searches. A hard cap prevents runaway work. A progress check helps stop earlier or ask for direction before the cap burns through.

I would give the agent a concise ledger: what it is trying to establish, which distinct sources and revisions it has already examined, what is still uncertain, and the next proposed query's expected information gain. Normalize repeated queries and track result overlap. If ten searches return the same three pages and no new evidence, the coordinator can ask the model for a different approach or stop with a partial result. It should not declare “no answer exists” from the failed search loop. It can say what it checked, why that did not resolve the issue, and what input or access would help.

The rare-issue probe matters. A simplistic “three searches and stop” policy will fail legitimate multi-hop work. An agent that retrieves a new schema version on call four and a governing exception on call five has made real progress. I would make budgets conditional on observed novelty and task value, with a bounded extension policy. Novelty by itself is not enough either. Five irrelevant new pages should not earn unlimited turns. Evaluate whether the new evidence reduces the uncertainty relevant to the user's question.

When the budget expires, produce a truthful terminal state: completed, partially answered, needs clarification, needs authorization, or exhausted. Include verified findings and unresolved questions. Do not let the model hide the stop by emitting a confident answer from weak evidence. If the run was supposed to take an external action, a stop must also report any submitted or unknown effects from durable runtime state. Ending the model loop does not cancel an already submitted tool operation.

Suppose a high-priority incident arrives while the agent is stuck. The scheduler can preempt this run and reserve capacity for the incident, then resume from its evidence ledger if it still has value. This should not reset the budget or forget the twenty-eight searches. I would evaluate on both genuinely hard tasks and deliberate circular-search traps, measuring correct completion, useful partial reports, cost, and how often the stop decision cut off an answerable task.