Stopping Conditions: How an Agent Knows When It's Done

An agent loop without a stop rule is a cost and reliability hazard. The model will keep proposing next steps as long as the host asks it to.

Stopping conditions are the explicit rules that end a run: success, failure, budget exhaustion, timeout, or human cancel. They are not optional polish. They are part of the agent definition.

Summary

A stop condition is any deterministic rule (or validated model signal) that ends the agent loop and returns control to the host with a clear reason.
Insight: Most runaway agents, surprise bills, and infinite tool thrash are missing or weak stops, not mysterious model bugs.
Key Concepts: final answer, max turns / max tool calls, timeout, token or cost budget, goal check, error budget, human cancel / approval gate.
When to Use This Model: Before shipping any looped agent, when setting production budgets, or when debugging runs that never return.
Limitations/Trade-offs: Hard caps can cut off almost-done work. Soft goal checks can be gamed by the model saying "done" too early. You usually need both hard and soft stops.
Related Topics: runaway loops, single vs multi-turn modes, observability, human-in-the-loop.

Foundations

The agent loop has a natural "happy path" stop: the model emits a final answer instead of another tool call. That signal is necessary but not sufficient.

You also need host-enforced stops the model cannot override:

Maximum model turns or tool calls
Wall-clock timeout
Spend ceiling (tokens or dollars)
Too many consecutive tool errors
User or operator cancel
Policy denial (disallowed action)

Think of elevator doors: the "open" button is a request, but mechanical limits and fire overrides still exist. The model's "I am done" is a request to stop; your runtime must also enforce limits.

loop:
  reason → act? → observe → ...
  stop if:
    - final answer accepted
    - max turns hit
    - timeout hit
    - budget hit
    - error budget hit
    - human cancel / deny
    - goal verifier says success (optional)

Mechanics & Interactions

1. Final-answer stop

The model returns assistant text with no pending tool calls. Your runtime should treat that as a candidate stop.

Optionally validate: does the answer actually address the user goal, or is it empty / "I will continue later"? Weak models sometimes "finish" with a plan instead of a result.

2. Max-turn and max-tool-call caps

Count host-controlled units:

MAX_MODEL_TURNS = 8
MAX_TOOL_CALLS = 12
 
# increment after each LLM call / each successful tool dispatch
# if either exceeds, stop with reason max_turns or max_tool_calls

Pick limits from task shape, not superstition. A two-lookup support bot may need 4 turns. A research agent may need dozens, with higher cost tolerance.

3. Timeouts

Separate:

Per-tool timeout (one API call hung)
Per-run wall clock (whole agent stuck)

A tool timeout should usually become an observation error, not always a full run stop. A run timeout always stops.

4. Cost and token budgets

Agents re-send growing context. Token spend can explode even with moderate turn counts.

Budget stop example policy:

Soft warn at 70% of budget (log / degrade model tier)
Hard stop at 100% with partial answer if available

5. Goal-completion checks

Beyond "model says done," add a verifier:

Structured output matches schema
Required tools were used
Business rule: ticket closed, file written, tests green
LLM-as-judge only as a weak signal, never as sole production stop for high stakes

Goal checks prevent early exit. They do not replace max-turn hard caps.

6. Error-budget stops

If the last N tool calls all failed with the same error, stop or escalate. Blind retries are a common runaway pattern.

7. Human-in-the-loop stops and pauses

Some "stops" are pauses: wait for approval before a refund tool. The loop is suspended, not finished.

Distinguish:

Signal	Meaning
`completed`	Final answer delivered
`awaiting_human`	Paused for input/approval
`failed`	Stopped with error
`cancelled`	User/operator aborted
`budget_exhausted`	Cap hit

Product UX and metrics need these distinctions.

When you stop for budget reasons, you may still ask the model once for a partial summary of what was learned. That is a deliberate final turn under a "must finalize" system instruction, not an open-ended continue.

Advanced Considerations & Applications

Layered stop policy

Production agents usually combine stops:

Layer	Example	Overrideable by model?
Success	Final answer + schema ok	Soft
Safety	Disallowed tool blocked	No
Resource	Max turns / $ / seconds	No
Quality	Goal verifier fails → continue or escalate	Partial
Human	Cancel button	No

