Inspect the task, current run and delivery state before sending the request again. Identify whether the worker is offline, blocked, budget-limited or failing at the provider. Preserve progress, check whether an external effect already happened, then apply the smallest appropriate fix and verify one clean result.
Describe the failure before choosing the fix
Start with what is missing: no reply, no progress, an unfinished task or a failed delivery. Record the agent, task, time and last visible step. “Online” only tells part of the story; the model provider might be rejecting a key while the bridge continues to check in.
EmperorClaw’s Right now panel, task history, message delivery state and Health view offer different evidence. Look at the run outcome and named failure cause instead of inferring failure from a quiet chat alone.
Match the cause to the next action
| Observed cause | First investigation |
|---|---|
| Provider rejected the key or has no credits | Inspect authorized provider configuration |
| Budget limit | Review spend and intended allowance |
| Runtime offline | Inspect its host and bridge connection |
| Missing project access | Review the assignment and intended scope |
| Waiting for a decision | Resolve the Inbox question |
| No progress despite an active run | Inspect the last step and task evidence |
Do not solve every failure by granting more permissions or raising the budget. The task may have the wrong owner or an unavailable input.
Check whether the action already happened
Suppose a worker sends a report but loses its connection before recording success. A fresh “send it again” can duplicate the customer message. Check the external service’s delivery record or other reliable evidence first.
If the result is uncertain, mark that uncertainty on the task and ask the responsible person to investigate. A failed chat reply does not prove the underlying operation failed. Give the next owner the current evidence, not just the original request.
Use restarts deliberately
For a connected Hermes host, an authorized admin can inspect the host card and request a bridge or gateway restart. The gateway may be shared by several workers; choose the idle-wait option where appropriate and review the effect before forcing a restart.
A provider key problem usually needs a configuration fix, not repeated gateway restarts. A missing business input needs a decision. Preserve useful checkpoints and task notes before interrupting a run that is still making progress.
Retry the remaining work once
- Write a short checkpoint: completed, uncertain, still needed.
- Apply the specific fix and confirm the intended worker has access.
- Retry through the appropriate task or message recovery path.
- Watch the next run and confirm the reply stays in the correct thread.
- Inspect the final file or external result, then update the task state.
Emperor exposes abandoned work through heartbeats, leases, retries and incidents. These records help recovery; they are not a universal exactly-once guarantee for arbitrary external systems.
Make the next interruption cheaper to resolve
Ask workers to record checkpoints during long work, name missing inputs and link their outputs to tasks. Break a large assignment into reviewable results. Choose one owner for each external action and avoid unbounded retry loops.
Use incidents as attention and escalation records, with remediation represented by tasks. Emperor’s incident surface is not a complete incident-command or postmortem platform. Keep the operational process proportionate to the problem.
Practice with a harmless interruption
Run a small test that cannot contact a real customer or modify production. Interrupt its connection, inspect the visible evidence and recover the remaining work. See recovery controls and the health manual for the signals available.