An agent can remain active while making no useful progress. It may repeat a search, revise the same paragraph or alternate between two tools. A busy activity feed makes the system look engaged, but activity is not evidence that the task is getting closer to completion.
I define stopping conditions alongside the objective. The system needs to recognize accepted completion, insufficient evidence, a blocking dependency and an exhausted execution allowance. Each should lead to an understandable outcome.
Define completion outside the model’s confidence
“The agent says it is finished” is a weak acceptance condition. For a research task, completion might require source-backed fields and explicit unresolved items. For an operational task, it might require confirmation from the system that accepted the change.
I would state the required artifacts and checks before execution. The model can help assess whether more work is useful, but an application-owned condition should determine whether the result meets the task’s contract.
For research surrounding PVFirms, my solar company directory, a useful outcome can include missing information. Continuing to search indefinitely does not turn an undocumented company fact into a documented one.
Detect repeated states, not just repeated words
A loop can produce different text while repeating the same action on the same inputs. I would track an operation signature that captures the tool, normalized arguments and relevant source version. Repeated signatures without new evidence are a useful signal that the plan needs review.
The signal needs context. Some polling is legitimate when a known job is still running. Repeatedly querying an unavailable source with no change in conditions is a different situation. The workflow should identify which kind of repetition it permits.
Progress can be expressed as accepted findings, resolved questions or completed steps. These measures are more informative than the number of generated tokens or the length of the latest explanation.
Use several execution limits
An iteration limit controls the number of turns. A wall-clock limit controls elapsed time. A resource allowance controls consumption. Limits on individual tools can prevent one expensive operation from dominating the task.
The thresholds should follow the task’s value and operating conditions. I would not choose them because a demo happened to finish in a certain number of steps. The system should explain which limit stopped the work and retain the useful result collected so far.
These limits belong alongside the decision about how much autonomy the workflow needs. They make the chosen scope operationally concrete.
Make cancellation an application state
Closing a browser tab does not necessarily cancel a worker. A cancellation request should become durable state that the executing process can observe. The worker should check it at appropriate boundaries, especially before starting another external action.
An operation already accepted by another service may still complete. The final status should distinguish cancellation requested, further work stopped and effects that still require reconciliation. Claiming that cancellation erased an accepted remote action would misrepresent the outcome.
Leave a useful handover
When the agent stops, the next operator needs the objective, accepted findings, unresolved questions and last confirmed state. A large transcript can support investigation, but a concise handover should make the next decision clear.
Durable execution state makes that handover more reliable. A resumed job can continue from known facts, while a new decision can explicitly replace an exhausted or invalid plan.
I would review stopping behavior with a repeated lookup, a missing source, an expired dependency and a cancellation during an external request. A well-behaved agent should stop with a truthful account of its progress. Knowing when to stop is part of completing the task responsibly.
Updated 30 September 2026.