Stopping is a design decision, not a budget
Budgets stop a runaway agent. They do not tell it when it is finished, and the difference between those two things is where most agent quality is lost. This lesson covers the four ways to define done and what to return when you never got there.
TL;DR: A step cap is a safety net, not a termination condition. Define done positively, in terms the agent can check: an explicit finish action, a satisfied goal condition, or a diminishing-returns rule. Then decide what a run that hits its budget returns, because a truncated answer presented as a complete one is the worst outcome available.
Where you are. Last lesson of the module. You have the loop, the reasoning variation, and the planning axis. This is the part all three depend on and the part most implementations leave to a for loop with a maximum.
Budgets and termination are different
A step cap answers "when must this stop no matter what". A termination condition answers "when is this finished".
If your only stopping rule is the cap, then every run either stops because the model volunteered no further tool call, which is unspecified behaviour you are relying on, or because it hit the ceiling, which is a failure. Neither is a definition of done.
The consequence is a specific and common quality problem: agents that stop slightly too early with a partial answer, or run several steps past the point where they had one. Both look like reasoning problems and are termination problems.
Four ways to define done
In rough order of how easy they are to implement.
1. An explicit finish action. Give the agent a tool it calls when it believes the task is complete, with the answer as its argument. Now stopping is a decision rather than an absence of decision, and you can inspect and validate it.
This is the cheapest large improvement available and it is underused. It also means "no tool call" becomes an anomaly rather than the normal exit, which is a useful thing to be able to alert on.
2. A checkable goal condition. Where the task has one, write it in code and check it after each step. The record exists, the file was written, all three fields are populated. Deterministic, cheap, and it removes the judgement entirely.
Not every task has one. Where it does, use it in preference to anything the model decides.
3. Diminishing returns. For open-ended work such as research, done is rarely a clean condition. Track whether recent steps added anything: if the last two produced no new facts, stop. This is imperfect and far better than a fixed cap, because it adapts to the task rather than to your guess about it.
4. Confidence, carefully. Ask the agent whether it has enough to answer. Useful as a signal and weak as a rule, for the reason from the applied AI course: stated confidence is generated text and is not well calibrated. Use it to trigger a check, not to decide.
Note where the budget sits: last. It is the backstop after three positive definitions have failed to fire, which is what a safety net should be.
Detecting no progress
The third condition needs a definition of progress, and the useful one is narrow: did this step add a fact the agent did not already have?
Track the tool calls made with their arguments, and the facts extracted. Then:
- Identical call repeated means no progress, and this is worth catching immediately rather than after N steps.
- Different call, no new information is weaker but real. Two or three in a row means the agent is circling.
- New facts arriving means continue, whatever the step count.
An agent on step fifteen still discovering things is doing better than one on step four that has repeated itself twice. A pure step cap cannot tell those apart, which is exactly why it is a poor primary rule.
What to return when you stop early
The part that decides how much trust survives, and the part most often left as an exception.
Return what was established. A run that found the account and the payment but not the policy should return those two facts. Partial information with its boundary stated is useful; a thrown error discards work that was already paid for.
Say what is missing and why. "I could not determine the regional policy because the policy lookup returned nothing" is actionable by a person. "I was unable to complete this request" is not.
Never present partial as complete. This is the rule. An agent that hits its budget at step twenty and returns its last intermediate answer with no indication that it ran out is producing a confident wrong answer, and nothing downstream can tell.
Escalate where it matters. For anything consequential, out of budget should route to a human with the transcript attached, not to a generic failure message.
Do this before moving on
Add a finish tool to an agent you have, and make "no tool call" an error rather than the exit path.
Then run five tasks and count how the runs ended: finish called, no progress, budget exhausted, or the anomaly. At least one run typically exits through the anomaly, and that is a run whose stopping behaviour you did not know you were relying on.
Go deeper
- Agent reliability covers termination alongside the other failure modes of long runs.
- Practice question: Your agent will not terminate. How do you fix it? is this lesson as an interview question, and naming the distinct causes is what a strong answer sounds like.
- Practice question: How do you keep a long-horizon agent reliable? is where these conditions have to hold over hours rather than steps.
- Practice question: How do you build human-in-the-loop checkpoints? is the escalation path above, designed properly.
- Practice question: How do you evaluate an agent's trajectory? is how you would measure whether your termination conditions are firing correctly, and it is module 7 of this course.
Key takeaways
- A step cap is a safety net. It is not a definition of done, and using it as one produces agents that stop early or run long.
- Give the agent an explicit finish action, so stopping is a decision you can inspect rather than an absence of one.
- Prefer a code-checkable goal condition where the task has one. Use no-progress detection for open-ended work.
- Return what was established, say what is missing, and never present a truncated run as a complete answer.
Check yourself before an interviewer does. Answer from memory first.
Why is 'the model stopped calling tools' a poor primary termination condition?