bhanu.fyi
/blogNovember 10, 2026

what survives a restart


part of the agent runtime lab.

a process can stop while the conversation it recorded remains in the database.

in my local runtime experiment, a Node process runs the agent loop and PostgreSQL keeps the session events. the process can hold the work while it is running. the database holds the record after the process is gone.

i tested the distinction with a small API demonstration. create a session, store a codeword, and wait for the turn to complete. stop the HTTP process. start a replacement with the same namespace and configuration. discover the saved session, then submit another turn that recalls the codeword.

the replacement process can construct the next request from the events already stored.

The original API process stops while the PostgreSQL event record remains available to its replacement.

the provider in this demonstration is a deterministic offline fixture. the API restart and database reads are real; the reply is not a hosted model invocation. this keeps the test focused on the state that crosses the process boundary.

the session has an identity outside the process. its events have a sequence. the new process can read those events, reconstruct the session view, and build a fresh request. it does not need the old process's objects to still exist.

there is an important boundary at unfinished work.

the execution worker currently lives inside the HTTP process. if that process stops during a tool execution, the saved record may show that the tool started without showing a result. the next process cannot learn the missing outcome just by reading that record.

perhaps the action finished. perhaps it stopped halfway through. perhaps nothing reached its destination. submitting the action again would be another decision with another possible effect.

the prototype therefore refuses continuation while an unfinished turn remains unresolved. inspection and explicit abandonment permit a new turn; they do not roll back an external action. a sandbox orphaned by a hard kill also needs explicit cleanup. there is no automatic tool replay.

the successful restart test proves a narrower, useful property: completed session state can outlive the process that produced it.

the next question is how execution ownership should outlive an HTTP connection, and eventually an HTTP process. that needs its own worker and failure tests.

for now, the record gives the replacement process a place to begin. it also shows where the record ends.

inspect the saved restart-demo receipt


👀

Getting page views