Knowl

Local-first. Typed. And retired the moment it stops being true.

Quick start · Why supersession · What gets stored · Features · Agent setup · Viewer · Requirements · Full reference →

Coding agents start every session blank, so teams write things down — and those notes only ever grow. Six months in, the store still reports the database you migrated off last spring, because nothing ever told it that decision was over.

Knowl is persistent memory across sessions for Claude Code, Cursor and Codex: a repository-local store of typed knowledge atoms — decisions, constraints, architecture, facts, goals, state, and skills — read and written over an MCP memory server or the knowl CLI, where a replacement retires its predecessor at write time instead of sitting beside it.

Quick start

Requires Node.js 22 or later.

npm install -g @dat999zx/knowl
cd your-project
knowl init

knowl init creates .knowl/, installs the project guidance files, updates .gitignore, and offers MCP and lifecycle setup for whichever agents it detects — Claude Code, Codex, Cursor, Gemini CLI, Claude Desktop. It also warms the local embedding model, but never depends on that download succeeding.

Record something worth keeping:

knowl decide "Use SQLite" "Use SQLite for local project memory." \
  --reasoning "Keeps storage repository-local and simple to operate." \
  --alternatives PostgreSQL MongoDB \
  --tags database local-first

Read it back, from the CLI or from any connected agent:

knowl query "why sqlite"     # search project memory
knowl state                  # the active memory, as a hierarchy
knowl status                 # repository, memory, AI, and workspace status
knowl doctor                 # check setup, retrieval, and agent registration

Then start a new agent session so the host picks up its guidance and MCP registration. The CLI and knowl_query read the same store under the same governance rules.

The idea: memory that retires itself

Most memory systems are append-only. Storing "we moved to SQLite" leaves "we use PostgreSQL" active and retrievable, so the agent gets both and picks by rank. Knowl treats a same-subject write as a correction: the predecessor is marked superseded, drops out of normal retrieval, and stays queryable through knowl timeline.

That single behavior is most of the accuracy difference. On the MemoryAgentBench Conflict Resolution corpus — 455 facts, 100 questions about which fact is current, top-5 retrieval, no LLM reader:

Same corpus, same ranker, same query path. The only variable is whether the outdated fact is still active. This is a retrieval-level measurement in Knowl's own harness: it asks whether the current fact comes back first, with no model in the loop.

Verified end-to-end, in the benchmark's own harness

Because a number you score yourself is worth less than one somebody else scores, the same claim was re-run inside MemoryAgentBench's harness, scored by its own code, with an LLM reading what Knowl returned — the harder, fully end-to-end setup, at the largest context the task offers:

18,332 facts, 100 questions, substring exact match. Every row uses gpt-4o-mini as the reader, Knowl's included — the paper states it for all RAG and memory agents, so these are like-for-like. Knowl's figure was measured here; every other figure is from the MemoryAgentBench paper, Table 2. Systems the paper does not evaluate on this task are not listed.

Switching supersession off in that same harness drops Knowl to 73, and the gap holds across a 40× change in corpus size:

The two sections measure different things and are not comparable to each other: 98% is retrieval top-1 at 6K with no reader, 90 is end-to-end accuracy at 262K with one. Only the second is comparable to the published systems above. See benchmarks for the protocol, the checked-in results, and what the task does not cover — including multi-hop, where Knowl scores 7 against a 14-point retrieval ceiling.

Supersession is a correction, not a delete: the item, its assertions, and its history all survive.

Not a mock-up — the same sequence against the published CLI, recorded from demo.tape:

What gets stored

Every atom has exactly one of seven categories:

Alongside the content, each atom keeps a status (active, deprecated, rejected, archived, superseded), a freshness flag, confidence, tags, source commit, affected paths, and optional evidence pointing at files, commits, tests, commands, URLs, or indexed code symbols. File and symbol evidence go stale on their own when the code moves, which is how an atom admits it may be out of date instead of asserting a version of the repository that no longer exists.

What Knowl deliberately does not store is your conversations. Lifecycle capture records bounded events and summaries — never prompts, transcripts, stdout, or environment variables. Raw transcript search exists as an opt-in, off-by-default index over files the host already wrote.

→ Knowledge model reference

Connecting an agent

Claude Code MCP · lifecycle · subagents

Codex MCP · lifecycle · subagents

Cursor MCP · lifecycle

Gemini CLI MCP · manual loop

Claude Desktop MCP · manual loop

knowl serve exposes the store over stdio MCP; knowl init registers it for you. The workflow the installed guidance asks agents to follow is short:

