Most people are waiting for AI tools to remember them.
I think that is backwards.
You should own the context.
This walkthrough shows how to set up the open-source RA-H graph: a local SQLite-backed knowledge base that your agents can read from and write back to through MCP.
The promise
The practical promise is simple:
Clone the repo, install the app, create a local database, connect your coding agent, and give it a durable context layer.
That context layer is not hidden inside ChatGPT memory or Claude Projects. It is a SQLite database on your machine. You can inspect it. You can copy it. You can query it. You can delete it.
And because it exposes MCP tools, external agents like Claude Code, Codex, Cursor, or OpenCode can interact with it directly.
They can search your graph, retrieve relevant nodes, inspect long source chunks, create new nodes, and connect ideas with edges.
That is the difference between a passive note store and an agent-readable memory system.
Two setup paths
There are two ways to use RA-H.
The Mac app is the easiest path. Download it, open it, and use the interface.
The open-source repo is the builder path. Clone it, bring your own keys, run it locally, and modify it however you want.
The OS walkthrough is mostly for the second path. It shows the full structure: the repo, the local database, the web app, the MCP server, and the way agents interact with the graph.
If you are using a coding agent already, you can ask it to do most of the setup. That is one of the nice things about this moment. Running open-source software is less scary when you can point an agent at the README and let it handle the boring parts.
What the database actually stores
The graph is built around nodes and edges.
A node is an atomic unit of context: a source, idea, podcast, article, person, project, insight, or decision.
Each node should have a clear title, explicit description, and useful source. If the source is long, like a podcast transcript, it can be chunked and embedded so the agent can search inside it.
An edge connects two nodes and explains why the relationship exists.
That last bit is important. A connection is not just a backlink. It should carry meaning. "This insight came from that podcast." "This project depends on that decision." "This idea contradicts that earlier assumption."
The more you use the graph, the more useful those relationships become.
Why MCP matters
MCP is the bridge between your agents and the database.
When the MCP server is installed, your agent gets tools for working with the graph. It can search nodes. It can retrieve context. It can create nodes. It can create edges.
In the video, I add source material, ask the agent to find recently created nodes, search inside a transcript, create a new insight node, and link it back to the source material.
That is the loop I care about:
- Add source material.
- Ask questions against it.
- Turn useful answers into durable context.
- Link that context back to the source.
This is how the graph compounds.
The agent should not guess
One of the underrated benefits of a real graph is that it gives the agent a place to check itself.
If the database does not contain the relevant context, the agent should say that. It should not invent a story because it found something vaguely related in a folder.
In the walkthrough, there is a moment where the agent has only a few demo nodes. I ask a question that would require more of my real graph. The agent cannot answer fully because the context is not there.
That is good behavior.
A useful memory system is not one that hallucinates confidence. It is one that makes the available context explicit.
Why this got traction
The soft relaunch of this setup video produced a useful signal.
The YouTube video performed above the channel's normal early baseline. Reddit discussion, especially in r/ClaudeCode, generated practical builder questions: one database or many, how media should be handled, how this compares with markdown folders, how sync should work, and how to keep entries true as the underlying subject evolves.
That is exactly the conversation I wanted.
The winning angle was not vague "AI memory." It was the practical setup story: local SQLite, MCP, explicit nodes, source, edges, and agents that can read/write a context layer you own.
No folders, tags, or buckets first
RA-H has gone back and forth on organization layers.
The current direction is much stricter: the quality of the node matters more than categories.
When you add something, make the title and description clear. Preserve the source. Create edges that explain meaningful relationships.
Do that well and the graph becomes useful. Do it badly and no folder structure saves you.
That is why I keep saying "atomic units of context." A node should be small enough to retrieve and reason about, but rich enough that the model understands what it is.
Start here
If you want the easiest path, use the Mac app.
If you want to build or modify the system yourself, use the open-source repo.
If you want the older long walkthrough, read Build Your Own Knowledge Base. If you want the philosophical version of the argument, read Don't Build a Second Brain. Build a Database..
The setup is not the hard part.
The hard part is building the habit: continually add useful source, create explicit nodes, connect ideas, and make your agents write back when something important happens.
That is how you build AI memory you actually own.