What is kmem

Who it is for

kmem is for a team whose knowledge is already written down in Markdown, and whose agents need to read it. A support team keeps a handoff doc. A platform team keeps runbooks and decision records. An engineer keeps an AGENTS.md that tells a coding agent how the repository works. Each of these is a file, and each of them goes stale the moment the work moves on.

The second reader is the agent. A coding assistant, a chat client and a retrieval tool all answer better when they read the team's own words instead of guessing. Today that means somebody pastes a document into a prompt, and the paste is out of date the next week. kmem removes the paste: the agent reads the doc from one place, and the team keeps that place correct.

How it works

You create an org. The org holds your docs, your review queue and your connections. You then bring the knowledge you already have: upload Markdown files or a zip, connect an agent that writes docs for you, or write the first doc in the editor.

Every doc is a Markdown file. kmem parses it into blocks, embeds each block, and indexes the result so that a question finds the paragraphs that answer it rather than the whole document. The file stays the ground truth. If everything else went away, the Markdown would still be readable in any editor.

A person reads a doc in Docs, or asks a question in Ask and gets a short answer with the docs it rests on. An agent reads the same docs through MCP or through a connection document. Both readers see the same text, because there is only one copy of it.

What review means

An agent may write to your docs, and this is the part most teams are careful about. kmem splits the two cases that matter. A new doc at an address nothing uses lands in Docs, because it takes nothing away. A change to a doc that already exists waits in Review for a person.

A change in Review shows the proposed text, the lines it adds or removes, and the reason the agent gave for it. You accept it, reject it, or keep both versions as separate docs. Acceptance records who decided. Verification is a separate act and records who checked the content of the current version.

This is why a doc in kmem carries a word about its origin rather than a score. A doc a person wrote says who wrote it. A doc a person uploaded says who uploaded it. A doc an agent proposed says that a person accepted it, or that nobody has. A reader can tell those apart at a glance, and so can an agent.

What an agent sees

An agent connects in one of two ways, and you choose which.

The first is MCP. kmem runs an MCP server for your org. An agent that speaks MCP gets tools with plain names: recall, to find the paragraphs that answer a question; remember, to write something down; and the read tools for a doc and its history. The agent's connection decides what it may read, and every write to an existing doc goes to Review.

The second is a connection document. It is an AGENTS.md or a SKILLS.md file that you give to a client that reads one. The document tells the agent what your org holds, how to ask it a question, and how to write something down. It carries a link, so a client with no MCP support can still read your docs.

What kmem is not

kmem is not a chat application. There is no message history to search and no channel to keep up with. A conversation is where knowledge is produced; it is a poor place to keep it.

kmem is not a wiki with a chat box attached. The retrieval is the product, and it is measured: the question is whether a recall returns the right three paragraphs inside a token budget, not whether a sidebar is pretty.

kmem is not a document store your agents cannot reach, and it is not an agent toy your team cannot read. Both readers are first class, and the same review queue protects the docs from both.