AI Memory for Writers: What Survives the Round Trip

codebase-memory-mcp supports 162 languages. Every one of them is a programming language. Graphify’s headline capability table lists the edges it resolves: calls, imports, inherits, mixes_in. mem0’s README lists its use cases as customer support and healthcare.

I read all three on 3 September 2026, and none of them mentions a manuscript, a draft, or a house style.

That is the honest starting point for anyone searching for an AI memory system for writing.

This category was built for code, by people solving a code problem, and the parts of it that work for prose work by accident.

There is exactly one project I could find that was built for prose on purpose, and it is a skill file with 66 stars and no release.

What a writer actually needs remembered

Before picking a tool it is worth writing down what the memory is for, because the answer is different from a developer’s answer and every tool in this field is optimised for the developer’s answer.

The six things a writer needs held

A developer wants to know what calls what. A writer, across sessions, needs the model to hold:

• Spellings and names as decided. Not approximately. The character is Elara, not Elera, and the company is styled lowercase.
• Facts already established in published text. Once it is on the page it is load-bearing, and contradicting it is a rewrite.
• What is still open. The setup you planted in chapter three and have not paid off.
• Who knows what, and when they learned it. This is the single hardest thing to hold in your own head across a long piece.
• Voice decisions and their reasons. We do not use semicolons here. We cut that metaphor because it was in the last piece.
• What was cut, and why. Otherwise you rewrite the same rejected paragraph three months later.

Mapping the six onto the four

Look at that list against the four things memory systems return, which I sorted in the piece on choosing a memory layer by retrieval unit.

Items one, five and six are ruined by summarisation, because the wording is the content. Items three and four are relationship questions, which is where a graph helps. Item two is a lookup.

No single retrieval strategy covers all six, which is why the answer here is two tools rather than one.

The rule that eliminates most of the field: does it store what you wrote

What a summariser does to your sentence

Here is the mechanism, and it is the whole decision. mem0’s README states that it requires a language model to function, with gpt-5-mini as the default. The write path sends your text to that model and stores what the model produced.

Supermemory’s README says the same thing in marketing form: it automatically extracts memories and builds user profiles. For a developer, that compression is a feature.

Your sentence about a retry policy becomes the fact ‘retries are capped at three’ and nothing of value is lost.

Why that is destruction for prose

For a writer it is destruction. You told it your protagonist speaks in short, clipped sentences because she is a lawyer who was trained never to give more than the question asked for.

What comes back three sessions later is ‘protagonist speaks tersely’.

The reason is gone, so the model cannot apply it to a case you did not anticipate, and the phrasing is gone, so you cannot lift your own line back out.

The one that promises the opposite

MemPalace is the one project whose README makes the opposite promise in plain words: it stores conversation history as verbatim text and retrieves it with semantic search, and it does not summarise, extract or paraphrase.

Read on 3 September 2026, MIT licence, 58,808 stars, last release v3.9.0 on 31 August 2026. That is the property to filter on. Not benchmark scores. Whether the sentence survives the round trip.

The two setups that work without running a database

Basic Memory: your notes are the memory

basicmachines-co/basic-memory, 3,841 stars, AGPL-3.0, last release v0.23.2 on 25 August 2026. Its README describes the storage as plain Markdown files on your disk plus a local SQLite index, with no servers required.

No server, no port

SQLite is a file, so nothing is listening on a port and nothing needs restarting.

The format is small enough to hold in your head, which for a writer is the entire point:

---
title: Elara Venn
type: note
permalink: elara-venn
tags: [character, book-two]
---

## Observations
- [voice] Short, clipped sentences under stress

## Relations
- works_with [[Corvin Hale]]

Three things that follow from files

Three things follow from files being the unit.

You can correct a wrong memory by editing a line, which no summariser lets you do.

You can read the whole memory without an agent, in any editor.

And the README states that Obsidian needs no setup at all: point it at the project folder and the same wikilinks and frontmatter show up in its graph view, so the writer-facing tool you probably already use becomes the inspection interface.

Semantic search is off by default

Semantic search is available and off by default. The README documents hybrid full-text plus vector ranking with FastEmbed embeddings on SQLite or Postgres, and an optional local cross-encoder reranker, defaulting to jinaai/jina-reranker-v1-tiny-en, behind two environment variables:

Two environment variables switch it on: BASIC_MEMORY_SEMANTIC_SEARCH_ENABLED=true and BASIC_MEMORY_RERANKER_ENABLED=true.

Leave both off to start. Title and text search over a few hundred notes is fast and predictable, and predictable is what you want when you are checking whether a name has been used.

graphify-novel: the only one built for prose

