The Conversation That Survives a Restart

Article 104 / AI

If an AI feature loses its conversations every time you restart the stack, you will test it badly. Durable sessions fix that at the layer where it belongs.

November 14, 2026 3 min read Article 104

If an AI feature loses its conversations every time you restart the stack, you will test it badly. Durable sessions fix that at the layer where it belongs.

Anything that talks to a model keeps state: who said what, which tool was called, what is half finished. Developers lose that state constantly, then wonder why bugs only appear in long conversations.

The restart problem

Edit a file, hot reload fires, the process restarts, and the conversation you spent ten minutes building is gone. So you stop building long conversations. You test one-turn happy paths, because the long ones are too expensive to recreate.

The bugs live in the long ones: the third tool call, the resumed session, the turn that was interrupted halfway. Your workflow quietly removed the tests that would have found them.

A contract, not a framework

The Flisk agent resource type does not pick your model library. It owns a small process contract and leaves the model call to you:

  • /health for liveness and /ready for "the checkpoint store is reachable", so callers know when to send a turn.
  • A POST turn endpoint that reads x-session-id, loads that session's checkpoint, calls your runTurn, and commits the new checkpoint atomically.
  • GET /sessions to list stored sessions, and flisk agent sessions <resource> to see them as a table or read one checkpoint with --session-id.

Inside runTurn you can call any provider or any orchestration library. The contract does not care.

Where the state lives

With durability: files, checkpoints are written to a named volume that survives flisk down, container restarts and live updates. On SIGTERM the process lets an in-flight turn checkpoint before it exits, so a reload in the middle of a call does not corrupt the session. Sessions nobody returns to are swept after a day by default, and you can drop one immediately with a DELETE on the session endpoint.

Removing the state is a deliberate act: delete the volume by name. Nothing clears it by accident.

Durable sessions are not a production claim. They exist so the way you develop matches the way the feature behaves.

What changes in practice

You can restart freely, keep one long conversation open for a week of work, and find the exact session that broke yesterday with flisk agent sessions and read its checkpoint. The long-conversation bugs start showing up on your laptop instead of in a user's report.