Use cases

A long run that can be killed

The contract this site will stand behind is small. checkpoint() returns, then a new process opens the same directory and the memory is there. A flush that does not checkpoint was tried. The new process did not see it.

What survived a second process

Same snippet as the coding-agent page, because it is the same fact: the write is not the durable step. The checkpoint is. Call it when a unit of work completes, not on every token.

Run, then the interpreter exited.

from fluctlightdb import connect_embedded

brain = connect_embedded("./coding-agent")
brain.experience(
    "The API worker owns transaction boundaries",
    context="decision:api",
    salience=0.8,
)
brain.checkpoint()

A new process printed

The API worker owns transaction boundaries

What did not survive

turn_end(flush=True) reported a committed turn and the same object could recall the text. After that object was dropped, a new process opening the same path recalled nothing. On main, memory_remember calls checkpoint() after that flush, and a second process recalled the sentence. That pair is on the MCP page . A flush without checkpoint() is still invisible to the next process.

The kill test in the repository

CI runs a Rust test that seeds a checkpoint, starts a worker writing experiences without checkpointing, and sends SIGKILL. The parent reopens the brain, requires the store to verify, and requires at least one engram. That test was read, not re-run, while this page was written. The write-up is the SIGKILL note .