Sessions
A session is a persistent, resumable conversation. With createLiteAgent, every run is event-sourced to disk through a Checkpointer, and the agent owns a current session: successive send() calls share the full conversation, you can list and resume past sessions across restarts, and you can roll a session back to any earlier prompt. You get durable multi-turn agents without writing any storage code.
Nothing to enable — persistence is on by default via the built-in fileCheckpointer:
Managing sessions
LiteAgent exposes the whole session lifecycle:
Time travel works because the file tools snapshot every file before modifying it: restore replays those snapshots to undo changes on disk, then truncates the event log. See Checkpointing for the full rewind model.
Set sessions: false to disable persistence entirely (session methods then reject).
Persisting to external storage
The default fileCheckpointer is single-process. When several processes on one host must share sessions — an HTTP server, a worker pool, parallel CLI runs — swap in the SQLite backend from @lite-agent/checkpoint-sqlite:
The SQLite backend gives you WAL-based concurrent readers, atomic seq allocation, and optimistic concurrency: a stale writer gets a clean CheckpointConflictError instead of silently clobbering the log. Any custom backend that implements the core Checkpointer interface (append / read / head / list / delete / truncate) works the same way — pass it via the checkpointer (or store) option, which overrides sessions.
Multi-host concurrency (networked FS, distributed writers) is out of scope for SQLite. The Checkpointer interface is backend-agnostic, so a future network backend can cover that without kernel changes.
See also
- Checkpointing — the
listCheckpoints/restoretime-travel model in detail. - Events — the
SessionEventstream that gets persisted. - Agent loop — what happens inside each turn of a session.