Cursor, Claude Code, Cline, Aider, Continue all share one shape: high-frequency calls into your repo for conventions, types, error classes, and test scaffolds. kolm compiles those calls into a per-project signed artifact (a single .kolm file) that the agent calls over MCP. The artifact is a compiled binary, not a cache. Offline. K-score gated. Zero runtime egress. 100% deterministic.
Coding agents are good at general code and bad at your code. Your conventions, your type aliases, your test fixtures, your build invariants: the agent re-derives all of it every turn. The model is fine. The harness has nothing to call. kolm compiles a file the harness can call.
Compile only finalizes when the synthesized recipe’s quality score on positives is ≥0.85. Below the gate, no .kolm is written. The K-score composite is then computed over size, accuracy, and coverage and signed into the manifest.
The harness patches fetch, http, https, net, tls, dns before any recipe runs. Any attempted egress is recorded and counted against the artifact. Verified offline.
Every recall is HMAC-chained to the prior call. One ring per: artifact hash, call binding, manifest, optional Sigstore Rekor anchor. Walks offline. Verifiable years later.
Every .kolm in ~/.kolm/artifacts registers as an MCP tool when you run kolm serve --mcp. The agent calls the tool over standard MCP tools/call; the artifact runs its embedded recipes against the input and returns a deterministic answer plus a signed receipt. Same input + same artifact = same output, every time.
The MCP server enumerates every artifact in your local registry. Each tool advertises its K-score, recipe count, signed/unsigned status, and a one-line task description. Agents pick the tool that matches their current step.
The agent posts { name, arguments: { input } }. The server dispatches to the matching artifact, runs its recipes, returns the output as MCP text content plus an _kolm trailer with recipe_id, latency_us, k_score, receipt.
Every artifact ships with the eval set it was gated on at compile time. If the artifact loaded, the signature verified and the K-score ≥ 0.85. The agent does not need to re-verify per call; the binary is the contract.
No fork of the harness. No proxy. No prompt-engineering ritual. kolm compile reads your repo, builds the artifact, and exposes it over MCP. Your agent calls it like any other tool.
# 1. compile your task into a signed .kolm artifact $ kolm compile --task "type-completion" --positives ./examples.json ✓ synthesized 12 recipes (verifier accepted, K-score 0.91) ✓ wrote ~/.kolm/artifacts/type-completion.kolm (3.2 KB, signed) # 2. serve every artifact in your registry over MCP (stdio or HTTP) $ kolm serve --mcp ✓ MCP server on stdin/stdout, protocol 2024-11-05 ✓ 1 tool registered: type-completion (signed, k=0.91) # 3. add to Claude Code / Cursor MCP config and call from any turn. $ cat ~/.config/claude/mcp.json { "mcpServers": { "kolm": { "command": "kolm", "args": ["serve", "--mcp"] } } } agent calls the artifact, not the cloud, for the operations it ran the gate against. re-compile when the inputs change.
A single tools/call against a compiled .kolm dispatches a recipe and returns deterministic output plus a signed trailer. The reference fixture at test/fixtures/sample.kolm measures p50 = 274µs, p95 = 335µs, accuracy = 1.0, network egress = 0 over 400 invocations. Reproduce yourself in 30 seconds.
No state accumulates. Same artifact + same input = same output, every run. To get newer answers, re-compile from newer repo state, like rebuilding a Docker image.
Agent posts JSON-RPC { method: "tools/call", params: { name, arguments: { input } } } over stdio or HTTP.
Server loads recipes (cached after first call), runs the first matching recipe, captures wall-clock latency in microseconds. No network hop.
Server returns MCP text content plus _kolm trailer: recipe_id, latency_us, k_score, signed receipt. Receipt walks offline.
When your repo shape changes (PRs, refactors), re-run kolm compile. Produces a fresh signed .kolm; no migration.
kolm compiles a per-project signed artifact. It is not a memory layer; it is not a frontier-model replacement. It is a file. Below is what the file is good for and where it is the wrong shape.
Repo-aware operations the agent does dozens of times per session: convention lookup, type completion, fixture path resolution, error-class identification, test scaffold generation. Sub-10ms, deterministic, offline. The frontier model handles reasoning; the artifact handles repo facts.
Greenfield code with no repo context, single-file puzzle solves, problems that fit entirely in the agent’s working set. The artifact has nothing repo-specific to contribute. The agent runs as if kolm were not installed.
Tasks that need creative reasoning across the whole repo (architectural redesign, cross-cutting refactors). The artifact is sealed at compile time; it cannot reason about its own contents. Use a frontier model for that, and call the artifact for the hundred lookups that follow.
The model is fine. The harness has nothing local to call. kolm compiles your repo into a signed file the agent can call: deterministic, offline, K-score gated.