Multi-agent and graph systems

In graphs, each node may have local timeouts while the graph has a global deadline. Handoffs should carry the remaining budget so specialists cannot reset caps to infinity.

Long-running agents

Overnight monitors need different stops: per-cycle caps plus schedule boundaries ("end of business day"), not a single max-turns from boot.

See Single-Turn vs Multi-Turn vs Long-Running Agents.

Communicating stop reasons

Always return a machine-readable stop_reason plus user-safe message.

{"stop_reason": "max_turns", "content": "I hit my step limit before finishing. Partial findings: ..."}

Operators can alert on unexpected reason distributions (spike in max_turns means prompt/tool design is wrong).

Stop style	Strength	Weakness	Best fit
Final-answer only	Simple	Runaways if model never finishes	Demos only
Hard caps only	Safe cost bound	May cut off success late	All production agents (as floor)
Caps + goal verifier	Better completeness	More engineering	Business-critical tasks
Caps + human gates	Safe side effects	Higher latency	Money, delete, send external

Common Misconceptions

"The model will stop when the task is done." Often true for easy tasks, unreliable for hard or tool-broken ones. Host caps are mandatory.
"Max turns equal quality." Higher caps enable longer tasks; they also enable longer thrash. Pair caps with better tools and prompts.
"Timeouts are only for network calls." Run-level timeouts protect you from infinite model/tool ping-pong even when each call is fast.
"Goal checks replace max turns." Verifiers can fail open or closed incorrectly. Keep hard resource stops.
"Stopping on first tool error is always right." Some errors are recoverable. Use error budgets, not single-fault panic, unless the error is safety-critical.
"Awaiting human means the agent failed." Pause states are normal for approval workflows.

FAQs

What is a stopping condition?

A rule that ends or pauses the agent loop and yields control with a clear reason, such as final answer, max turns, timeout, or cancel.

What is the minimum stop set for production?

At least: accept final answers, max model turns or tool calls, per-run timeout, and user cancel. Add cost caps for paid model usage.

How many turns should I allow?

Start from the shortest successful golden trajectories in evals, then add a small buffer. Raise caps only when metrics show real incomplete successes.

Should max turns count user messages or model calls?

Count host-controlled model and tool steps. User messages are usually out of band for budget protection.

What if the model never emits a final answer?

Hard caps must fire, then optionally force a summarization turn with tools disabled.

How do I stop agents that keep calling the same tool?

Detect repeated identical tool calls and results, convert to an error observation, then stop after N repeats. See runaway debugging.

Can the model raise its own max-turn limit?

No. Limits must be enforced in host code outside the model's control.

What's the difference between pause and stop?

Pause waits for external input and may resume the same run. Stop finalizes the run and needs a new run to continue.

Do streaming UIs change stop logic?

Streaming changes presentation, not the need for caps. You can stop mid-stream if cancel or timeout fires.

Should goal verification use another LLM?

Sometimes as a soft check. Prefer deterministic checks (schema, tests, DB state) when stakes are high.

How do stopping conditions show up in metrics?

Track distribution of stop_reason, average turns per success, and rate of budget stops on tasks that should succeed.

What stop reason should partial answers use?

Use a dedicated reason like budget_exhausted or max_turns with partial content, not final_answer, so dashboards stay honest.

How do stops interact with plan-and-execute agents?

Cap both planning and execution phases. A perfect plan with infinite execute steps is still a runaway risk.

Is "success" only when the user is happy?

Product success is user outcome. Runtime success is meeting stop criteria with a valid result. Measure both.

Inside the Agent Loop: Perceive, Reason, Act, Observe - the loop that stops must bound
Agent Loop Basics - max_turns in a minimal loop
Why Agents Loop Forever: Debugging Runaway Agent Behavior - when stops fail or fire too late
Single-Turn vs Multi-Turn vs Long-Running Agents - different stop profiles by mode
Agent Loop Best Practices - operational stop habits
Stopping-Condition Rules Every Agent Must Implement - rule-form enforcement list

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.

Stopping Conditions: How an Agent Knows When It's Done

An agent loop without a stop rule is a cost and reliability hazard. The model will keep proposing next steps as long as the host asks it to.

