What it does
LWC is a command-line tool that gives AI agents persistent memory. Instead of rebuilding an answer from raw document chunks on every query, the agent recalls a maintained wiki, reasons from its sources and earlier synthesis, and writes verified improvements back. The page stresses that LWC is not query-time retrieval: it needs no embeddings or vector database, and it does not embed an LLM itself. The agent runs the CLI; the human picks sources, states goals and reviews the results. SQLite is the canonical store, with Markdown, full-text indexes and optional graph stores rebuilt from it. Sources are saved as immutable snapshots, wiki pages keep citations and links, and a temporal memory records decisions, outcomes and unresolved work. Project and global scopes are kept separate. Search is lexical and page-first, with handling for Chinese, Japanese and Korean text, and a read-only local viewer shows pages, sources and graphs. A single command, lwc agent install, detects supported agents and sets up their MCP, skill, hook and instruction surfaces. The page names Claude Code, Cursor, Codex, OpenCode, Hermes, Gemini CLI, Antigravity, Kiro, GitHub Copilot in VS Code, Copilot CLI, Copilot for JetBrains and pi. Other features include changesets with rollback, memory archives, multi-machine sync over SSH, optional document conversion, and self-hosted team spaces. Install with npm, Homebrew, crates.io, GitHub releases or a local Cargo build.
Capabilities
- Source-grounded wiki memory stored in local SQLite, with rebuildable Markdown and indexes
- One-command setup of MCP, skill and hook integrations for twelve named agents
- Atomic changesets with checksummed rollback for multi-step knowledge updates
- Separate project and global scopes, plus a temporal memory of decisions and outcomes
- Memory archives, SSH sync and self-hosted team spaces
- Read-only local viewer for pages, sources and graphs
When to use it
- You want a coding agent to remember project knowledge across sessions with citations back to sources
- You use several agents and want one memory layer across them
- You prefer a local-first, auditable store over a hosted vector database
- A team needs shared agent memory on a server it hosts itself