Remnic: Give Your AI Agents a Local-First Shared Memory Store

Who It's For

• Individual developers who want their AI assistants to have memory that persists across sessions and is shared across multiple agents: memories are stored as plain markdown files with YAML frontmatter on your own disk, and the search index can be rebuilt from these files—no external database service required. MIT-licensed open source, local-first.
• Also suited to scenarios where you use multiple agents and want "one memory store, usable by every agent"; beyond storage and recall, the MCP tool surface also includes entity lookup, memory correction, recall by time, X-ray source tracing, daily briefings, a work board, and continuity tools.
• Not suitable if: it requires Node.js 22.12 or newer, so older environments won't work. The evidence does not state the degree of remote deployment support (Docker, hosted services, etc.); if you have such needs, verify on your own first.

First Try in 3 Minutes

The recommended main path is the official CLI end-to-end flow:

1. Prerequisite: install Node.js 22.12 or newer (nodejs.org).
2. Install and initialize:

npm install -g @remnic/cli
remnic init

remnic init writes the remnic.config.json configuration file (a local state write, a normal initialization step). The global install also installs the remnic command, plus the legacy engram forwarding command.

1. Start and verify:

remnic daemon start
remnic status

A normal response from remnic status is the success signal, meaning the background service is running and ready for clients to connect. In standalone mode, the daemon can run as an HTTP endpoint exposing MCP tools (the official @remnic/server run mode is also available as a secondary option). For first verification, stick to status-check actions like remnic status before doing real storage.

Note the distinction: remnic init and subsequent memory writes both write to local disk—they are not read-only operations; remnic status is a low-risk check of running state.

Use Cases

• Case: store a memory, then recall it. With the daemon running, store a fact into the memory store, then query it via an MCP recall call. Memory records are markdown files with YAML frontmatter on disk (with structures like category: decision); once stored, you can see the record directly in your local files and recall it from the agent side. The evidence does not provide exact call parameter examples for the store/recall tools; refer to the tool descriptions listed by your MCP client for specifics.
• Case: pick up yesterday's work with the daily briefing/continuity tools. After connecting to the MCP endpoint, the client lists Remnic's tool surface, which includes daily briefing, work-board, and continuity tools; calling a briefing-type tool gives you an overview of the current state based on existing memories. Exact tool name spellings follow the tool list shown by the client; the evidence does not enumerate them.

Limits of Use

• Remnic is a local read/write system: storing a memory writes markdown files to disk, and correcting a memory modifies existing content; the evidence does not mention a built-in undo/rollback path, so it should not be assumed to be automatically reversible. Deletion and backup depend on your own management of local files.
• Memories are stored as plaintext markdown on local disk; be cautious about storing sensitive information. The README's specific statements on privacy and redaction policies were not found in the evidence—unknown.
• The service requires Node.js ≥ 22.12; details such as the port clients connect to and authentication were not disclosed in the evidence. If you need network exposure, consult the official documentation first to confirm.
• Unconfirmed items (privacy policy, full tool parameters, remote deployment) should be checked against the latest README in the official repository.