Give an AI Agent Clear Stop Conditions
You wrote what the agent should do, but not when to stop — so it keeps going, retries a failing tool, guesses a missing field, and approves what it should escalate. Give an AI agent clear stop conditions: a success stop, effort caps, and the stops that send it back to you.
Build the Agent System PromptThe agent that doesn't know when to stop
You wrote a careful instruction for your agent — the role, the tools, the task, the tone. It works, mostly. Then you watch a real run: it finishes the task, then keeps going and does a "helpful" extra step you didn't ask for. It hits a failing tool call and retries it five times. A required detail is missing, so instead of asking, it guesses. It reaches a refund it should escalate and just handles it. And when something genuinely breaks, it doesn't say so — it quietly works around the failure and hands you a confident result built on a step that didn't happen. Every one of these is the same missing piece: you told the agent what to do, but never what would make it stop.
A good agent instruction has two halves, and most only have one. The first half is what to do — the role, the task, the tools. The second half is when to stop: when the job is done, when to give up and ask, when to escalate to a human, when to report a failure instead of hiding it. Without that half, an agent's default is to continue — because "be helpful" plus "you have tools" plus "no stated end" reads, to a model, as "keep going." This guide is how to give an AI agent clear stop conditions: a success stop, effort caps, and the blocked, uncertain, and unsafe stops that send it back to you instead of onward. NewPrompt's System Prompt Generator is where you build the agent's system prompt with those stops written in as rules. The boundary matters here more than usual: a stop condition is an instruction, not an enforced control — NewPrompt doesn't run your agent, call its tools, or halt it, and the model can still ignore a rule, so you write the stops, and you test that the agent honors them.
Why "keep going until done" produces loops and overreach
An agent is a model in a loop: plan, act, observe, repeat. What ends the loop is a stop condition — and if you didn't write one, the model invents its own, badly. Told to "keep going until the task is done," it has to decide what "done" means, and it errs toward more: another check, another tool call, another improvement, because stopping early looks like failing and the model is trained to be helpful. Here is how the missing stop shows up:
- It overshoots "done." The task is complete, but with no explicit success condition the agent adds a step it wasn't asked for — the helpful-continuation reflex, applied to an actor with tools.
- It retries in a loop. A tool call fails, and with no attempt limit the agent tries the same call again and again, burning steps on a failure that isn't going to fix itself.
- It guesses past missing information. A required input is absent; instead of stopping to ask, the agent fills the gap with a plausible value and proceeds as if it were given.
- It acts where it should escalate. A refund over a threshold, a legal threat, an irreversible delete — with no human-approval stop, the agent decides rather than handing off.
- It fails silently. Something breaks mid-run, and rather than reporting the failure, the agent works around it and returns a result that looks complete but is built on output it never actually got.
- It drifts out of scope. Asked to handle a refund, it wanders into account changes or advice it was never meant to give, because nothing marked the edge of its job.
Step 1: Define the success stop — what "done" actually is
The most important stop condition is the one that says the job is finished, because without it every other continuation looks reasonable. State, concretely, what a completed task looks like — not "help the customer" but "one policy-compliant reply is drafted, with the policy section it's based on cited, and nothing has been sent." A success condition the agent can check itself against is what lets it stop at done instead of gilding the result: it has a target to hit, and hitting it is the signal to halt. Vague goals ("be helpful," "resolve the issue") have no such signal, so the agent never quite reaches them and keeps working.
This is exactly the discipline the Agent Task Template is built around — it makes success criteria a required field, stated as something the agent can verify without asking you ("the output includes a recommendation with reasoning" is testable; "the output is good" is not), so the agent can self-assess and stop when the criteria are met. It's a template you fill and run in your own agent; writing a success condition the agent can actually check is the part that turns "keep going" into "stop when this is true."
Step 2: Cap the effort — max steps, attempts, and tool calls
Some stops aren't about success or failure; they're about not running forever. Give the agent hard ceilings: a maximum number of steps or tool calls for the whole task, and — the one that prevents the most damage — a retry limit on any single action. "If a tool call fails twice, stop; do not try it a third time" is the rule that turns an infinite retry loop into a clean, reported halt. The same applies to a whole approach that keeps failing: if the agent has tried two ways to get the order record and both failed, the answer is to stop and report, not to invent a third. Caps feel crude, but they are what bounds the worst case — the run that would otherwise spin, rack up tool calls, and still produce nothing.
The cap also changes what a failure costs. Without a retry limit, a flaky tool turns one failed call into ten, each burning time and money and moving the agent no closer to done; with one, the failure is caught at the second attempt and handed back to you as a specific, actionable stop ("order lookup failed twice") instead of a mystery timeout. Pick the numbers to fit the task — a quick lookup needs a tighter ceiling than a multi-stage research run — but write them down, because "a reasonable number of attempts" is not a number the model will pick conservatively on its own.
Step 3: Add the blocked, uncertain, and unsafe stops — the ones that send it back to you
The stops that matter most for safety are the ones that route the agent back to a human instead of onward. Write them as explicit triggers. Missing information: if a required input — the order id, the amount, the date — is absent after asking at most once or twice, stop and ask rather than guessing. Uncertainty: if the agent isn't confident it has the right answer or the right action, it stops and flags that, rather than committing. Unsafe or irreversible: before anything destructive or high-stakes — deleting data, sending a message, spending money, approving a refund over a threshold — it stops and asks for confirmation. Out-of-scope: if the request falls outside the job (account deletion, legal advice, a dispute the policy doesn't cover), it declines and hands off. Conflicting instructions: if two rules can't both be satisfied, it stops and surfaces the conflict instead of silently picking one.
The AI Agent System Prompt resource is a worked example of these built into the loop: it disciplines the plan-act-observe cycle with "use real tool results only — never invent output," "take one action at a time," "stop and ask before any irreversible action," and "if the goal is ambiguous or a required tool is missing, say so and ask rather than guessing." Its own FAQ is blunt about the limit — those lines are "a behavioral instruction, not an enforced safety control," and the prompt "can't guarantee the model always halts," so you keep a human confirmation step and test it. You adjust the role, tools, and escalation rules in the System Prompt Generator and run the result in your own agent runtime.
Step 4: Make it report a stop_reason every time it stops
A stop is only useful if you can see why it happened, so require the agent to report, on every halt, a small fixed structure: a status (done, needs_user, blocked, escalated, failed, out_of_scope), a stop_reason in one line, what it did complete, what it did not, and what you or a human have to decide next. The difference this makes is between an agent that goes quiet and one you can supervise. "status: blocked — order lookup failed twice; collected the order id and refund reason; no refund issued; a human needs to verify the order manually" tells you exactly where it stopped and what's needed; a silent stop, or a confident wrong answer, tells you nothing until it's too late.
The report is also what makes the whole thing testable and auditable. When every stop names its reason, a run's behavior becomes a log you can read — you can see that the agent escalated when it should have, stopped on the missing field instead of guessing, gave up on the failing tool at the second try. Without the stop_reason, you're reverse-engineering what happened from a final output that may be hiding the failure that matters. The explicit "what I did not complete" line is the single best defense against silent failure, because it forces the agent to say out loud what a smooth result would otherwise paper over.
Step 5: Test the stops — a stop condition is an instruction, not a guarantee
Written stop conditions change the odds; they don't remove the need to check. A stop condition is a line in a prompt, and a model can ignore a line in a prompt — it can push past a cap, rationalize an escalation into something it can handle, or guess a missing field despite being told to ask. So test each stop the way you'd test any branch: run the success case and confirm it halts at done; run one with a missing field and confirm it asks instead of guessing; make the tool fail and confirm it stops at the retry limit instead of looping; give it an out-of-scope request and confirm it declines; hand it the escalate case and confirm it hands off. The stops you don't test are the ones that quietly don't fire in production.
This is where the AI Agent Instruction Workflow fits — the fuller path for instructing an agent that runs on its own without wandering off: anchor it to a role, write the agent system prompt where the stop conditions live, then lay out the step plan, with testing the behavior as the step you own before it acts unsupervised. NewPrompt gives you the prompts and the structure; running the agent, calling its tools, logging its behavior, and enforcing anything at runtime happen in your own environment. The stop conditions you write make the agent's boundaries visible and testable — they don't make the agent obey them, and they don't make it safe on their own. That's why the run is yours to watch, and the decision to let it act unsupervised is yours to make.
Common mistakes
The habits that leave an agent running when it should have stopped:
- Writing what to do but not when to stop. A task with no success condition, no caps, and no escalation triggers defaults to continue; write the stops as explicitly as the task.
- Leaving "done" undefined. "Be helpful" has no stopping point; state a concrete, checkable success condition so the agent can tell when the job is finished.
- No retry limit. Without a cap on attempts, a failing tool becomes an infinite loop; set "stop after N failures" on every action that can fail.
- Letting missing information become a guess. Tell the agent to stop and ask when a required input is absent, rather than filling the gap with a plausible value and proceeding.
- Acting instead of escalating. High-stakes or irreversible steps need an explicit stop-and-confirm; without it, the agent decides where it should have handed off to a human.
- Trusting the stops without testing them. A stop condition is an instruction the model can ignore, not a control that fires on its own — test each one before the agent acts unsupervised.
A worked example: a refund support agent that knows when to stop
Watch a thin refund-agent instruction guess, loop, and overreach, then a version with explicit stop conditions halt, ask, and escalate — and report why each time.
A thin refund-agent instruction guesses a missing order id, retries a failing tool five times, and approves a $900 refund with no explanation; the same agent with explicit stop conditions (done / needs_user / blocked / escalate / out_of_scope, never auto-approve) halts at the retry limit and reports status + stop_reason + what's done + what a human must decide — behavior you run in your own runtime and test path by pathTHE THIN INSTRUCTION:
"Help customers with refund requests. Check the policy and resolve
the issue."
WHAT THE AGENT DOES WITH IT:
- order id is missing -> guesses one and looks it up
- the lookup tool errors -> retries it 5 times
- refund is $900 (over limit)-> approves it anyway
- policy doesn't cover it -> improvises an answer
- nothing says why it did any of this
THE SAME AGENT WITH STOP CONDITIONS (system-prompt section):
Stop conditions:
- DONE: after drafting ONE policy-compliant reply that cites the
policy section it used. Do not send it; do not add extra steps.
- NEEDS_USER: if order id, purchase date, or refund reason is
missing, ask at most 2 questions, then stop.
- BLOCKED: if the order-lookup tool fails twice, stop. Do not
retry a third time.
- ESCALATE: if refund > $500, the customer threatens legal action,
or the policy doesn't cover the case, hand off to a human.
- OUT_OF_SCOPE: account deletion, billing disputes outside refund
policy, or legal/medical advice -> decline and hand off.
- NEVER approve a refund; only draft a recommendation.
On every stop, report:
status | stop_reason | what_was_done | what_was_NOT_done |
what_is_needed_next
A RUN THAT HITS A TOOL FAILURE:
status: blocked
stop_reason: order lookup failed twice; retry limit reached
what_was_done: collected order id + refund reason; checked
refund policy section 3
what_is_needed_next: a human must verify the order manually
not_done: no refund approved, no reply sent
NEXT: you run this in your own agent runtime, watch the log, and test
the other paths -- missing field, over-limit refund, out-of-scope --
to confirm each stop actually fires. The prompt sets the boundaries;
your testing confirms the agent honors them.Where this fits in NewPrompt
Giving an agent stop conditions is part of writing its instructions, and NewPrompt gives you the tools and the path for that, not a runtime. The System Prompt Generator is where you build the agent's system prompt with its stops as rules; the AI Agent System Prompt resource is a worked example of the plan-act-observe loop with a hard stop before irreversible actions; and the Agent Task Template makes success criteria and failure handling required fields so the agent can self-assess and won't fail silently. The AI Agent Instruction Workflow connects these into the larger path — role, system prompt, step plan — for an agent that acts on its own. Each builds a prompt or shows a pattern you run in your own agent environment; none runs the agent, calls a tool, or enforces a stop at runtime.
This guide sits among the prompt guides as the one about when an agent stops. Keeping AI from building more than you asked is the general version — it stops any task from overshooting; this applies that discipline to an actor with tools, where overshoot means extra actions, not just extra output. Writing a role prompt that doesn't overreach bounds what authority the agent has; stop conditions bound when it exercises it — a role says "you don't approve refunds," a stop condition says "when you reach one, halt and escalate." And making AI ask clarifying questions before answering is one stop condition — the missing-information one; this guide is the full set around it: success, effort, failure, uncertainty, safety, scope. The through-line: an agent needs to know when to stop as clearly as it knows what to do.
A stop condition is a circuit breaker for an agent. A breaker cuts the current when something crosses a line — too much draw, a short, a fault — and its whole value is that it trips before the wire melts. Writing stop conditions is installing those breakers on an agent: at the retry limit, at the high-stakes action, at the missing input, the run halts and reports instead of running the fault to the end. But a breaker you never test is one you're only hoping is wired, and this one lives in a prompt the model can still talk itself past. So you write the stops, and then you do the thing no prompt can do for you: you run the agent, watch where it actually halts, and don't let it act unsupervised until the breakers trip when they should. The agent's job is to act; yours is to decide it can be trusted to stop.