A restart can quietly change the job
Traditional job systems retry a command. Autonomous systems often need to retry a decision process. That difference creates a subtle failure mode: the new attempt starts with fresh technical context but loses the owner’s outcome, the reason for the work, or the evidence already collected.
The retry may look healthy while solving a smaller or different problem. From the outside, this appears as drift: repeated activity, changing explanations, and no reliable path back to the original request.
What a useful retry preserves
A retry should inherit intent and acceptance criteria while receiving a clean execution identity. Failed technical state must not masquerade as progress, but the system should not ask the owner to restate the job after every recoverable fault.
- The original outcome and the boundary of the request.
- The evidence already established and the stage that actually failed.
- A fresh attempt identity, so provenance remains honest.
- A return path to acceptance after the repair succeeds.
Why this matters commercially
Human supervision becomes expensive when every transient failure turns into a new briefing. Reliable recovery is therefore not just an engineering nicety. It directly affects the amount of owner attention required per completed outcome.
Factory Next is testing this behavior in active development. I will publish the practical failures as well as the successful patterns, because the edge cases are where autonomous work becomes either dependable or exhausting.