Langonrock

Overview

A multi-tenant store for Open Knowledge Format bundles, built so an agent spends as few tokens and as few round trips as possible reading them.

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 graph one file at a time, spending an inference turn per hop.

langonrock keeps your Markdown as the source of truth and compiles it into a dense read model. A manifest the agent keeps in its cached prompt prefix, and section-addressable concepts it fetches in batches. Your bundles stay conformant, so okflint, the visualizer and Obsidian keep working on the same folder.

What it costs to read

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

OKF navigatorlangonrock
Tokens billed for a 20-question session116,35764,355
Tool calls3017
Tokens for one concept read594213

The saving comes from the manifest carrying the link graph. 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. Full numbers, including where the store loses.

Where to start

What it does

Compiles OKF, does not replace it. Your directory of Markdown stays the source of truth and stays conformant.

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 input compiles to identical bytes, so the manifest stays in the prompt cache across rebuilds.

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

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

Deterministic retrieval. BM25 plus a capped one-hop expansion over the link graph, with no model call anywhere in the path.

Immutable, content-addressed snapshots. A backup is a file copy, a restore is a file copy back, and a rollback is a side effect of naming files by their own hash.

Multi-tenant. A tenant is a directory boundary with its own snapshots and its own 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. Four verbs for Claude Code, Cursor, or anything else that speaks MCP.

Editable over the network. Create, change and delete concepts through the API, with a mandatory precondition so two editors cannot silently overwrite each other.

No database. Two runtime dependencies, both for MCP.

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

Two runtime dependencies

@modelcontextprotocol/sdk and zod, both for the MCP server. Everything else, including YAML parsing, directory walking, hashing and zstd, comes from Bun.

On this page