Retrying without escalating consumes resources and delays human intervention

What it is

On a tool failure or a wrong object, agents often try again themselves: another phrasing, another call a few seconds later, a nearby object. While they try, the person is left under a surface of success, and intervention is pushed past quota or timeout. Retry without escalation delays the human: retry is an internal policy; escalation is pulling the person back. Do only the first, and the second’s clock never starts.

Three internal retries look like robustness. To a person they are three times the silence, plus a later, longer history.

Why it happens

Transient faults deserve a bounded retry; permission denials, missing objects, business-rule conflicts will not become right by retrying. When an agent cannot tell the two apart, the default is retry. If the product paints “still running” as health, people will not come in during the retry window. Resource is eaten by useless calls, the external system may be rate-limited, and what the person receives is a scene already harmed a second time. Delay also lengthens the history that must be reconstructed — late and long stack.

Retry count invisible to the user is a unilateral extension of the failure-handling deadline.

Studying it

On a non-transient failure (permission deny), compare: escalate immediately, bounded retry then escalate, retry until timeout. Dependent variables: time from first failure to a person seeing it, count of useless calls, whether the outside took side effects, whether the scene is worse when the person arrives. Independent variables: whether retries are visible, whether transient and persistent are distinguished, the cap.

The primary endpoint is time-to-person-seeing, not eventual success rate. A success rate lifted by infinite retry is paid for in the scene.

Where it stops holding

Known-transient network jitter reasonably takes bounded backoff, but the count and “retrying now” must be visible, and timeout still escalates. Approximating is handing a fake artefact; this is handing delay. Cleanup for a partial does not vanish because of retries; each retry may change the world once more, and the cleanup list has to grow with it.

Applying it

• Split failures into transient and persistent. Persistent (permission, missing, rule) escalates on the first, no retry. Transient has a cap; inside the cap the process view says “retrying n / N,” and at N it escalates.
• A retry must not produce a further irreversible side effect outward; calls that cannot guarantee that escalate on first failure.
• Check: on a permission deny, count time from failure to a person seeing it. If several useless calls sit in the middle, the policy is still silent retry. Change persistent failure to first-time escalate; time-to-seeing should fall near the first failure, and outward side-effect count should drop.

Related

• Same group: L4.13.1 When an agent cannot finish, it should escalate rather than cover with an approximation · L4.13.2 Escalation must say which step is stuck and what is needed; a failure report alone cannot be handled · L4.13.4 A partially completed task must say how far it got and whether cleanup is needed · L4.13.5 The later the escalation, the longer the execution history a person must reconstruct
• Nearby: L4.12 Task Progress and Intermediate-state Visibility · L4.06 Permission Boundaries of Agents · L1.06 Graceful Degradation of AI Failure
• Search terms: retry storm · escalation delay · transient vs persistent