Skip to content

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

3 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Rei Memory System

Rei Memory System is the local memory layer behind Rei's Hermes setup.

It stores durable agent memory in SQLite, retrieves it with keyword and vector search, and mirrors selected memory knowledge into an Obsidian-readable wiki. The public repo contains the engine, CLI, tests, and a legacy adapter package. It does not contain Ryot's live memory data.

Package: rei-memory-system Runtime target: Hermes Agent local memory Mirror target: Obsidian markdown vault License: MIT

Why this exists

A long-running agent should not depend only on a chat transcript.

Rei needs to remember stable facts across Telegram, CLI, cron jobs, coding work, crypto operations, and research. The memory layer has to answer a harder question than "what text matched this query?" It has to decide which facts are durable, which facts are stale, which facts should stay hidden from lower-trust agents, and which facts should be visible to Ryot as readable notes.

RMS is the local storage and retrieval layer for that job.

It is built to:

  • store short durable facts in a local SQLite database
  • retrieve memories with FTS5 keyword search and vector similarity
  • group facts into logical categories and hidden storage banks
  • support supersession, deduplication, and decay
  • redact credential-like material from restricted reads
  • expose selected memory knowledge as Obsidian markdown
  • keep runtime databases, logs, credentials, and private facts out of Git

Current deployment

The current Rei deployment is Hermes-first.

On this machine, Hermes is configured with:

memory:
  memory_enabled: true
  user_profile_enabled: true
  provider: holographic

The live database is a local SQLite store under the Hermes home directory. At the time this README was rewritten, that live store had:

  • 39,658 memory facts
  • 16,212 entities
  • 74,715 fact-to-entity links
  • 333 memory banks

The same memory system is mirrored into Ryot's Obsidian vault as human-readable notes. The mirror has English and Korean wiki trees under Rei Memory and Rei Memory KO.

Those numbers describe the private local deployment. The public repository does not include the live database, the Obsidian vault, session logs, credentials, or private facts.

System model

Hermes Agent
  memory provider: holographic
        |
        v
Local SQLite memory store
  facts
  entities
  fact-entity links
  FTS5 index
  memory banks
        |
        v
Retrieval layer
  keyword search
  vector similarity
  category policy
  redaction policy
        |
        v
Obsidian mirror
  Rei Memory
  Rei Memory KO

The database is the source of truth. Obsidian is the readable mirror. GitHub is only the public code export.

What this repo contains

  • packages/core: SQLite schema, store API, search, category logic, vault indexing, markdown writer, decay, migration helpers
  • packages/plugin: legacy adapter package from the OpenClaw era, still useful as reference code for memory-slot integration
  • bin/rms.mjs: CLI entry point for local store/search/stat operations
  • test/: root regression checks for redaction, database setup, decay, parsing, hashing, and categories
  • verify.sh and prove.sh: local verification scripts

What this repo does not contain

This public repo does not contain:

  • Ryot's live memory database
  • Obsidian notes from the private vault
  • session transcripts
  • private agent logs
  • credentials or .env files
  • a hosted memory service
  • a cloud vector database
  • a finished UI

It is a public code export of the memory engine and its tests.

Core capabilities

Current code supports:

  • SQLite-backed memory storage
  • FTS5 keyword retrieval
  • sqlite-vec vector index support
  • reciprocal-rank fusion for hybrid search
  • text-hash duplicate detection
  • supersession links for replaced facts
  • soft decay and archive support for stale memories
  • retry queue for failed embedding jobs
  • logical categories with hidden bank-key rollover
  • category-aware read and write policy for Rei, Asa, Frimion, Zeminion, and system callers
  • credential redaction for restricted agents
  • Obsidian-style markdown vault indexing
  • generated-zone writer for managed memory output
  • CLI commands for store, search, migrate, decay, stats, export, and retry

Hermes and Obsidian relationship

Hermes is the runtime that uses memory during conversations and tool work.

RMS is the local memory engine work that shaped the store, search, category, and sync model. The live Hermes profile now uses a holographic memory provider with a SQLite database. Obsidian acts as the human-readable mirror so Ryot can inspect the memory graph outside the chat UI.

That separation matters:

  • Hermes uses memory at runtime.
  • SQLite stores the durable facts and indexes.
  • Obsidian shows a readable projection of selected knowledge.
  • GitHub publishes code only, not private memory content.

Legacy OpenClaw adapter

Some files still mention OpenClaw because RMS started before the Hermes migration. The adapter package in packages/plugin is kept as legacy integration code and test material.

That does not mean the current deployment is OpenClaw-based. The current live setup is Hermes with the holographic memory provider.

Requirements

  • Node.js 24 or newer
  • npm
  • SQLite support through better-sqlite3
  • Optional: Ollama with an embedding model such as bge-m3:latest

If embeddings are not available, search falls back to FTS and reports degraded vector availability instead of failing the memory path.

Setup

npm install
npm test
npm run build

Core tests:

npm test --workspace=packages/core

Adapter tests:

npm test --workspace=packages/plugin

CLI examples

Use the default database path:

rms store "Rei should keep credential facts out of lower-trust prompt sections." --category credential --source example
rms search "credential prompt policy" --limit 5
rms stats

Use a throwaway database:

RMS_DB_PATH=/tmp/rms-example.db npm exec rms -- store "SQLite is the local memory store." --category technical
RMS_DB_PATH=/tmp/rms-example.db npm exec rms -- search "local memory store"

Migrate markdown memory files:

rms migrate --dir /path/to/workspace --dry-run

Category model

RMS separates the human-facing category from the hidden storage bank.

Example:

logical category: project/dlmm/strategy
hidden bank key:  project/dlmm/strategy#0003

This keeps search and permissions understandable while allowing a busy category to roll over into multiple storage banks. Callers ask for logical categories. The store manages bank keys.

Safety model

Public repo safety rules:

  • runtime databases are ignored
  • logs are ignored
  • .env files are ignored
  • credentials are redacted in restricted reads
  • markdown sync should render credential entries as references, not plaintext secrets
  • the public history started from a clean export

The live private memory store is not part of this repo.

Verification

Useful checks before changing the package:

npm test
npm run build
npm test --workspace=packages/core
npm test --workspace=packages/plugin
git diff --check

For public safety, scan the committed tree and the full history before publishing changes.

Repo status

This public repository is a clean export of the current RMS codebase. The earlier private working history is kept separately and is not part of the public Git history.

Releases

Packages

Contributors

Languages