Design a Hermes Session Retention and Archive Policy
Session history powers resume, search, incident review, and operator continuity. Keeping everything forever increases privacy exposure and makes test traffic harder to navigate; deleting aggressively destroys useful provenance. A retention policy should distinguish active work, completed reference sessions, disposable tests, and records that require controlled archival.
Official documentation: https://hermes-agent.nousresearch.com/docs/user-guide/sessions#session-management-commands
Classify before pruning
Use hermes sessions list and statistics to understand volume by platform and age. Rename valuable sessions with outcome-based titles. Export records that must survive deletion, using redaction when content may contain keys, credentials, or private identifiers. Archive sessions that should leave normal resume results but remain recoverable in the database.
Pruning is destructive. Preview with --dry-run, combine filters deliberately, and remember that adding an explicit filter can change default age behavior. For test storms, constrain both platform/title and a narrow timestamp window rather than deleting every recent session.
Policy checklist
- Define retention classes for active, reference, test, and sensitive sessions.
- Set title conventions for important work.
- Choose archive versus export-and-delete for each class.
- Redact exports intended for broader review.
- Store archives with access controls and a retention date.
- Preview every prune operation.
- Back up
state.dbbefore a large destructive cleanup. - Review whether gateway and cron workloads need different windows.
Search and lineage considerations
Compression can create session lineage while preserving a logical conversation. Export lineage as one document when the audit requires continuity. Session search depends on the canonical database, so archived or deleted records affect what the agent can recall later. Do not describe pruning as storage-only housekeeping when it also changes operational memory.
Common pitfalls
- Deleting by a vague title substring without a dry run.
- Exporting private sessions without redaction.
- Assuming archived sessions are removed from the database.
- Pruning the latest lineage while keeping only an obsolete branch.
- Setting automatic cleanup before measuring normal session growth.
- Keeping test conversations indefinitely because the database is still small.
Verification steps
- Generate session statistics and record the baseline count.
- Preview the exact archive or prune selection.
- Export one representative session and open the result.
- Run the operation and compare counts.
- Confirm active sessions still resume and important terms remain searchable.
- Test restoration or retrieval of the archived class according to policy.
