Notes / Workers
What should an AI Worker do when a tool goes down?
How an AI Worker can continue unaffected work, retain the context of blocked tasks, and recover under the direction of its designated owner.
By Rich Hill III. Published Sep 22, 2026. 11 min read.
Imagine a Worker coordinating incoming customer requests. It has organized the information, checked for missing details and prepared the next internal steps. Then its CRM connection stops responding. Some records may have been updated. Others are waiting. The rest of the job still matters.
The Worker should keep the job moving wherever it can do so safely, preserve the context for unfinished work, and escalate the interruption to the person responsible for it. Blocked tasks should remain recoverable until the tool returns or the designated contact gives different instructions. Actions that depend on an uncertain result must wait for that uncertainty to be resolved.
That expectation needs to be part of the job design. A useful recovery plan explains what can continue, what must wait, where the context lives, and who decides when the Worker needs direction. It also explains how the Worker will confirm that resumed work actually finished.
The CRM example throughout this article is illustrative. It shows decisions to specify with a provider or internal team, rather than a claimed result from a particular deployment.
What did the Worker actually finish?
Start by separating the job into confirmed work and unresolved work. A service becoming unavailable does not necessarily invalidate everything the Worker has already completed. It also does not tell you whether its last request reached the receiving system.
AWS's guidance on idempotent APIs describes this ambiguity: a client can receive no response even though a remote action has taken place. Repeating the request can create an additional effect unless the API's behavior makes that repetition safe.
For the CRM task, the useful distinctions are:
Frequently asked questions
Does a read-only task need the same recovery process as an update?
A read usually has less risk of duplicating a business change, but its result may still be required for a later decision. Retry according to the tool’s rules, identify stale information, and keep dependent actions waiting if current data is unavailable. Assess the actual operation rather than assuming every action labeled a read is harmless.
Can saved context guarantee that a resumed task will not create duplicates?
Saved context helps the Worker remember its intended action and progress. Duplicate prevention also depends on execution controls and the receiving tool. A durable task can still contain an unconfirmed external update; preserving that uncertainty is part of recovery, not evidence that the update failed.
What if the tool comes back after the owner has paused the job?
Keep the owner’s hold in force. Tool availability does not cancel a business instruction. Preserve the task and relevant context, record that the connection has recovered, and resume only when the current instructions permit it. A cancellation should leave a clear record of the decision and any unresolved effects.
What if the Worker cannot reach its designated owner?
Use the backup contact and escalation timing established for the job. Keep unresolved tasks visible and their context available. Continue only work already permitted and independent of the blocker. The absence of a response should not become permission to repeat an uncertain change or expand the Worker’s access.
Explore Workers