Overview

langonrock is a document database for Markdown, built around the agents that read it. It stores your documents in its own engine, commits related edits atomically, keeps each commit as a revision you can list and restore, and compiles every commit into a read model an agent can afford: a manifest it keeps in its cached prompt prefix, and section-addressable concepts it fetches in batches.

The engine is Bun and TypeScript plus a small C adapter for OS locks and durable file replacement. There is no SQL, no SQLite, no external database service and no Python, and no embedding model anywhere in the read path.

Why Markdown, and why compile it

OKF is a good authoring format. A directory of Markdown with YAML frontmatter, no SDK, no runtime, readable in Obsidian and diffable in git. It is an expensive reading format. The agent pays for full frontmatter on every read, the prose is written for people, and the reference consumption pattern walks the links one file at a time, spending an inference turn per hop.

The database keeps the authoring format whole. Import reads a folder of bundles, export writes the exact Markdown back out, frontmatter and line endings included, and what the agent pays for is the compiled read model rather than the files.

What it costs to read

Measured against the OKF reference consumption pattern over the same corpus and the same twenty questions:

The saving comes from the manifest carrying every concept's outgoing links. The agent knows every id it needs before it fetches anything, so one batched call covers them all, and it can ask for a single section instead of the whole concept. The manifest itself is not smaller than the Markdown it replaces.

That corpus is a warehouse catalogue, and the saving depends on the documents more than on the store. Over a set of RFCs the same twenty questions save 98 percent. Over four novels they save 69 percent, nearly all of it from find returning the passage instead of the chapter; without it the novels save 2 percent. Full numbers, including where the store loses.

What the database adds

Atomic commits. A transaction carries 1 to 1,000 document writes and deletes, up to 16 MiB of Markdown, and becomes visible all at once. A batch with one conflicting change publishes nothing.

Every change names the version it replaces. Replacing or deleting a document requires the sha256 of the version you read, and leaving it out asserts that the document is new. Two writers cannot silently overwrite each other.

History you can restore. Each commit is a revision. History pages newest first, and restore publishes an older revision's complete source as a new commit, guarded by the revision you expect to be current, so nothing in the history is rewritten.

A returned commit is on disk. Every immutable file is synchronized before one atomic replacement of the tenant's HEAD. A failure after that point is reported as indeterminate rather than guessed at, and a corrupt HEAD fails closed instead of falling back to an older revision.

Folders in and out. Import remembers what it last read from each folder, so an unchanged file never overwrites a database edit, and a document changed on both sides fails the whole import. Export writes the exact Markdown of the current revision to a new directory.

Maintenance you can check. verify reads stored data independently of the caches, gc keeps ten revisions by default, and repair needs the head hash that verify reported.

Where to start

What the read side does

Compiles any Markdown, keeps OKF as the bar. Every file compiles, frontmatter or not, with its id, summary, title and links derived from the text; --strict is the OKF conformance gate.

A manifest that fits in the prompt. One dense TSV row per concept: id, bundle, kind, status, grain, summary, outgoing links.

Byte-deterministic output. Identical documents compile to identical bytes, so the manifest stays in the prompt cache across commits that do not change it.

Section addressing. get(id, { section: "schema" }) returns one slice instead of the whole document, using the concept's own Markdown headings.

Sliced reads on any document. offset and limit page a long concept, and find returns a window around a literal phrase plus the offset of every occurrence, so prose with no headings still gets addressable parts. Over MCP a read stops at 15,000 characters per concept by default.

Batched reads. Pass every id you need in one call. N concepts cost one round trip.

Deterministic retrieval. BM25 plus a one-hop expansion along the manifest's links column, capped so a hub concept cannot drag in half the tenant, with no model call anywhere in the path.

Search that points inside the document. Every direct hit carries pos, the offset of the passage densest in the query's words, so the next get can be a 2,000-character window instead of the document, even when the question quotes nothing.

Knowledge that expires visibly. A concept past its stale_after date shows stale in the manifest's status cell, computed at read time so the snapshot bytes never depend on the clock.

Multi-tenant. A tenant is a directory boundary with its own revisions, its own snapshots and its own search index.

Three connection modes, one interface. Embedded, local daemon, or HTTP server, selected by a connection string.

Refuses to leak its own credentials. TCP needs a token, and any address past loopback needs TLS, or the server declines to start.

MCP server. Six tools for Claude Code, Cursor, or anything else that speaks MCP, four to read and two to write, and three more for transactions, history and restore when you ask for them. The server measures the manifest at startup and tells the model whether this tenant is cheaper to read manifest-first or search-first.

A model can persist knowledge, safely. The MCP write and delete tools commit one document and answer with the new snapshot, and the first write creates a tenant that does not exist yet. Both still need the hash they replace, and the refusal names that hash, so a model satisfies the precondition without a lost update.

Where it stops

• No query language. The interface is a fixed set of verbs, the same on every transport. There is no SQL and no relational query language.
• One machine. No replication, and no guarantees for network filesystems.
• One tenant per transaction. A transaction is scoped to the connection's tenant, and a request that names a tenant itself is rejected.
• Disk grows with history. Every commit writes a complete immutable snapshot, reusing the unchanged compressed bodies. After the same ten edits with ten revisions kept, the engine used about 69 percent more disk than the one it replaced at 20,000 concepts. gc is what bounds it.
• Crash-tested, not power-tested. Recovery is tested by killing processes. That says nothing about power loss or about every filesystem's durability behaviour.
• Opening got slower on Bun 1.4.2. Opening a tenant measured 34 to 68 percent slower than the engine it replaced at 500 and 5,000 concepts, in a ten-pair capture. Searching, reading and editing got faster. See Engine benchmarks.
• Windows is not verified. The test suite runs in CI on Linux, macOS and Windows. It passes on Linux and macOS and does not pass on Windows yet.

What a commit guarantees, and how each failure surfaces, is in Durability and failures.

The shape of a session

An agent reads the manifest once, usually from the cached prompt prefix. It picks ids from the rows it already holds. It fetches them in one call, and only the section it needs.

langonrock manifest --data ./data --tenant acme

# tenant: acme
# bundles: ops sales
id	bundle	kind	status	grain	summary	links
deploy	ops	runbook	-	-	How to ship the orders service.	-
customers	sales	bigquery_table	deprecated	customer_id	Registered customers, including churned.	-
orders	sales	bigquery_table	-	order_id	One row per completed customer order.	customers

Everything needed to plan the reads is in those rows. A status cell other than - is the concept telling you it is not current.

langonrock get orders --section schema --data ./data --tenant acme

When the agent learns something worth keeping, it writes it back as a commit, and the next manifest it reads already carries the new row.

The editor

langoneditor is the human-facing half: a desktop app for macOS, Windows and Linux that browses the bundle tree, edits concepts as Markdown with a form for the frontmatter the compiler keeps, draws the link graph, searches through the server's BM25 index, and imports or exports bundles as archives or spreadsheets.

It ships the langonrock binary inside it, so nothing else is required to run it. See editing over the network for the API it is built on, and the library for the client it uses.