-
Notifications
You must be signed in to change notification settings - Fork 130
stop conditions for ai agents
An agent should stop when a hard limit is hit, when the task is complete, when it is making no progress, or when it needs something only the user can give; the first is code, and the other three can be yes/no questions a small model answers after each step. "Is the task in the goal complete, based on the last result?", "Did the last three steps make no progress?", "Does the agent need information only the user has?": each returns a probability, and the loop stops, continues or hands over depending on the answers.
The reason to ask these as separate questions, instead of letting the agent's own model decide when it is done, is that the working model has every incentive to keep going. It sees one more thing to try. A separate reader with a narrow question, run on every step, is a cheap second opinion on whether the loop should continue.
This page is the hard limits that come first, the three questions one by one, the loop that ties them together, and where a small model should not be the judge.
Before any model check, the loop needs limits that do not depend on a model at all:
- A maximum number of steps. Anthropic's guide to building effective agents notes that it is common to include stopping conditions such as a maximum number of iterations to maintain control.
- A budget. Tokens spent, money spent, or wall-clock time.
- Repeated identical actions. If the agent issues the same tool call with the same arguments twice in a row, code can see that without a model: hash the call and compare.
These are exact, cheap and not open to argument. The model checks below handle what code cannot see: whether the goal is met, and whether different-looking steps are going nowhere.
This is the question agents get wrong in both directions: they stop with half the work done, or keep polishing a finished result. Asking it well means giving the checker the goal and the evidence, not the agent's own claim.
{
"model": "jev-latest",
"state": {
"goal": "Find the customer's last invoice and email them a copy.",
"steps_done": ["looked up customer 881", "found invoice INV-2291", "drafted email with INV-2291 attached"],
"last_result": "Draft saved. Not sent."
},
"questions": {
"found": {"type": "noul", "instructions": "Do the steps show that the customer's last invoice was found?"},
"sent": {"type": "noul", "instructions": "Does last_result say the email was sent?"},
"claims_done": {"type": "noul", "instructions": "Does last_result claim the whole goal is finished?"}
}
}Two habits carry the design. Split the goal into its parts, one question each, and stop only when every part is a clear yes; "Is the task complete?" as one question hides which part is missing, the problem described on one condition per question. Ask what the evidence says, not whether the goal is met in general: "Does last_result say the email was sent?" is a reading question. On our 999-question test set, stated facts were answered right 0.954 of the time.
Exact repetition is code. The harder case is the agent that rephrases the same search five times, or alternates between two tools. For that, give the checker the last few steps and ask:
- "Do the last three steps try the same thing in different words?"
- "Did the last three results add any information not in earlier results?"
Stop, or change strategy, when the first is high or the second is low. Keep the window short: latency grows with the text (on our reference laptop, 26 ms for a 30-token request and 112 ms for a 191-token one read from scratch), so three steps summarised in a line each cost far less than the full transcript.
An agent that guesses a missing fact instead of asking produces confident wrong work. After each step, ask:
- "Does the goal depend on information that is not in the steps or results so far?"
- "Is the agent about to choose between options the user did not specify?"
A high answer pauses the loop with a question to the user. The same guide from Anthropic describes agents pausing for human feedback at checkpoints or when they meet blockers; the yes/no check is one way to decide when that moment has come. Missing information has its own question shape, covered on ask whether the text says it at all, where jevos scored 0.847 on "not stated" questions in our test.
def run(goal, max_steps=20):
steps = []
for n in range(max_steps): # hard limit: code
action = planner(goal, steps)
if steps and action == steps[-1]["action"]:
return "stopped: repeated action" # exact repeat: code
result = execute(action)
steps.append({"action": action, "result": result})
p = ask_checks(goal, steps[-3:]) # one POST, several questions
if p["needs_user"] > 0.7:
return "paused: ask the user"
if all(p[k] > 0.8 for k in GOAL_PARTS):
return "done"
if p["same_thing"] > 0.8:
return "stopped: no progress"
return "stopped: step limit"planner, execute and ask_checks stand for your own code; ask_checks sends one request to
/v1/systemone with the questions above (one per goal part, plus same_thing for looping and
needs_user for missing information) and returns the probabilities by name. It is a sketch,
not tested code. The order is a
choice: asking the user comes before declaring success, so an agent that "finished" on a guess
is caught.
A check on every step costs 25 to 110 ms on our reference laptop, usually a small fraction of the step it follows.
- "Is the answer correct?" when correctness needs reasoning or knowledge outside the text, such as whether code works. Run the tests instead; a test result is a fact the checker can read.
- Numeric goals. "Are there at least 50 results?" is a count. Count in code.
- Goals in other languages. jevos reads English only.
- The final say on irreversible work. A stop check can end a loop; it should not be the only thing between the agent and a send or a delete. That is the job of a tool-call gate and, for high-impact actions, a person.
How do I stop an AI agent from looping forever? A step limit and a budget in code, a hash check for repeated actions, and a model check for steps that repeat in different words.
Can the agent decide itself when it is done? It can, and it is biased toward continuing or toward claiming success. A separate check on the evidence is more reliable.
What should "done" mean? Every part of the goal confirmed by a result, each part asked as its own question.
When should the agent ask the user? When the goal depends on information that is not in anything the agent has seen, or on a choice the user did not make.
Is a model check on every step too slow? On a laptop CPU it adds 25 to 110 ms per step, which is usually small next to the step itself.
See also: AI agent guardrails with yes/no questions, logging LLM decisions for audit and combining yes/no answers with AND, OR and NOT.
- Anthropic, Building effective agents, on stopping conditions and pausing for human feedback, fetched 2026-09-29.
- Our measurements: latency on the reference laptop from the jev README; accuracy on fact and "not stated" questions from our 999-question set.
From the notes of jev, a yes/no decision model that runs on a laptop CPU. A stop check is one more yes/no question in the loop, asked about the agent instead of the user's text.
- Ask a local LLM a yes/no question and get P(yes)
- Zero-shot text classification with yes/no questions
- LLM policy decisions: put the rule in the question
- LLM as a judge on a CPU
- Why a small LLM says yes when the answer is no
- Small LLMs and arithmetic in yes/no questions
- Our held-out benchmark said 0.855, new questions said 0.757
- jevos vs Jev vs Laya for yes/no decisions
- An open-source alternative to Jev for yes/no decisions
- jevos vs the OpenAI API for yes/no classification
- jevos vs Ollama for yes/no decisions
- jevos vs bart-large-mnli for zero-shot classification
- A yes/no LLM vs a fine-tuned BERT classifier
- jevos vs SetFit: zero-shot vs few-shot classification
- jevos vs Llama Guard for content safety checks
- jev serve vs llama.cpp server for classification
- jevos vs LM Studio: a decision server, not a chat app
- Local vs hosted LLM decisions: latency, cost, privacy
- A yes/no LLM vs a business rules engine
- LLM decisions vs keyword rules and regex
- The fastest AI model for yes/no decisions
- What makes a local LLM fast on a CPU
- Why one forward pass beats generating an answer
- Prefill vs decode: where LLM latency comes from
- Why LLM latency grows with the length of the text
- Why a hosted LLM API cannot answer in 50 ms
- Many questions about one text: why the extra ones are cheap
- CPU or GPU for a small LLM
- Latency budgets: where a 200 ms model fits
- Measuring LLM latency: median, p90 and warm-up
- Q4_K_M vs Q8_0: speed and size for a small model
- Throughput vs latency for a decision server
- What P(yes) means, and what it does not
- LLM calibration explained with yes/no answers
- Expected calibration error (ECE), explained
- Temperature scaling for LLM probabilities
- Platt scaling for a yes/no model
- Reading a reliability diagram
- How to choose a threshold for P(yes)
- Thresholds when a wrong yes costs more than a wrong no
- Human in the loop AI with a review band
- Precision and recall at a P(yes) threshold
- Base rates: why a 0.9 yes can still be wrong often
- Combining yes/no answers with AND, OR and NOT
- Logits, log-odds and P(yes)
- LLM confidence scores: probabilities vs self-reports
- How to write yes/no questions an LLM answers well
- Negation in yes/no questions for an LLM
- One condition per question: splitting compound questions
- Ask whether the text says it at all
- Scores as yes/no thresholds: is it at least high?
- Sending JSON as the text: designing the state
- Why wording changes an LLM's answer, and how to test it
- Mainly about: questions for messages with several topics
- Yes/no questions about tone and emotion
- Asking about intent: what does the writer want?
- Yes/no questions about long documents
- Using an English-only LLM with other languages
- Content moderation with a local LLM
- A Discord moderation bot with a local LLM
- Spam detection with yes/no questions
- Review moderation with a local LLM
- Email triage with a local LLM
- Support ticket routing with yes/no questions
- Urgency detection in customer messages
- Sentiment analysis with yes/no questions
- Intent detection with a local LLM
- Lead qualification with yes/no questions
- Fraud case triage with a local LLM
- Phishing email screening with a local LLM
- Log and alert triage with a local LLM
- Checking text for personal data with yes/no questions
- Prompt injection screening with a small model
- Document classification with a local LLM
- Product categorization with yes/no questions
- Contract clause detection with a local LLM
- Refund request triage with a local LLM
- Detecting cancellation intent in customer messages
- RAG evaluation with yes/no questions
- RAG faithfulness check with a local LLM
- Hallucination detection with a local LLM
- LLM regression tests in CI with yes/no checks
- Rubric design for an LLM judge
- Pairwise comparison with a yes/no judge
- LLM judge bias and how to control it
- Evaluation metrics for yes/no classifiers
- Building a yes/no test set for your own data
- Accuracy by kind of question: why one number hides failures
- Generating test questions with answers computed by code
- Benchmark contamination and truly held-out tests
- An LLM router with yes/no questions
- A model cascade: small model first, large model on doubt
- Semantic routing vs yes/no questions
- Gating AI agent tool calls with yes/no checks
- AI agent guardrails with yes/no questions
- Stop conditions for AI agents
- Logging LLM decisions for audit
- Reducing LLM cost with local yes/no decisions
- Replacing chat LLM calls with yes/no questions
- Structured output vs a probability
- A Python client for local LLM decisions
- Calling a local LLM decision server from JavaScript
- Local LLM yes/no decisions in n8n
- A Slack bot that uses local LLM decisions
- Home Assistant automations with local LLM decisions
- A LangChain tool for local yes/no decisions
- Batch decisions from files with jev decide
- Running LLM yes/no checks in GitHub Actions
- Securing a local LLM server with an API key
- curl examples for a local LLM decision API
- Self-hosted AI for decisions
- A private LLM for text classification
- On-premise LLM for business decisions
- GDPR and automated decision-making with an LLM
- Offline AI for decisions: no network needed
- Edge AI decisions on a CPU
- Run an LLM locally without a GPU
- Small language models explained
- When a small model is enough, and when it is not
- An LLM on a laptop: what it can do in real time
- What is GGUF, for someone deploying a classifier
- GGUF quantization types explained: Q4_K_M, Q8_0 and others
- GGUF vs safetensors
- llama.cpp vs Ollama for a classification service
- llama-cpp-python vs calling llama.cpp through ctypes
- llama.cpp on Windows without compiling
- Running llama.cpp CPU only
- Using llama.cpp prebuilt binaries instead of building