Herdr survives client detachment by keeping processes alive. After a server restart it restores layout, then resumes supported sessions when a client attaches. My reading: it can host the fleet's agents, but sleep/wake policy and task routing still need an external controller.

Persistence and the fleet's sleep/wake requirement

The session-state documentation distinguishes two mechanisms. Detaching a client leaves the original processes running. After a server restart, those processes are gone: Herdr restores the terminal layout and can launch a supported agent's native resume command. Resumption happens after a client attaches and supplies terminal size and theme context. Restored conversation state does not mean arbitrary running work survived.

The integration documentation describes OMP lifecycle and session reports. Its saved conversation can be reopened with omp --resume=<session>. A custom agent can likewise report lifecycle state, a resume command and its exit.

My architectural interpretation is that this supplies part of the runtime driver, especially terminal hosting and human inspection. It does not establish the fleet's wake-on-message policy: an external controller still needs to retain task-to-session mappings, route incoming requests, decide when to stop compute and resume the intended conversation. Ordinary Herdr detachment leaves that compute running.

Whether unattended restart can meet our controller's recovery needs is an open integration question. This assessment is based on documentation, not an executed recovery test.