Why “what to do next” isn’t enough
Most teams can write a decent “next action” prompt: search the docs, call the API, draft the email, repeat. The trouble starts when the agent treats that instruction as a treadmill. If each step only asks, “what should I do next,” the agent can keep finding plausible follow-ups—one more query, one more refinement, one more tool call—without ever proving it met the goal.
Real workflows have finish lines: a ticket resolved with evidence, a report delivered by a deadline, a compliance check escalated when uncertain. Without explicit stop conditions, you get drifting scope, inconsistent outputs, and surprise bills. “Keep going until it feels done” is not an engineering strategy when the system can act repeatedly and at scale.
The hidden costs of agents that never stop
You notice it first in the logs: the agent is “making progress,” but the work looks like orbiting. A second web search to confirm the first. Another rewrite “for clarity.” A tool call to fetch data that was already returned, just formatted differently. Each loop seems harmless, yet the costs add up quickly—token spend, tool fees, rate-limit pressure, and latency that turns a 10-second interaction into a 3-minute one. If the agent runs across many users or background jobs, that drift becomes a budget line item.
The deeper cost is operational. Runaway loops fill audit trails with noise, making it harder to explain what happened when something goes wrong. They also increase exposure: more external calls means more chances to hit restricted data, trigger a policy boundary, or create contradictory outputs that confuse users and support teams. Stopping isn’t just thrift; it’s control.
Different stop rules for different kinds of work
A support bot closing a password-reset ticket should stop on a crisp condition: the user confirmed access, the system logged the reset, and the ticket was updated. A data-enrichment agent should stop when required fields are filled and provenance is recorded, not when it “found more context.” A research agent is different: you rarely get a single success signal, so you stop on coverage rules (N independent sources, contradictions noted, and a short “what would change my mind” list) plus a hard budget on time, steps, or tool calls.
Ongoing work needs its own stop logic. Monitoring agents shouldn’t “keep improving” a dashboard; they should run on a schedule, exit after producing a diff, and escalate only when thresholds are crossed or inputs look suspicious. The more open-ended the task, the more you must pay for governance: explicit acceptance checks, bounded exploration, and a defined handoff when uncertainty stays high.
Hard stops, soft stops, and human handoffs
You can usually separate “stop” into three mechanisms that work together. A hard stop is non-negotiable: max steps, max wall-clock time, max tool calls, max spend, or “no further external calls after PII is detected.” Hard stops prevent runaway loops, but they also create partial results, so you should define what the agent must return when it hits the limit (best-so-far answer, evidence gathered, and what it would do next if allowed).
A soft stop is a quality gate the agent can satisfy early: success criteria met, required fields completed, confidence above a threshold, or “no new information found in the last two retrievals.” Soft stops reduce cost and latency, but they’re fragile if you can’t measure progress, so make the checks concrete and machine-verifiable whenever possible.
Human handoffs are the safety valve for ambiguity. Trigger them on repeated uncertainty, conflicting sources, policy-sensitive categories, or user-visible risk (money movement, access changes, legal or medical claims). The handoffs add queue time and require clear packets—what was tried, what’s missing, and the decision needed.
How to tell “done” when outputs are fuzzy
AI agents can keep refining a response indefinitely when success depends on vague judgments such as whether a summary is good, a plan is reasonable, or the risks have been adequately covered. Clear acceptance criteria make completion easier to judge. For a draft, specify the audience, objective, requirements, and recommendation, along with a word limit and a checklist covering assumptions, dependencies, and unresolved questions. For analysis, require a concrete decision statement, a minimum number of supporting facts, a comparison of alternatives, and a confidence assessment that distinguishes verified information from inference.
When there is no single correct answer, track what each iteration contributes. Progress might mean finding a new source, resolving a contradiction, narrowing the options, or filling a missing field. If another round produces no meaningful change to the tracked outputs, stop rather than generating more variations for their own sake. Defining and measuring these changes requires additional engineering work, and some unusual cases may warrant another review even when the usual criteria are met. Still, explicit stopping rules prevent endless refinement that produces more text without improving the actual result.
Engineering stop rules into the agent loop
You can’t “prompt” a stop rule into existence; you have to wire it into the loop. Treat each iteration like a transaction with a state object: goal, constraints, evidence gathered, and what changed since the last step. Before any tool call, run a preflight check: is a required field still missing, is there a contradiction to resolve, and is the next action the cheapest way to reduce uncertainty? After the action, run a postflight check that updates artifacts (filled fields, citations, diffs) and evaluates soft stops like “all required fields complete” or “no new information added twice in a row.”
Budgets need to be first-class, not implied. Track step count, wall-clock time, and tool spend, and make the agent choose: “use one more tool call” versus “handoff with a summary.” In practice, you’ll also need a deterministic finalizer: when a hard stop hits, force a structured return (best answer, evidence, gaps, recommended next step) so users don’t get an unfinished thought mid-loop.
A practical checklist before you ship
Before you ship, write down the stop contract the same way you write an API contract: what “success” means, what artifacts must exist (fields filled, evidence logged, ticket updated), and what the agent must return when it cannot finish. Set hard budgets for steps, wall-clock time, and tool calls/spend, and make the fallback deterministic: best-so-far output plus gaps and a recommended handoff.
Then pressure-test the loop with boring failures: empty retrievals, conflicting sources, rate limits, partial tool outages, and users who keep changing requirements. Verify that soft stops actually trigger, that “no marginal value” is detectable, and that sensitive categories reliably escalate. Budget time for instrumentation and red-team runs; stop rules you can’t observe will drift in production.
