---
title: "kmem — why it exists"
type: reference
tags: [signpost, root, reference]
proposed_by: tok_bc09b340db294c709763789154d8113d
model: kmem-docs-publisher
extracted_at: "2026-10-08T22:24:51.760Z"
---
# kmem — why it exists

Read this to understand why kmem exists and who it is for. For what to build, read
[`design/CONTRACT.md`](./design/CONTRACT.md). For how it looks, read
[`design/DESIGN.md`](./design/DESIGN.md).

| | |
| --- | --- |
| **Product** | kmem, always lower case |
| **What it is** | A hosted team knowledge base for people and AI agents |
| **Stage** | Live on kmem.app. Paid and hosted. The code is private |
| **Where it runs** | `kmem.app`. One organization, one subdomain |

## 1. The name

kmem is short for knowledge memory. That is the whole gloss. It is said once here, once in the
documentation, and then never again. There is no acronym to expand and no capitalised form. The name
is always written `kmem`: lower case, one word, in every position, including the first word of a
sentence. A source scan enforces it.

One sentence, the same in every place it appears:

> A team knowledge base your assistants can read and write.

Use *team knowledge base* in a meta description and in a registry listing, because that is the phrase
people search for. Do not invent a category name. An invented category costs money to teach.

## 2. The problem

An AI assistant arrives every morning with no memory of the company. Each person explains the same
things again, and each person's assistant drifts from the others.

Underneath that sits an older problem: the most valuable knowledge in a company is never written
down. Why the team chose this supplier. Why that approach failed. What somebody promised a client in
March. It lives in chat threads nobody can find, in call recordings nobody replays, and in people's
heads. When a person leaves, it leaves with them.

For a technical reader the same thing is a reachability problem. An agent reads `AGENTS.md`,
`CLAUDE.md` and a `SKILL.md` bundle natively. It reads a wiki page weakly and an issue tracker
noisily. It reads an ADR only when that repository is open in the session. It does not reach a chat
thread, a pull-request comment or a person's head at all. Those last three hold the *why* behind a
decision, which is exactly where the value sits.

## 3. The thesis

**Agents propose. People decide.**

The line is the product's, and this is what it means today. A read-only connection cannot write or
propose. A propose connection queues every change, including a new doc; nothing is live until a
person accepts it. A write connection does the same while Agent writes is off (the default for a
new org). Only when Agent writes is on **and** the connection can write does the instance
`conflicts` policy apply a new doc at a free address or an edit that names the current version
(`apps/worker/test/services/agent-writes-clamp.test.ts`). A deletion, a stale or blind edit, and a
doc that replaces a live one still wait in Review
([ADR 0017](./docs/ADR/0017-conflict-only-review.md), [ADR 0022](./docs/ADR/0022-agent-writes.md)).

This is the whole product argument. A memory server that lets an agent overwrite the record produces
a record nobody trusts, and a wrong memory is worse than no memory, because the next agent believes
it. The queue is what makes an agent write safe by default. Provenance on every block records who
wrote what, so the record stays auditable afterwards.

**Verification tracks who wrote each fact, and whether a person has checked it**
([ADR 0027](./docs/ADR/0027-verification-is-tracking.md)). Each org chooses whether it uses it
([ADR 0018](./docs/ADR/0018-verification-is-an-org-choice.md)). A new org starts without it: docs
show no fact states, and answers treat every fact the same. With verification on, agent text shows
Unverified, Accepted or Verified, and answers rank verified facts first. Accepted and unverified
facts still appear in answers, ranked lower. A doc a person wrote shows Written by or Imported by,
and never Unverified. Stale and Superseded can apply to either. In both modes every doc answers
questions as soon as it is saved, and a change that waits in Review never appears in answers.

Three properties carry the same weight.

1. **Plain Markdown is the ground truth**, so a team can leave whenever it wants and take a directory
   of files with it. Portability is why a team can trust a record whose source it cannot read.
2. **A budgeted retrieval contract.** One `recall` returns a ranked, deduplicated ContextPack inside
   a token budget, with the gaps named. Seven tools, and the tool-definition footprint is published.
   That answers the strongest criticism of the category, which is that an agent reloading a whole
   store costs more than it saves.
3. **Editing a non-technical teammate will actually use.** A simple Markdown editor, in the browser,
   over the same corpus the agents read. Without it, half the team knowledge stays out.

## 4. Who it is for

- **The solo technical founder.** Several projects in parallel, agent-driven work. "When I return to
  a project I paused, help me and my agent reload the state in under two minutes."
- **The three to fifteen person engineering team.** Several engineers, several AI tools, decisions
  trapped in individual sessions. "When a teammate decides something at 2am, my morning session
  should already know."
- **The agency.** Many client projects, and each needs isolation and a clean handover. One
  organization per client.
- **The non-technical teammate.** Operations, product, design. This person will not use a command
  line, and the editor exists for this person.

The signal that matters: does a developer who signs up invite a non-technical colleague? That tests
the whole thesis. If the answer is no, the editor was the wrong investment.

## 5. What kmem is not

- **It is not a workspace with a chat window bolted on.** Those products treat retrieval as an
  afterthought, because they were designed for a person reading a page.
- **It is not a memory SDK for an agent framework.** That is a different buyer.
- **A customer does not run kmem.** The kmem team provisions and operates every deployment. There is
  nothing to install and nothing to operate.
- **The code is private.** Whether any of it becomes public later is the owner's decision, and it is
  not scheduled.

The trust that reading the code would buy has to come from somewhere else, and the product already
carries the material: Markdown a team can export byte for byte at any time, provenance on every
block, a review queue between an agent and the record, tenant isolation in which a note outside the
organization appears in no response at all, and a published tool footprint with a retrieval eval
behind it.

## 6. Pricing

**Paid and hosted. Pricing soon.** The tiers are not decided, and this document will not guess at
them. The owner sets the price before launch. Two facts constrain that decision. The infrastructure
behind one organization grows with inference calls and with editing hours rather than with seats, so
a team that lives in the editor costs more than a team that reads over MCP. And distillation for a
connector processes roughly a hundred times the tokens that retrieval does, so it needs its own meter
and a hard per-plan cap.

## 7. Risks

| Risk | Response |
| --- | --- |
| Retrieval quality is mediocre | The eval set and its gate. Measure before building on top |
| Editor scope grows without limit | A hard cap: Markdown editing, and no formulas or rollups |
| Markdown round-trip fidelity fails | The parser preserves the source. The round trip is an invariant |
| A model vendor ships native team memory | Cross-vendor neutrality and byte-for-byte export |
| A leaked connection link | A short expiry, a read-only default, a rate limit, one-click revocation |
| Review fatigue turns the queue into a chore | Measure the acceptance rate before changing the default |