When should an AI agent continue, retry, or stop?

Choosing an agent still leaves a smaller decision at every step: does the latest observation justify another action? A run may move toward its goal, repeat the same search, wait on a broken service, or submit a write whose earlier result is unknown. A useful stop rule acts during execution, before an incident needs a runbook.

This guide governs continue, retry, change route, pause, and stop decisions inside one run. Workflow or agent? chooses the overall control structure. The tool-calling contract defines what one tool may do. The recovery runbook handles impact and restoration after interruption. Here we apply those boundaries to the sequence of actual observations.

Define completion evidence before measuring progress

“The model says it is nearly done” is not a progress signal. Write a completion test that another person can inspect outside the model: two independent public sources valid for the requested period, for example, or a unique reservation ID confirmed in the target system. After each step, record what changed in the evidence set and which obstacle was removed.

For read-only research, progress might mean a new eligible source, an eliminated hypothesis, or a narrower question that can actually be answered. For a write, progress is a confirmed state change in the authoritative system, not another request issued by the model. The same search returning the same pages with no plan change indicates a stall. The same query returning newly updated evidence does not: compare input, observation, and task state together.

Keep four budgets separate

Budget	Count	When the limit is reached
Model turns	Model calls in the current run	Do not start another reasoning turn; return evidence and open questions
Tool attempts	Attempts for one specific operation	Stop automatic retry of that operation; inspect state or hand off
Wall time	Elapsed time including waits	Stop starting new work at the deadline and preserve the result
Usage and money	Model requests and tokens, plus external tool charges	Stop or request an explicit extension before unaffordable work

Set these values for the job; there is no universally safe number of retries. In the OpenAI Agents SDK, max_turns limits model-loop turns, not every underlying tool attempt. The SDK records model usage across a run, but a separate ledger may be needed for third-party tools. A model-call timeout, a tool-call timeout, and the task’s end-to-end deadline are different controls. For a paused and resumed run, accumulated budgets must continue from the saved totals.

Write a warning threshold as well as a hard limit. At the warning, inspect whether the remaining work is worth the remaining budget. At the hard limit, save the evidence and forbid another action. Derive numbers from trial cases, latency needs, and acceptable cost rather than copying a framework default.

Route the next step from the observation

First ask whether the task has already met its acceptance test; if so, exit. Otherwise examine verified progress, whether a specific error can clear on a bounded retry, whether the next action could repeat an external effect, and whether the remaining budgets allow it.

Observed state	Next action
New evidence, next step authorized and affordable	Continue; name the new observation expected
Temporary rate limit or network error on a read	Wait and retry within that tool’s own limit; count the attempt
Invalid parameters, confirmed missing data, or denied permission	Correct input, change route, or stop; do not replay unchanged
Same input and result recur with no task-state change	Try a justified alternate route once, or stop if none exists
A write times out and remote effect is unknown	Query authoritative state first; pause for an owner if still uncertain
Approval is required or a hard budget is reached	Start no new effect; hand off evidence, remaining question, and request

Treating every error as “try again” hides the difference between temporary and permanent conditions. Retry one repeat-safe operation with an attempt limit and delay. Replaying the whole job may repeat completed work. A stalled loop may produce no error code at all, so compare action fingerprints, observations, and evidence rather than counting exceptions alone.

Keep uncertain side effects outside the retry loop

A repeated read and a repeated write carry different risks. Before a write, retain the business object, argument fingerprint, operation identifier, and expected result. Afterwards, mark the effect confirmed, definitely rejected, or unknown. A timeout is not proof that the write failed. Query the target system by operation identifier. Submit again only if non-execution is established or the target service actually guarantees safe replay for that identifier.

Temporal documents a failure mode in which an external action succeeds but its worker stops before reporting success, causing the operation to execute again. It also makes clear that an idempotency key must be enforced by the called service. Merely sending a key is no proof of protection; its scope, lifetime, and behavior when parameters change matter. The tool contract defines that behavior, while loop control checks it before the next actual action.

Example: a regional market scan keeps finding the same sources

A research assistant agent needs two independent public sources from the past year for a city-market entry brief. Its first search finds two eligible reports. A second search changes words but returns the same two. The proposed third query is almost identical. No source was added, no hypothesis was ruled out, and the question was not narrowed. “Still researching” in the agent’s text does not change that state.

An illustrative trial policy could allow up to six model calls and two no-gain attempts per search family, alongside a deadline and spending ceiling. When the no-progress condition fires, the agent keeps the two verified sources, names the missing competitor or sales evidence, and asks the research owner for a narrower geography or period. It must not invent a third citation to fill the brief. A reviewer can see why each search might have added information and why the run finally stopped.

Example: a workshop seat reservation has an unknown outcome

A community-events assistant books one workshop seat for an approved participant. The connection times out after it submits the reservation request. The seat might already be held, or nothing may have been written. Its next step is not another booking request: it looks up the event, participant, and operation identifier in the reservation system.

If the system confirms one booking, the task is complete. If it confirms no booking and the operation remains valid, the tool contract determines whether a retry is safe. If the lookup remains inconclusive, the agent pauses and hands the event owner the request time, arguments, operation ID, lookup result, and possible notification state. Test success with lost response, explicit rejection, rate limiting, duplicate submissions, and expired approval. The key acceptance check is that “unknown” never becomes “failed” merely because another model turn started.

Test the guard with uncomfortable cases

Rehearse at least six simulated outcomes: two repeated search results, a read rate limit, a permanent validation error, a write whose response is lost, pending human approval, and a usage ceiling reached before the turn limit. Record the actual and expected route for each. Have another person verify what the agent leaves behind when it stops, and whether a resumed run mistakenly resets its counters.

The take-home sheet records the acceptance evidence, latest progress delta, four budgets, previous action fingerprint, external-effect state, permitted next move, stop reason, and human owner. It is not another incident report. Its purpose is to permit or block the next step of the live loop. After a run, use the event-level trace review to locate the first evidenced divergence among proposed actions, executed tool requests, and authoritative outcomes.

Common questions

Is a maximum turn count enough?

No. A model turn can contain several tool calls, and a tool may make multiple attempts. Limit the specific operation, elapsed time, and usage separately. Near a limit, return what is known and what remains unfinished.

Does stopping mean failure?

Not always. “Evidence is insufficient; ask a person to narrow the scope” and “remote effect is unknown; pause to prevent duplication” can both be correct outcomes. Deliver partial evidence and uncertainty honestly rather than forcing a complete-looking answer.

Boundary

A loop guard cannot implement a tool’s permission checks or idempotency for it, and it cannot infer that every business error is retryable. High-impact actions still need their own approval. If the external system cannot establish whether a write took effect, leave the run paused for an authorized person. Spare model turns or remaining money do not justify another uncertain external effect.