Before an AI agent tries again.

A missing reply is not a missing action

Consider a fictional AI assistant issuing an approved refund. The payment service accepts the request, but the connection drops before the assistant receives confirmation. From the assistant’s perspective, the outcome is uncertain.

Sending the same request again without checking could create a second effect. Declaring success would also be unjustified. The first recovery task is to establish what the external service actually recorded.

Recover the outcome before repeating the action

A safer workflow preserves the identity of the intended action, checks the available receipt or external state, and separates confirmed completion from an unresolved attempt. Where the evidence remains insufficient, it holds the action for reconciliation or human review.

The exact safeguards depend on the connected service. Some support duplicate-request protection; others need different controls. No single retry rule can substitute for understanding the effect being produced.

Check that permission still applies

Even when another attempt is appropriate, the original conditions may have changed. An approval may have expired, a policy may have been updated, or another worker may now own the task.

Recovery therefore needs more than persistence. It needs a current answer to who is allowed to act, on which proposal, and within which limits. A restarted process should not inherit unlimited authority simply because an earlier process had permission.

Design for the awkward middle

Reliable automation has to account for the interval between requesting an action and confirming its outcome. That is where uncertainty, duplicate work, and competing workers can meet.

This is one of the problems shaping UBIKITOS: keep proposed actions, authority, and outcome evidence connected through interruptions. The refund story here is illustrative. A real pilot must verify the relevant controls against its actual systems before relying on them.

Different failures need different responses

A temporary read failure, an invalid request, and an uncertain external action should not share one automatic response. Retrying a read may be low risk, while repeating a consequential write may create another effect. Invalid input may require correction rather than delay. Missing permission may require a decision from a person. Categorising the failure preserves information the recovery step needs. Without that distinction, the system can be persistent in exactly the wrong way, spending resources or repeating actions without addressing the reason the workflow stopped.

The interface should reflect those differences in ordinary language. A user waiting for a result should be able to tell whether the system is retrying safely, checking an uncertain outcome, or waiting for a required decision. A generic spinner can conceal all three. Clear status reduces the temptation to press the same button again and helps a human intervene appropriately. The underlying runtime needs to support that clarity by preserving what was attempted and what has actually been confirmed, rather than reducing every interrupted path to a single failure flag.

Keep the earlier attempt in the history

When a new attempt is justified, it should remain distinguishable from the earlier one. Overwriting the old record can erase the uncertainty that prompted recovery and the evidence used to resolve it. A useful history connects the original request, the attempted action, the observed outcome, and the basis for continuing. That relationship makes later review possible. It also helps another process avoid interpreting the same unresolved attempt differently after a restart or a handover.

This does not require exposing technical logs to every user. The product can present a concise explanation while preserving the more exact record underneath. What matters is that the concise explanation remains truthful. “Checked the destination; no action occurred; a new attempt was authorised” describes a different sequence from “tried again.” The extra meaning is important when consequences matter. A person should not have to guess whether the system established a safe basis for continuation or simply repeated the request because it wanted a cleaner-looking ending.

Consider the worker that did not stop

A recovered workflow may have another complication: an old process can resume after a newer one has taken over. Each process may hold a locally plausible view of the task. The system needs a way to ensure that an outdated view does not continue to authorise action. This is a coordination problem, not merely an error-message problem. Restarting one worker does not prove that every earlier worker has lost the ability to affect the outcome.

Controls for this situation depend on the environment and the external service. A mechanism verified within one shared local store should not automatically be described as a guarantee across independent remote providers. The boundary needs to be tested where it will be relied on. This is why a real pilot should exercise interruption, delayed responses, and relevant handover cases in its actual setup. The goal is to establish the specific recovery behaviour the workflow needs, rather than borrow confidence from a similar-looking case that ran under different conditions.

Define the human decision point

Some uncertainty cannot be resolved automatically with the available evidence. The workflow should have a clear place to stop and explain what is known, what remains unknown, and what decision is needed. A person should receive the relevant context, not just a request to approve an unexplained retry. The proposed next action should be concrete enough to assess, and its scope should remain connected to the current task. Approval is more meaningful when the person can understand what it would authorise.

The product should also avoid turning every routine recovery into unnecessary friction. Where the evidence and existing authority support a safe continuation, the workflow can proceed within those limits. The distinction is what matters: continue because the conditions are satisfied, and pause when a consequential condition remains unresolved. UBIKITOS treats that as a design requirement to verify in bounded workflows. Reliable assistance is not measured by an unwillingness to stop or a habit of asking permission for everything. It is measured by choosing the next action from the actual state, evidence, and authority.

A recovery drill can be especially informative when it begins from an awkward intermediate state rather than a clean restart. What does the next worker know? What can it verify? Which action remains blocked? These questions expose assumptions that a normal demonstration may never touch. The resulting lesson should be attached to the actual environment tested. If the workflow later moves to another provider or operating setup, revisit the relevant boundary. A reliable recovery story grows through those checks; it should not become universal merely because the first carefully chosen scenario ended well.