Analysis · DiggingBeagle record
An agent can be alive while its work is lost: the hidden state behind stalls and restarts
AG-UI, Hermes and OpenClaw reports describe different ways a session can wait indefinitely, read the wrong memory, lose an acknowledgment, or silently overwrite state. Restarting a process proves none of these records was reconciled.
- Published
- Nov 2, 2026
Overview
A process returning to a healthy state is not the same as a task reaching a durable outcome. A pending interrupt, stale browser lock, missing relay receipt or wrong memory path can leave the user with a system that appears responsive while the original work is still blocked or misrepresented. Recent reports from three agent ecosystems offer a useful way to separate these failures by state boundary rather than by product name.
The control flow can wait on something that no longer exists
An AG-UI client issue describes RUN_FINISHED with interrupt identifiers but no expiresAt. In the reporter's 0.0.58 test, subsequent work on the same thread remained pending until those IDs were explicitly resumed. A client restart is not a defined expiry policy, and a successful transport message does not settle an unresolved control-flow obligation. Reproduction.
Another AG-UI transport issue found that malformed protobuf events entered reducer state while equivalent server-sent-event input failed schema validation. The maintainer later marked this fixed on main. This is a historical transport-parity bug, not a current unpatched vulnerability claim; the tested package release containing the change is not established. Issue and maintainer resolution.
A Hermes Chromium report describes a persistent browser-profile lock after container recreation. Seven of ten agents in the reporter's environment reportedly failed to start browsers because the old process identity was interpreted as a living owner. Blindly deleting every lock is unsafe if a real process still owns the profile. Local issue.
A new process can connect to the wrong history
In Hermes cron sessions, a configured Mnemosyne memory path was not forwarded to the scheduled runner, which used a much smaller default memory bank instead. This is not evidence that another tenant's data was read; the established problem is profile identity and silent substitution. Profile-path report.
A separate Honcho recall report describes a five-second synchronous budget applied to a backend that took roughly ten to fifteen seconds. The model continued with empty retrieved context and without a useful error surfaced to the operator. 'No remembered facts' and 'the memory provider did not answer before the deadline' are different states; downstream decisions should not conflate them. Timeout evidence.
OpenClaw memory-wiki illustrates the write side. The reporter supplied one additional metadata claim and observed replacement of the existing claims collection instead of append/merge. The system needs an explicit replace-versus-append contract with an inspectable before-and-after diff. Another OpenClaw forget report warns that deletion from a core sidecar may not remove data retained by an active memory provider. A successful local deletion is not evidence of complete erasure. Replacement issue; forget scope issue.
Acknowledgment and delivery are separate facts
A Hermes Desktop relay issue reports a harmless command result settled on the local worker while the cloud coordinator kept waiting because the receipt was not delivered. Re-executing the command could duplicate an already-completed side effect; the missing artifact is the delivery acknowledgment, not necessarily the execution. Relay report.
An OpenClaw WhatsApp issue describes reconnect notices occupying a twenty-event queue, with 186 queue-full errors across the observed twelve days. Those numbers are one installation's report, not a general fleet failure rate. A heartbeat that is stopped, a reconnect event that is repeatedly retried, and a task-completion event that is discarded require different recovery logic. Queue issue.
| State boundary | Honest machine-readable result | Dangerous shortcut |
|---|---|---|
| Interrupted run | Pending, resumed, expired or explicitly invalidated | Assume no expiry means permanent approval or permanent wait |
| Browser session | Live owner confirmed, or stale owner safely reconciled | Remove every lock file on startup |
| Memory retrieval | Fresh, stale, timed out or unavailable | Return an empty set as if retrieval succeeded |
| Memory mutation | Append, replace and deletion effects with diffs | Treat all list updates as implicit replacement |
| Local execution and relay | Committed locally, acknowledged remotely, retry-safe ID | Re-run work because its receipt is missing |
| Notification queue | Durable event, coalesced noise, dropped event explicitly counted | Declare process health equal to delivery health |
These cases do not demonstrate one shared bug. They demonstrate a shared evaluation error: using process liveness and success-shaped messages as substitutes for durable, identity-bound state. A meaningful test injects each failure separately, restarts the relevant component and checks whether an immutable action receipt, current ownership and exact memory bank still agree. Without that reconciliation, another restart can make the dashboard look better while losing the reason the operator asked for recovery.