Anshler/graphify-novel. 66 stars, MIT, last commit 16 April 2026, no published release, and the whole product is a 25,512-byte SKILL.md plus a README.

All of that is from the GitHub API and the repository contents endpoint on 3 September 2026.

I am telling you the size and the date because you should calibrate on them: this is one person’s skill file, not a maintained product.

It is also, as far as I can find, the only thing in this category designed around a manuscript.

What it actually does

It scaffolds a story bible from a premise, reviews a draft against that bible for contradictions and unresolved setups, and updates character and thread files after you write. The structure it imposes:

/
  chapters/          finished manuscript files
  draft/             work in progress, excluded from the graph
  static/            excluded from the graph
  bible/
    premise.md
    timeline.md
    characters/
    threads/
    world/
  graphify-out/      generated knowledge graph
  .graphifyignore

# from the graphify-novel README, read 3 September 2026

The commands that matter for the six needs listed earlier are status, which reports open threads, character states and unresolved setups,

and query and path, which trace how two story elements connect across the full manuscript.

Those are relationship questions, and they are the ones a flat notes file answers badly.

Two honest caveats

Two honest caveats. First, it runs on top of the Graphify skill, which is a separate install, and the README links Graphify at github.com/safishamsi/graphify.

That URL redirects: following it through the GitHub API on 3 September 2026 lands on Graphify-Labs/graphify. The link works, it is just not the current name.

I compared Graphify against its nearest rival in the codebase-memory-mcp and Graphify comparison.

Second, and this is stated by the author rather than discovered by me: if you already have a bible or story-tracking structure, it will not be compatible.

You move it outside the project and retrofit it after initialising. For a manuscript already in progress that is a real afternoon of work.

What does not work, and why

Anything that needs a graph database

Anything that requires a graph database. Graphiti’s README lists Neo4j 5.26, FalkorDB 1.1.2 or Amazon Neptune as requirements, and marks the embedded Kuzu driver deprecated because the upstream project is no longer maintained.

Its temporal model is genuinely well suited to fiction, since ‘this was true until chapter nine’ is exactly a validity window.

It is still a database you have to keep running to write a novel, and that is the setup that quietly stops being running in March.

Khoj, the near-miss

Khoj is the interesting near-miss, because it is aimed at documents rather than code: 37,013 stars, AGPL-3.0, self-hostable by design.

But its own docker-compose.yml, which I pulled from the master branch on 3 September 2026, brings up pgvector/pgvector:pg15, a SearXNG container and a sandbox container before you index anything.

Also worth knowing before you commit: its last published GitHub release is 2.0.0-beta.28, dated 26 March 2026, while the repository was pushed to on 2 August 2026. Active development, no shipped release in five months.

Code-graph tools pointed at prose

Code-graph tools pointed at prose. They will run. Graphify will map your Markdown, and its own capability table says docs, PDFs, images and video all map into the same graph.

What it also says is that the code pass is local and deterministic while the semantic pass over documents uses your assistant’s model or a configured API key.

So for a writer, the free deterministic part is the part you do not need, and the part you do need is the metered one. Know that before you assume the zero-credit claim applies to you.

Relying on chat history. Basic Memory’s README puts the reason well: chat history captures conversations but is not structured knowledge. A transcript contains the decision and also contains the three wrong ideas you had before it, with nothing marking which is which.

The setup I would actually run

Basic Memory for the six needs list, because the unit is a file you can fix, and it needs no server.

Add graphify-novel on top only if you are working on something long enough that thread tracking is a real problem, and only after reading its SKILL.md, because at 25 KB you can read the entire product in fifteen minutes and know exactly what it does.

If you want your raw session transcripts searchable as well, MemPalace alongside it, specifically because it does not paraphrase. Two systems, one for curated notes and one for the raw record, is a better shape than one system trying to be both.

If you are weighing whether any of this needs to be self-hosted at all, the running costs are in the self-hosted memory cost breakdown, the storage backends and licences per project are in the platform comparison table, and the whole cluster sits under the AI memory tools comparison.

One thing to do in the next ten minutes: open the memory tool you are using, save one sentence containing a phrase you would recognise, and search it back.

If you get your sentence, you have a system a writer can use. If you get a tidy summary of your sentence, you have a system that will lose your voice one paragraph at a time.

Resources

• Basic Memory on GitHub – Markdown entity format and local install
• Basic Memory knowledge format docs – observations, categories and relations in full
• graphify-novel on GitHub – the story bible skill, README and SKILL.md
• MemPalace on GitHub – the verbatim storage claim and backend table
• MemPalace: the palace concept – how wings, rooms and drawers scope a search
• Khoj on GitHub – and its docker-compose.yml if you want to see the stack first
• Obsidian – reads the same Markdown Basic Memory writes, with no configuration