Build an AI Knowledge Base Without RAG: The Markdown Second-Brain (and Codebase Memory) Approach

The problem

Most teams have knowledge scattered across Google Docs, Notion pages, call transcripts, Slack threads, and large or legacy codebases. Chat context is ephemeral, so AI agents forget what they were told and answer from stale or missing information. The default fix, retrieval-augmented generation (RAG), forces you to stand up an embeddings model, a vector database, and a chunking pipeline before you can ask a single question, and it still retrieves imprecise fragments that miss how documents relate to each other. For an SMB or agency that just wants a reliable internal knowledge base or an executive second brain, and for a developer who wants Claude Code or Cursor to actually understand a large codebase, that is heavy, expensive, and slow to maintain.

Who it's for

SMBs and agencies that want an internal knowledge base or executive second brain without standing up a vector database, and developers working in large or legacy codebases who want Claude Code, Cursor, or another coding agent to have durable, accurate context on the whole repo. It fits any team that produces a lot of documents, transcripts, or code but loses that knowledge to ephemeral chat sessions.

How it works

1. 1

   Define the structure: create a raw/ folder for source material, a wiki/ folder for the linked output, and a CLAUDE.md (or AGENTS.md) schema file that tells the agent the naming convention, link style, and index format to follow. For a codebase, point Graphify at the repo root instead.

2. 2

   Ingest the source: drop docs, exported transcripts, and notes into raw/, or use Obsidian Web Clipper to capture articles. For code, run Graphify to parse the codebase into a knowledge graph of files, functions, and their relationships.

3. 3

   Chunk into a linked wiki: have the agent (Claude Code) read each raw source, split it into atomic markdown pages, add [[wiki-links]] between related pages, and write or update a single index.md plus a running change log so the whole library is navigable.

4. 4

   Unify into a second brain (optional): merge the wiki pages and the Graphify graph output into one Obsidian vault so you get backlinks, graph view, and a single searchable knowledge surface for exec or team use.

5. 5

   Query it: ask questions in Claude Code with the wiki folder in context, or point an executive-assistant agent at the wiki path so it reads the index first and follows links to the relevant pages instead of searching embeddings.

6. 6

   Maintain it: run periodic lint or health checks that flag orphan pages, broken links, stale sections, and coverage gaps, then suggest which new sources to add so the knowledge base stays current.

Tools

The result

You get a self-contained, version-controllable knowledge base of plain markdown files (and, for code, a navigable knowledge graph) that an AI agent reads directly, with no embeddings model, vector database, or chunking infrastructure to run or pay for. Because the agent navigates an index and follows links to only the relevant pages rather than retrieving similarity-matched fragments, answers tend to be more precise and the team avoids RAG's setup and maintenance overhead. Practitioners report large token savings versus loading or retrieving everything, though the exact figure is scale-dependent and works best at smaller scale (roughly under a few hundred documents, or sub-60-file codebases) where the whole index and linked structure stay manageable; very large corpora may still benefit from retrieval. The knowledge becomes durable and auditable instead of ephemeral, and a developer's coding agent gains stable context on a large or legacy repo.