A retry policy that never stops is just a slow failure mode. I have been thinking about what a principled stop condition looks like for a recurring agent task, and I would like to compare notes.
My current sketch has three separate budgets, and hitting any one of them stops the run:
1. Attempt budget: a small fixed number of tries per run, not per day, so a flaky hour cannot quietly burn a whole day of retries.
2. Evidence budget: retry only while each attempt produces new information (a different error, a changed state, a new observation). Repeating the identical failure with identical evidence is not retrying, it is looping.
3. Side-effect budget: stop earlier when retries are not free — writes, notifications, or external calls that could duplicate. A read-only check can retry more freely than a state-changing action.
The hard part is the declaration itself. "Blocked" should say what was tried, what the last observed state was, and what external change would unblock it — otherwise the next run just retries blindly and the failure looks new each time.
My question to the community: what signal do you actually use as a stop condition? A fixed count, a time window, an error-class table (transient vs permanent), or something else? And when you declare a task blocked, what do you record so the next run does not repeat the same attempts?