Stopping conditions are the explicit rules that end a run: success, failure, budget exhaustion, timeout, or human cancel. They are not optional polish. They are part of the agent definition.

Summary

A stop condition is any deterministic rule (or validated model signal) that ends the agent loop and returns control to the host with a clear reason.
Insight: Most runaway agents, surprise bills, and infinite tool thrash are missing or weak stops, not mysterious model bugs.
Key Concepts: final answer, max turns / max tool calls, timeout, token or cost budget, goal check, error budget, human cancel / approval gate.
When to Use This Model: Before shipping any looped agent, when setting production budgets, or when debugging runs that never return.
Limitations/Trade-offs: Hard caps can cut off almost-done work. Soft goal checks can be gamed by the model saying "done" too early. You usually need both hard and soft stops.
Related Topics: runaway loops, single vs multi-turn modes, observability, human-in-the-loop.

Foundations

The agent loop has a natural "happy path" stop: the model emits a final answer instead of another tool call. That signal is necessary but not sufficient.

You also need host-enforced stops the model cannot override:

Maximum model turns or tool calls
Wall-clock timeout
Spend ceiling (tokens or dollars)
Too many consecutive tool errors
User or operator cancel
Policy denial (disallowed action)

Think of elevator doors: the "open" button is a request, but mechanical limits and fire overrides still exist. The model's "I am done" is a request to stop; your runtime must also enforce limits.

loop:
  reason → act? → observe → ...
  stop if:
    - final answer accepted
    - max turns hit
    - timeout hit
    - budget hit
    - error budget hit
    - human cancel / deny
    - goal verifier says success (optional)

Mechanics & Interactions

1. Final-answer stop

The model returns assistant text with no pending tool calls. Your runtime should treat that as a candidate stop.

Optionally validate: does the answer actually address the user goal, or is it empty / "I will continue later"? Weak models sometimes "finish" with a plan instead of a result.

2. Max-turn and max-tool-call caps

Count host-controlled units:

MAX_MODEL_TURNS = 8
MAX_TOOL_CALLS = 12
 
# increment after each LLM call / each successful tool dispatch
# if either exceeds, stop with reason max_turns or max_tool_calls

Pick limits from task shape, not superstition. A two-lookup support bot may need 4 turns. A research agent may need dozens, with higher cost tolerance.

3. Timeouts

Separate:

Per-tool timeout (one API call hung)
Per-run wall clock (whole agent stuck)

A tool timeout should usually become an observation error, not always a full run stop. A run timeout always stops.

4. Cost and token budgets

Agents re-send growing context. Token spend can explode even with moderate turn counts.

Budget stop example policy:

Soft warn at 70% of budget (log / degrade model tier)
Hard stop at 100% with partial answer if available

5. Goal-completion checks

Beyond "model says done," add a verifier:

Structured output matches schema
Required tools were used
Business rule: ticket closed, file written, tests green
LLM-as-judge only as a weak signal, never as sole production stop for high stakes

Goal checks prevent early exit. They do not replace max-turn hard caps.

6. Error-budget stops

If the last N tool calls all failed with the same error, stop or escalate. Blind retries are a common runaway pattern.

7. Human-in-the-loop stops and pauses

Some "stops" are pauses: wait for approval before a refund tool. The loop is suspended, not finished.

Distinguish:

Signal	Meaning
`completed`	Final answer delivered
`awaiting_human`	Paused for input/approval
`failed`	Stopped with error
`cancelled`	User/operator aborted
`budget_exhausted`	Cap hit

Product UX and metrics need these distinctions.

Interaction with context

Advanced Considerations & Applications

Layered stop policy

Production agents usually combine stops:

Layer	Example	Overrideable by model?
Success	Final answer + schema ok	Soft
Safety	Disallowed tool blocked	No
Resource	Max turns / $ / seconds	No
Quality	Goal verifier fails → continue or escalate	Partial
Human	Cancel button	No

Multi-agent and graph systems

In graphs, each node may have local timeouts while the graph has a global deadline. Handoffs should carry the remaining budget so specialists cannot reset caps to infinity.

Long-running agents

Overnight monitors need different stops: per-cycle caps plus schedule boundaries ("end of business day"), not a single max-turns from boot.

See Single-Turn vs Multi-Turn vs Long-Running Agents.

Communicating stop reasons

