Skip to content

Choose an install path

There are three practical ways to adopt openclaw-mem. Start with the lightest path that solves your problem.

Quick-start decision guide

  • Prove it locally (5 minutes) → start with Path 1: Local proof
  • Run sidecar on existing OpenClaw (default) → choose Path 2: Sidecar on existing OpenClaw
  • Promote to optional mem engine when needed → use Path 3: Optional Mem Engine

Path 1 — Local proof in one repo

Choose this when

  • you want a 5-minute product proof
  • you do not want to touch OpenClaw config yet
  • you want to inspect the SQLite / JSON outputs first

What changes

  • install the packaged CLI with pip install openclaw-context-pack
  • or clone the repo and run uv sync --locked for repository fixtures
  • generate or provide a JSONL file
  • run local recall commands against SQLite

What you get

  • local DB
  • deterministic CLI receipts
  • proof that search → timeline → get works

First step

python -m venv .venv
. .venv/bin/activate
pip install openclaw-context-pack
openclaw-mem --db /tmp/openclaw-mem-demo.sqlite status --json

Then go to Quickstart.

Rollback

Delete the test DB or the repo checkout. No OpenClaw state changed.

Path 2 — Sidecar on an existing OpenClaw install

Choose this when

  • you already use memory-core or memory-lancedb
  • you want capture, freshness, auditability, and local recall
  • you want minimal migration risk

What changes

  • enable the openclaw-mem plugin
  • point it at a JSONL output path
  • schedule harvest on a freshness cadence
  • optionally add embed/index on a slower cadence
  • if installing from a marketplace/package registry, this role maps to @phenomenoner/openclaw-mem

What you get

  • tool-result capture
  • SQLite recall layer
  • backend-aware observability
  • deterministic triage / ops workflows
  • optional continuity side-car activation later without changing the active memory slot
  • continuity operator loop can later graduate from snapshots to explain/sensitivity/patterns/triggers/interventions without changing the active memory slot
  • no active memory-backend change

First step

Read:

Rollback

Disable the plugin, stop harvest jobs, remove the symlink if you added one. Your native memory slot stays untouched.

Path 3 — Optional Mem Engine as active memory backend

Choose this when

  • sidecar mode already proved useful
  • you want hybrid recall, policies, and bounded automation in the active memory backend
  • you are comfortable doing a controlled switch with smoke tests and rollback

What changes

  • keep the sidecar for capture / audit
  • enable openclaw-mem-engine
  • switch plugins.slots.memory
  • smoke test store / recall / forget
  • if installing from a marketplace/package registry, this role maps to @phenomenoner/openclaw-mem-engine

What you get

  • hybrid recall path
  • core memory runtime registration on capable OpenClaw hosts, so doctor/status can recognize mem-engine as the active backend
  • operator-tunable receipts and policies
  • more explicit control over recall/capture behavior
  • optional Proactive Pack lane for bounded pre-reply recall during live turns
  • optional continuity side-car activation from the same checkout if you want governed derived continuity receipts
  • one-line rollback to memory-core or memory-lancedb

First step

Read:

Rollback

Switch plugins.slots.memory back to the prior backend (memory-core or memory-lancedb), restart OpenClaw, and run openclaw doctor / openclaw status as the readback gate. The mem-engine data store is not deleted by the slot switch.

If you are deciding between paths, choose Path 2: sidecar on an existing OpenClaw install.

That is where openclaw-mem is easiest to justify:

  • high observability value
  • low migration risk
  • clean rollback
  • you can still promote to the engine later

After you choose