Skip to main content
Session enables persistent storage and recovery of Agent state, allowing conversations to maintain continuity across application runs.

Core Features

  • Persistent Storage: Save Agent, Memory, and other component states
  • Simple API: Call saveTo() / loadFrom() directly on Agent
  • Multiple Backends: Supports JSON files, in-memory, and custom storage
  • Flexible Identification: Use simple string session IDs or custom SessionKey

Quick Start


Session Implementations

AgentScope provides two Session implementations: Stores state as JSON files on the filesystem.
Features:
  • Directory format: One directory per session {sessionId}/
  • Single states: {key}.json files
  • List states: {key}.jsonl files (JSONL format, incremental append)
  • UTF-8 encoding, automatic directory creation
⚠️ Security Note: JsonSession uses the sessionId directly as the session directory name. If sessionId comes from untrusted sources (e.g., HTTP cookies or query parameters), an attacker could inject path traversal characters like .. or path separators to read/write files outside the intended session directory. Always validate and sanitize sessionId before use - only allow safe characters (alphanumeric, underscore, hyphen) and reject values containing path separators or .. sequences.

InMemorySession

Stores state in memory, suitable for testing and single-process temporary scenarios.
Notes:
  • State is lost when application restarts
  • Not suitable for distributed environments
  • Memory usage grows with session count

Agent State Management API

Save Operations

Load Operations

Session Management Operations


Complete Example


Custom Session

Implement the Session interface to create custom storage stores:

Data Format and Migration

Old vs New Data Format Comparison

The new Session API uses a completely different storage format that is incompatible with the old SessionManager approach:

Old Format Example

File content:

New Format Example

memory_messages.jsonl content (one message per line):

Data Migration

Due to format incompatibility, old data cannot be directly read by the new API. If migration is needed, follow these steps: If old data is not important, simply delete old session files and use the new API to create new sessions:

Option 2: Manual Migration

If you need to preserve historical conversation data, write a migration script:

Option 3: Dual Version Parallel

During transition, keep old code for reading historical data while using new API for new sessions:

Database Backend Migration

MySQL Table Structure Change

The new API uses a different table structure. If you previously used MysqlSession, you need to migrate the table structure: Old Table Structure:
New Table Structure:
The item_index column enables true incremental list storage:
  • Single states: stored with item_index = 0
  • List states: each item stored in a separate row with item_index = 0, 1, 2, ...
Migration Steps:
  1. Backup old data:
  1. Drop old table:
  1. Recreate (use createIfNotExist=true for automatic creation):
Or manually execute the new table structure SQL above.

Redis Storage Structure Change

The new API uses a different Redis key structure: Old Structure:
New Structure:
Migration Steps:
  1. Clear old data (if not needed):
  1. New data will automatically use the new structure.

More Resources