Always return a machine-readable stop_reason plus user-safe message.

{"stop_reason": "max_turns", "content": "I hit my step limit before finishing. Partial findings: ..."}

Operators can alert on unexpected reason distributions (spike in max_turns means prompt/tool design is wrong).

Stop style	Strength	Weakness	Best fit
Final-answer only	Simple	Runaways if model never finishes	Demos only
Hard caps only	Safe cost bound	May cut off success late	All production agents (as floor)
Caps + goal verifier	Better completeness	More engineering	Business-critical tasks
Caps + human gates	Safe side effects	Higher latency	Money, delete, send external

Common Misconceptions

"The model will stop when the task is done." Often true for easy tasks, unreliable for hard or tool-broken ones. Host caps are mandatory.
"Max turns equal quality." Higher caps enable longer tasks; they also enable longer thrash. Pair caps with better tools and prompts.
"Timeouts are only for network calls." Run-level timeouts protect you from infinite model/tool ping-pong even when each call is fast.
"Goal checks replace max turns." Verifiers can fail open or closed incorrectly. Keep hard resource stops.
"Stopping on first tool error is always right." Some errors are recoverable. Use error budgets, not single-fault panic, unless the error is safety-critical.
"Awaiting human means the agent failed." Pause states are normal for approval workflows.

FAQs

What is a stopping condition?

A rule that ends or pauses the agent loop and yields control with a clear reason, such as final answer, max turns, timeout, or cancel.

What is the minimum stop set for production?

At least: accept final answers, max model turns or tool calls, per-run timeout, and user cancel. Add cost caps for paid model usage.

How many turns should I allow?

Start from the shortest successful golden trajectories in evals, then add a small buffer. Raise caps only when metrics show real incomplete successes.

Should max turns count user messages or model calls?

Count host-controlled model and tool steps. User messages are usually out of band for budget protection.

What if the model never emits a final answer?

Hard caps must fire, then optionally force a summarization turn with tools disabled.

How do I stop agents that keep calling the same tool?

Detect repeated identical tool calls and results, convert to an error observation, then stop after N repeats. See runaway debugging.

Can the model raise its own max-turn limit?

No. Limits must be enforced in host code outside the model's control.

What's the difference between pause and stop?

Pause waits for external input and may resume the same run. Stop finalizes the run and needs a new run to continue.

Do streaming UIs change stop logic?

Streaming changes presentation, not the need for caps. You can stop mid-stream if cancel or timeout fires.

Should goal verification use another LLM?

Sometimes as a soft check. Prefer deterministic checks (schema, tests, DB state) when stakes are high.

How do stopping conditions show up in metrics?

Track distribution of stop_reason, average turns per success, and rate of budget stops on tasks that should succeed.

What stop reason should partial answers use?

Use a dedicated reason like budget_exhausted or max_turns with partial content, not final_answer, so dashboards stay honest.

How do stops interact with plan-and-execute agents?

Cap both planning and execution phases. A perfect plan with infinite execute steps is still a runaway risk.

Is "success" only when the user is happy?

Product success is user outcome. Runtime success is meeting stop criteria with a valid result. Measure both.

Inside the Agent Loop: Perceive, Reason, Act, Observe - the loop that stops must bound
Agent Loop Basics - max_turns in a minimal loop
Why Agents Loop Forever: Debugging Runaway Agent Behavior - when stops fail or fire too late
Single-Turn vs Multi-Turn vs Long-Running Agents - different stop profiles by mode
Agent Loop Best Practices - operational stop habits
Stopping-Condition Rules Every Agent Must Implement - rule-form enforcement list

Stack versions: Pins from the category manifest (verify at build): OpenRouter (~315+ models, July 2026 pricing/fees); LangGraph 1.0+; CrewAI 1.14+; Microsoft Agent Framework 1.0; Vercel AI SDK 6; Pydantic AI (latest); LlamaIndex (latest); OpenAI Agents SDK (latest + MCP); MCP (Linux Foundation governance); A2A (HTTP+SSE+JSON-RPC 2.0); Solana @solana/web3.js + @solana/spl-token.

Stopping Conditions: How an Agent Knows When It's Done

Buscar en la documentación

Stopping Conditions: How an Agent Knows When It's Done