Retry

What question does this solve?

An execution did not produce the expected output. Should it simply run again? Sometimes yes: a temporary condition has cleared, or feedback now shows what to fix. Often no: the rule is ambiguous, the input is wrong, the resource is unsuitable, or nobody knows whether the first attempt already had effects. Repeating without knowing which case applies only consumes resources, and can do harm.

Definition and role

A Retry is a bounded re-execution, justified by the conditions and respecting the authorization, limits and effects of the previous attempt. It is one possible response to a situation that evaluation or coordination has identified. Its companion mechanism, Escalation, routes a question to the competence or authority it requires when the condition exceeds the scope available.

A new attempt makes sense when there is reason to expect a different result within the permitted conditions. It does not, by itself, resolve a missing business decision or a constraint that stays the same. The response to a failure might also be to wait, correct information or stop. The aim is justified continuity, not persistence for its own sake.

Why it matters for the hypothesis

Reducing with AI the effort of interpreting feedback and preparing another attempt could make cycles of correction affordable for advances where they used to be too expensive. The relevant gain is reaching an accepted output with lower complete consumption, including the attempts that were discarded. Engineering of limits and of exception routing must stop persistence without progress from cancelling out the apparent saving of each attempt.

How it works

Diagnose before choosing the response

An execution that fails may have hit different problems: a transient fault, an inadequate input, an ambiguous criterion, an insufficient resource, or a missing authorization. They do not all get the same treatment.

Situation	Question to resolve
Execution interrupted by a temporary condition	Has the condition cleared, and is a new attempt safe and authorized?
Output diverges from the contract	Which correction is needed, and which criteria will be re-evaluated?
Insufficient input	Who can provide or clarify the information?
Ambiguous rule	Who has authority to define the behaviour?
Unsuitable or unavailable resource	Is there an eligible alternative, or does the commitment need reviewing?
Result of the attempt unknown	What happened, before repetition is even considered?
Limit of action reached	Who can decide on continuing or stopping?

A failure can combine situations: a technical constraint can reveal that a rule must change and also raise the cost. Routing should keep those relations rather than reduce the case to its first symptom.

Conditions for a new attempt

A Retry needs a recognizable purpose, scope and conditions: which work will be repeated, what remains valid, and why the attempt may produce a useful result. A cleared temporary condition can justify repetition; specific feedback can guide correction; a changed input can allow a new execution. Without a relevant change, or a procedure planned for that kind of failure, repeating may only consume more resources.

The Execution Policy sets the applicable limits, such as effort, expense or when intervention is required. They need not be the same at every stage. The attempt must also stay covered by the current authorization. An output not yet accepted does not grant unlimited permission to consume capacity or widen scope. When the scope is insufficient, continuing needs the appropriate decision.

Unknown results and effects already produced

Before repeating an action, a confirmed failure has to be distinguished from an absence of confirmation. An execution may have had effects even though coordination never received the result. This matters for actions that change environments, deploy changes or consume resources: repeating without knowing what happened can duplicate effects or create a different situation from the one intended. The relevant state must be checked and related to the earlier attempt; where confirmation is impossible, the uncertainty stays explicit and guides a decision proportional to the risk. The model prescribes no recovery technique, but a new attempt has to consider partial outputs, external effects and executions still running. Stopping an attempt also needs confirmation when its effect conditions what comes next.

Correction, return and a new attempt are different

Correcting an output within the same criterion can be part of continuing the stage. Revising an input may require returning to another transformation. Changing the expected result may require revising the contract and the commitment. These differences should stay visible in the Delivery State and in the history of the Delivery Unit: calling everything a retry can hide that the understanding of the demand has changed. When there is correction, the evaluation’s feedback guides the work, and the later evaluation recognizes what changed. When there is a return, the affected outputs must be identified.

The cycle as a way of producing

Attempt, observation and correction is also a way of producing. An agent can use feedback to try another approach and move forward within the commitment without a person choosing each action. The cycle is worth something when it incorporates new information and recognizes when an attempt is not progressing; repeating the same response without learning consumes resources without demonstrating progress.

Limits of persistence

People and agents can both retry, interpret feedback and route questions, and the policy should say when they may continue and when they need intervention. An automated execution can repeat actions quickly, but that does not show usefulness or authorization. A person can also persist with an inadequate solution or take a decision beyond their reach. The discipline of justifying continuity applies to any composition. Switching executor can help when the difficulty is capability or available context; it is not a substitute for a missing decision.

In the running example

At the barbershop, evaluation finds overlapping bookings. The authorized executor interprets the divergence, corrects the implementation and has it re-evaluated. That sequence can run autonomously within the contract and its consumption limits.

If the validation environment becomes unavailable, the response may be to wait and try again after checking the condition and the effects of the earlier attempt; no response does not mean no action occurred. If deployment loses confirmation, the flow first establishes the state of the environment: repeating without knowing its effects is not an attempt that is automatically allowed. If the question is which business behaviour should apply, a retry is the wrong tool, and the case goes to Escalation.

Boundaries and failure modes

Repeated failure points somewhere. Failures that recur may indicate a problem with inputs, contract, policy or evaluation, not only with execution. Those possibilities should be examined before attributing all rework to the resource.

No universal rule for when to stop. The cost of persisting has to be weighed against the likelihood of a useful output and the conditions of the commitment, and the model offers no numeric rule. Stopping an attempt, or interrupting a demand, can be right when no continuation is justifiable; it should be recorded with its scope and remaining obligations. Stopping does not undo effects already produced, and it does not turn an incomplete delivery into an accepted one.

Connected concepts

• Engine overview
• Next: Escalation, when the condition exceeds the scope available
• Evaluation, which produces the feedback a retry uses
• Orchestration, which recognizes what happened before repeating
• Glossary