1. Query memory with the words that name the subject before reading repository files.
2. Use an active hit directly; inspect files only on a miss, conflict, or stale result.
3. Store durable findings, stated goals, and recurring diagnoses as you go, and correct contradicted memory rather than duplicating it.

In practice that looks like this — a new session, no context, nothing pasted in:

You     why did we pick SQLite over Postgres?

Agent   → knowl_query "sqlite postgres database choice"
        ← decision · Use SQLite · active · fresh
          "Keeps storage repository-local and simple to operate."
          alternatives: PostgreSQL, MongoDB
          tags: database, local-first

        SQLite keeps the store repository-local and simple to operate.
        Postgres and MongoDB were both considered and rejected on that
        basis.

The agent answered before opening a single file, and it knew the options you rejected — which the code cannot tell it, because rejected alternatives leave no trace in a codebase.

Where hooks are available, they own the session lifecycle: bootstrap context, capture, checkpoints, and finalization happen without the agent being asked. Where they are not, knowl task run, task start, task checkpoint, and task finish cover the same ground manually.

knowl init writes the MCP registration for every host it detects. To wire one by hand, the entry is the same everywhere:

{
  "mcpServers": {
    "knowl": { "command": "knowl", "args": ["serve"] }
  }
}

Use knowl.cmd as the command on Windows. Codex reads the same entry under mcp_servers.

→ MCP tools and resources · Lifecycle reference

What Knowl is for

Knowl does one job: keep a repository's engineering truth accurate for the agents working on it. Not user preferences, not chat history — the decisions, constraints, and architecture of a codebase, and which of them are still true today.

Three choices follow from that:

• Typed, not free text. A decision carries reasoning and the alternatives you rejected. A constraint is a rule that must keep holding. A state atom is expected to go out of date. Retrieval can rank on those differences; it cannot rank on paragraphs in a notes file.
• Governed, not append-only. Status, freshness, provenance, conflict identity, and supersession let the store tell you that something stopped being true. That is the whole difference between memory and an ever-growing pile of notes.
• Repository-local, not a service. The database sits beside the code it describes. No account, no egress, no vendor between you and your own project history.

Knowl is deliberately not a personalization layer. It has no opinion about your users, and it keeps no transcripts of its own.

Features

Everything below works from the CLI and from any MCP-connected agent, against the same local database. No account, no server, no API key. Each item links into the full reference for the detail — and for the limits.

The commands worth knowing on day one:

knowl query "auth design"              # search project memory
knowl state                            # the active memory, as a hierarchy
knowl conflicts                        # items that contradict each other
knowl timeline <item-id>               # every version an atom ever had
knowl context --token-budget 1500      # a fixed-size briefing for an agent
knowl pr --since origin/main           # knowledge your diff may invalidate
knowl doctor                           # setup, retrieval, and registration

knowl workspace init product      # create the workspace
knowl workspace add product       # run inside each repo that joins it
                                  # ...or --default-visibility repo to keep its writes private

knowl workspace promote                               # pick what to share from a list
knowl workspace promote --category decision --apply   # or name it outright

See it: the local viewer

knowl view starts a read-only inspector on 127.0.0.1 with a fresh access token per launch — knowing the port is not enough to read anything.

knowl view

Search, filter by category, spot stale rings, focus a neighborhood, and open any atom to read its evidence and timeline. The graph links atoms through shared tags and category-derived edges — a navigation aid, not a causal or evidence graph. It shows full local content across every status, so loopback binding is the privacy boundary: do not put it behind a public proxy or tunnel.

→ Local viewer

Everything else

27 MCP tools (plus 3 when transcript search is on, 1 when connected to a cloud workspace, 1 when linked into a local workspace, and 1 when change impact is on)

and two resource URIs · the complete CLI, from knowl status to knowl audit · a read-only integrity audit · retrieval evaluation you can run yourself against the checked-in governance and 500-case regression suites with knowl eval.

→ CLI reference · MCP tools · Benchmarks

Requirements and local data

Node.js 22 or later. Everything Knowl writes for a project lives under .knowl/, which knowl init adds to .gitignore:

Workspace manifests live outside member repositories, because their checkout paths are machine-local. Exports and snapshots are written only when you ask for them.

Documentation

Everything above is the summary. The full reference is one document covering every subsystem in depth — including the parts that are deliberately limited, which is usually what you actually need to know.

Contributing

See CONTRIBUTING.md for setup, the checks to run before a pull request, and the conventions this codebase follows. Contributors are asked to agree to the Contributor License Agreement once, on their first pull request.

License

Knowl is licensed under the Apache License 2.0. Apache-2.0 does not grant trademark rights.