Skip to main content
The SessionStoreProtocol defines the methods any session backend must implement — swap JSON files, Redis, or your own store without changing agent code.
The user plugs in a custom session backend; agents call the same protocol methods regardless of storage.

How It Works

Quick Start

1

Use the built-in JSON store (zero config)

Sessions are automatically persisted to ~/.praisonai/sessions/chat-123.json.
2

Swap to a custom store

Protocol Methods

The protocol requires exactly five methods:
For persistent backends (DB / JSON), clear_session() and delete_session() remove the underlying stored messages too, not just in-memory data. This ensures cleared history does not reappear after a reload or restart.
Backward compatible resume. On resume the agent prefers get_working_history(...) when the store implements it (checked via hasattr), so it can replay a compacted summary + tail. Stores that implement only get_chat_history continue to work unchanged — they simply resume from the raw transcript. See Compacted Session Resume.
The protocol uses Python’s typing.Protocol with @runtime_checkable, so any class with matching method signatures automatically satisfies it — no inheritance needed.
set_chat_history(session_id, messages) (recommended). Atomically replaces the chat history for a session. If your store omits this method, Session.save_state() falls back to add_message() per message and may produce duplicates when called repeatedly. The built-in DefaultSessionStore implements this with reload-under-lock atomic-write semantics.
If your custom store backs onto shared storage (Redis, Postgres, S3), reload from that backing store on every read — do not rely on in-process caches. DefaultSessionStore and BotSessionManager._load_history assume this.

update_session_metadata() API

The update_session_metadata() method enables safe metadata updates across processes without touching messages:

Parameters

Reserved Metadata Fields

The SDK uses these reserved fields internally:

Example Usage

Concurrency Safety

In DefaultSessionStore, update_session_metadata() reloads under a cross-process file lock so concurrent metadata updates and message appends are both preserved.

Built-in Implementations

DefaultSessionStore

JSON file-based persistence with atomic writes and file locking. Mutating and read methods reload from disk under lock so multiple processes can share one directory.

HierarchicalSessionStore

Extends DefaultSessionStore with forking, snapshots, and revert.

SqliteSessionStore

Extends DefaultSessionStore with a stdlib sqlite3 + FTS5 index for scalable cross-session recall (Issue #2927). A drop-in implementation of SearchableSessionStoreProtocol.
See SqliteSessionStore.
SessionHit gained a bookends field (Dict[str, List[Dict]]) carrying the first/last user+assistant turns of a matched session. It is backward compatible — as_dict() only emits the key when populated. See Cross-Session Recall.

Using with Bots

Bots use the same SessionStoreProtocol for persistent per-user sessions:
Each user gets a deterministic session key like bot_telegram_12345, stored in the same ~/.praisonai/sessions/ directory as agent sessions.

Building a Custom Store

Checkpoint Query Protocol

For session stores that support checkpoints and rollback functionality:

Checkpoint Usage


Best Practices

Without it, repeated Session.save_state() calls may duplicate messages via the add_message fallback.
Redis, Postgres, and multi-worker file stores must not serve stale in-process caches.
SessionStoreProtocol is @runtime_checkable — verify custom stores with isinstance(store, SessionStoreProtocol).

Session Persistence

Automatic session save and restore

Sessions Overview

Sessions and remote agents