Every agent session starts with amnesia. You explain the project, the conventions, the decision you made last Tuesday. The agent does good work, the session ends, and the next one starts from zero. Switch from Claude to Cursor to ChatGPT and you do it again, three times over.
I got tired of pasting the same context into every chat, so I built Korpus: one space where humans and their agents read and write the same memory. And I built it MCP-first. The MCP server is the main interface, the web app is a second client on the same documents.
Most tools get an MCP server bolted onto an API that was designed for humans clicking buttons. MCP-first turns that around: you design the tools for the caller that uses them most, an agent with a limited context window and no memory of its last session.
This post is partly a show-and-tell and partly the list of design decisions that came out of that. If you are building an MCP server yourself, the second half is for you.
The model in 30 seconds
- Bundle: a folder of memory for one subject, private or shared.
-
Concept: a markdown document at a path like
auth/token-expiry, with a type, tags and a revision counter. - Links: typed relations between concepts. Each bundle defines its own link kinds.
- README and AGENTS: two files at the bundle root. One tells people where to start, the other tells agents how to work there.
That is all of it. Plain markdown, named paths, no proprietary format to learn.
What MCP-first changed in the design
1. Enumerate first, search second
My first instinct was to give the agent a great search tool. In practice agents open with search, get a fuzzy top 10, and miss the document that was sitting at an obvious path.
So the server tells agents to call list_folder first. Paths are named on purpose, which makes enumeration exact, complete and cheap. Search is the fallback for when you do not know where something lives, or when you want a regex across a whole bundle.
2. Every write names the revision it was based on
Several agents and several humans edit the same documents. Last write wins is a quiet disaster in that setup. An update has to pass the rev it read, so nobody overwrites work they have never seen. Classic optimistic concurrency, and it turns out agents handle a conflict error well: they re-read, merge and retry.
3. A change description is mandatory
Every create, update and delete needs one line: what changed and why. That line is the log. Six weeks later, "why does this runbook say X" has an answer with an author on it, whether the author was a person or an agent.
4. Index and log are derived, never stored
Each folder has a generated index (titles and descriptions) and a log (the changes). They are computed from the content, so they cannot drift out of date, and an agent can orient itself in a folder with one cheap read.
5. One tool per action
No manage_concept(action=...) mega tool. list_*, read_* and search_* only look. create_*, update_* and delete_* change things. The client can let reads through without a prompt and ask the human before writes, and the agent picks the right tool more reliably.
6. An agent works for one person
Each agent has its own MCP endpoint and only the access its human grants it. A CI agent that writes findings into one folder does not get to read the rest of the bundle.
7. The server asks agents to write tersely
Every later session pays tokens for what an earlier one wrote. The server instructions tell agents to drop filler and keep the fact and the reason. Memory that is cheap to read gets read.
Trying it
Korpus is a remote MCP server with OAuth sign-in (passkey or emailed code). In Claude, search for Korpus under Settings → Connectors, or add a custom connector with this URL:
https://mcp.fra.korpus.cloud/mcp/me
In Claude Code:
claude mcp add --transport http korpus https://mcp.fra.korpus.cloud/mcp/me
Cursor, ChatGPT and CI jobs connect the same way, over MCP.
If you would rather start from something filled in than from an empty folder, the catalog has reviewed templates you can copy into your own account, for example:
- Project Memory for AI Coding Agents: project brief, architecture notes, numbered decision records, runbooks and session handoffs.
- Agent Kanban Board: cards, columns, owners and hand-off notes that agents read and update.
- Agent Skills Template: one shared set of steps and rules for every MCP-compatible assistant.
- Human Feedback Loop: turns your corrections into rules agents read on every run.
The boring facts
- Hosted in Frankfurt (eu-central-1).
- Free plan: 5 bundles, 500 MB, no card needed. Plus is €5 a month for more room. Every feature is on both plans, and agents never count as users.
- Running it in your own AWS account is possible on request.
I would like your feedback
Korpus is early. If you try it, I want to hear what breaks, which tool confused your agent, and what your own setup for agent memory looks like today. Markdown files in the repo? A vector store? Something else?
Tell me in the comments. I read all of them.
Top comments (0)