An agent stops when its spec tells it to, not when it "feels" done. Write three explicit stop conditions — success-stop (the goal is verifiably met), budget-stop (steps, tokens, or time run out), and give-up-stop (it can't proceed and should escalate) — before the agent ever runs, not after it loops.
Quick Answer: A well-specified agent has three stop conditions, checked in this order every cycle: (1) success-stop — a verifiable goal state is met, (2) budget-stop — a hard ceiling on steps/tokens/time is hit, (3) give-up-stop — the agent detects it cannot proceed and escalates instead of guessing. Missing any one of the three is the most common root cause of runaway agent loops.
Why agents don't stop on their own
Large language models generate the next plausible token; they have no innate concept of "task complete" unless the spec defines one. Without an explicit stop condition, an agent keeps generating plausible-sounding next steps forever, because continuing is always the statistically safe move.
This isn't a model limitation you'll patch away with a better model. It's a specification gap. An agent given a goal like "research competitor pricing" but no definition of "enough research" will treat every new search result as evidence it should keep searching — there's no internal signal telling it otherwise.
Anthropic's own guidance on building effective agents notes that the biggest reliability gains come from constraining the environment an agent operates in, not from prompting it to "be careful" or "use judgment" — judgment about when to stop has to be engineered into the loop, not requested from the model. That maps directly onto why a stop condition belongs in the spec, not the system prompt's tone.
Three failure patterns show up when stop conditions are missing:
- The agent re-runs the same search with slightly reworded queries, mistaking rephrasing for progress.
- It keeps "double-checking" a result it already confirmed, burning budget on redundant verification.
- It never escalates a blocker — it just keeps trying variations of the same failed approach until something (usually a token or time limit) kills it externally.
None of these are model bugs. They're the predictable result of a goal statement with no matching "done" statement. If you haven't yet nailed down the goal itself, writing an agent goal without drift is the prerequisite step — a fuzzy goal makes every stop condition fuzzy too, since "done" is always relative to what "done" was supposed to look like.
Success-stop: define "finished" as precisely as "goal"
Success-stop is the condition where the agent's actual objective has been verifiably met, not merely attempted. It needs a check the agent (or a wrapper around it) can evaluate mechanically — not a vibe, a threshold. If you can't write the check as a yes/no test, the success-stop isn't specified yet, only implied.
The classic example: a research agent tasked with "find out if Company X uses Framework Y." A vague success-stop is "when you're confident." A real one is "when three independent, corroborating sources confirm the claim, or after five searches — whichever comes first." Notice that's actually two conditions layered together, which is the point of the next section.
What makes a success-stop verifiable
A verifiable success-stop has three properties:
- A concrete artifact or state to check, not a feeling — "three sources cite the same fact" is checkable; "sufficiently confident" is not.
- A count or threshold, so the agent (or an evaluator step) can compare against a number rather than judge quality on the fly.
- Independence from the agent's own narration. The agent claiming "I've found enough evidence" isn't the check — a structured comparison of collected sources against the threshold is.
| Vague success-stop | Verifiable success-stop |
|---|---|
| "Stop when the summary looks complete" | "Stop when every required field in the output schema is populated with a cited source" |
| "Stop once you're confident in the answer" | "Stop when 3 sources from different domains agree" |
| "Stop when the code passes" | "Stop when the test suite returns 0 failures and coverage ≥ target %" |
| "Stop when the plan is good" | "Stop when the plan has been validated against all listed constraints with no unresolved conflicts" |
The general pattern (documented well in Ulwick-style outcome-driven thinking, adapted here to agents rather than customers) is to specify the outcome, not the activity. "Search more" is an activity; "three corroborating sources" is an outcome. An agent optimizing for an activity will do that activity indefinitely; one checking against an outcome has somewhere to land.
Budget-stop: the hard ceiling that catches every other failure
Budget-stop is a resource ceiling — steps, tool calls, tokens, wall-clock time, or dollars — that halts the agent regardless of whether the goal was met. It exists precisely because success-stop and give-up-stop can both fail to trigger; budget-stop is the backstop that guarantees termination no matter what.
Think of it as the circuit breaker in the system, not the primary control. A well-tuned success-stop should fire before budget-stop almost every time; if budget-stop is routinely what ends your agent's runs, that's a signal the success or give-up conditions are broken, not that the budget is working as intended.
Setting a realistic ceiling
Budget-stop numbers should be task-shaped, not arbitrary round numbers. A five-search cap makes sense for a narrow fact-check; it's far too low for a multi-hop research task spanning several sub-questions, and far too generous for a single-lookup classification task.
- Step/tool-call ceiling: cap the number of tool invocations (e.g., 5 searches, 3 file edits, 10 API calls) tied to the complexity of the task, not a global default.
- Token ceiling: cap total tokens consumed across the run — useful as a cost control even when step count looks reasonable, since a single step can balloon in length.
- Time ceiling: cap wall-clock duration for latency-sensitive or user-facing agents, independent of how many steps that time contains.
- Cost ceiling: cap dollar spend directly when the agent calls metered tools or external APIs, as a business-level backstop above the technical ones.
A pattern worth stealing from the original example: combine a quality threshold with a budget threshold using "whichever comes first." The research agent stops at three corroborating sources or five searches — whichever hits first. That single sentence encodes both a success-stop and a budget-stop in one rule, and it's the shape most production agent specs should aim for.
Combining thresholds this way means the agent never optimizes purely for either dimension — it can't loop forever chasing a fourth source, and it can't burn its full step budget once three sources already agree.
Give-up-stop: the condition nobody specs until it's too late
Give-up-stop is the escalation trigger for when an agent detects it cannot proceed — a blocked dependency, contradictory instructions, missing access, or a tool repeatedly failing — and should stop and hand the problem to a human rather than keep guessing.
Give-up-stop is the most commonly skipped of the three because it requires anticipating failure, and specs are usually written optimistically, describing the happy path. But an agent without a give-up-stop doesn't fail gracefully — it fails by looping, retrying the same broken approach, or worse, fabricating a plausible-looking answer to satisfy the success-stop it was actually given.
Common give-up triggers worth specifying explicitly
| Trigger | Example | Escalation action |
|---|---|---|
| Tool returns an error repeatedly | Same API call fails 3x in a row | Stop, report the error and last-attempted input |
| Required access is missing | Agent needs a data source it isn't scoped to reach | Stop, request the specific permission needed |
| Instructions conflict | Two constraints in the spec can't both be satisfied | Stop, surface the exact conflict for a human to resolve |
| No progress across N steps | Repeated actions return no new information | Stop, summarize what was tried and why it stalled |
| Confidence stays below threshold at budget-stop | Only 1-2 corroborating sources found after 5 searches | Stop, report partial findings as inconclusive, not final |
Note the last row: give-up-stop and budget-stop can trigger together. Hitting the search cap without meeting the corroboration threshold isn't success — it's a give-up condition wearing a budget-stop's clothes, and the spec should say so explicitly rather than let the agent quietly present a two-source answer as if it were the three-source one it was asked for.
Scoping what an agent can reach in the first place also shrinks how often give-up-stop needs to fire for permission reasons — see least-privilege agent tool access for how narrowing access up front reduces the surface area for this failure mode.
Putting all three into one spec
A stop-condition section that only lists success criteria is an incomplete spec — it should name success-stop, budget-stop, and give-up-stop as three distinct, separately-checked conditions, evaluated in a fixed order every cycle so the agent never has to infer which one applies.
A reasonable check order per cycle:
- Check success-stop first. If the goal is verifiably met, stop and return the result — don't keep going just because budget remains.
- Check give-up-stop second. If a blocker is detected, stop and escalate — don't burn remaining budget retrying a dead end.
- Check budget-stop last, as the guaranteed backstop, if neither of the above triggered.
This is exactly the layered structure behind the five-part agent spec structure: goal, context, tools, constraints, and stop conditions each get their own section because conflating them is how a spec ends up with a vague goal masquerading as a stop condition, or a stop condition that silently depends on a tool constraint nobody wrote down. If you haven't mapped the whole agent landscape yet, the complete guide to agentic workflows covers where stop conditions sit relative to the rest of an agent's design.
How Prodinja treats this
Key Takeaways
- Agents don't have an internal "done" signal — every stop condition has to be written into the spec, not inferred from model behavior.
- Success-stop must be mechanically verifiable — a count, a threshold, or a structured check, never "when it feels confident."
- Budget-stop is the backstop, not the primary control — if it's what usually ends your runs, your success or give-up conditions are under-specified.
- Combine thresholds with "whichever comes first" — three corroborating sources or five searches is one sentence encoding two stop types at once.
- Give-up-stop is the most commonly skipped condition — specify concrete triggers (repeated tool failure, missing access, conflicting instructions) and a named escalation action for each.
- Check success, then give-up, then budget, in that fixed order every cycle — the order matters as much as the conditions themselves.
- A runaway loop is almost always a missing stop condition, not a broken model — fix the spec before you reach for a different model or a lower temperature.
Frequently Asked Questions
When should an agent stop searching or gathering information?
An information-gathering agent should stop when it hits a defined evidence threshold (e.g., a number of corroborating sources) or a search-count ceiling, whichever comes first. Specify both together so the agent never optimizes purely for exhaustiveness or purely for speed.
What is an agent termination condition?
An agent termination condition is an explicit, checkable rule in the spec that tells the agent to stop running — typically one of three types: success-stop (goal met), budget-stop (resource ceiling hit), or give-up-stop (blocked, escalate to a human).
Why do AI agents get stuck in loops?
Agents loop because nothing in their spec defines "finished," so continuing always looks like the safer next move than stopping. Adding a verifiable success-stop, a budget-stop, and an explicit give-up-stop closes off the conditions under which looping can continue indefinitely.
How many stop conditions does an agent need?
At minimum three: success-stop, budget-stop, and give-up-stop. Some agents combine two into one rule (like a source-count threshold "or" a search cap), but all three failure modes — succeeding, running out of resources, and getting stuck — need a defined exit path.
Should an agent stop or ask a human when it's unsure?
If the agent detects it genuinely cannot proceed — a blocked dependency, a tool failure, conflicting instructions — it should trigger give-up-stop and escalate rather than guess or keep retrying. Guessing to satisfy a success-stop it can't actually meet is a worse outcome than an honest escalation.