Building a Second Brain Knowledge Base

A knowledge base that can function as a second brain can be very useful for research and development. The exact setup depends on the scope and objectives. The most typical setup for organizations is to use Notion or custom-built repositories that support database queries and collaborative work. Individuals prefer to use tools like Obsidian or even simple notes or files organized in folders. 

Whatever your preferred setup is, one of the main objectives is the ability to get an overview, extract relevant knowledge, and generate interesting insights. This is where LLMs become very useful, but in order for them to work well, they need to be combined with a scaffold that provides a framework and infrastructure for memory and reasoning. Otherwise, every time you use Claude, it will start from the beginning and lack the context. 

InfraNodus can be very useful for adding this additional layer in the shape of a knowledge graph. The knowledge graph can be used to improve the model's understanding of the context because it summarizes the relations between different concepts and lets the model traverse the graph in order to find better responses. Some other frameworks, such as Graphify, use a similar knowledge graph approach but lack InfraNodus' graph analytics and gap detection capabilities. 

Additional setups, such as LLM Wiki proposed by Andrej Karpathy, can be used to build an extra layer of infrastructure on top of your existing knowledge base to enable a model to have additional understanding of the main concepts, projects, and relations between them. It can be combined with the InfraNodus knowledge graph in order to let the model have both a structural overview of the context as well as the graph traversal capabilities.

In this article, we will propose how a second brain knowledge base can be set up without any programming knowledge. We will then show how it can then be maintained and queried using LLMs and additional tools. 

Step 1: Setting Up a Knowledge Base

The most typical setup for a knowledge base is to have files with content organized into folders. You can use PDFs as your raw material, but it also makes sense to convert them to Markdown (MD) format, which maintains formatting but is available in plain text form, which will make it faster for LLMs to process it. 

The folder structure should not be too complex to avoid additional cognitive load deciding where to add the new files. Therefore it may sometimes be useful to add a general "Incoming" folder and additional incoming folders into each category as well as to establish a regular practice of sorting the incoming folder to keep it more or less empty. We recommend to create one single vault with all your knowledge at one place. However, if the domains you work with are too diverse, it may then make sense to create additional sub-knowledge bases that would be focused on specific areas of inquiry.

Version control (ran with a tool like Git) can be very useful as well because it will allow you to maintain local control of how your knowledge base evolved and revert it to any previous state or even fork it into several different versions if you'd like to explore certain aspects or experiment with various structural setups. 

You would also need an interface to view and organize the files. Many people like to use Obsidian for it (see the screenshot below), because it is local and has a very useful capability to show connections between the notes that you link using the [[wikilink]] syntax. Therefore you can manually curate how your files or ideas relate to one another, which can be very useful for adding a rhizomatic network layer of coherency that goes beyond the simple hierarchical folder organization. Other alternatives include Cursor (which is an IDE for software development, but has a Markdown / PDF file viewer) and if you are happy to store your data on the cloud, you can also use Notion or InfraNodus for that.

Finally, you might want to make your knowledge base accessible to an LLM of your choice. If your knowledge base is inside InfraNodus or Notion, you can use the built-in AI to query the specific documents. If your knowledge base is on your local folder, you can use Claude or OpenAI's Codex via the Terminal command line or using their desktop apps. Both offer the (co)work mode where you can point them at the folder to ask questions, but we recommend to use their Code tools (Claude code in the desktop app or directly via the Terminal), as functionalities there are much better and allow for additional tool use (this may become important later)

The basic setup therefore would include the files that are tagged or organized into a folder structure as well as the content viewer / navigator. You can choose to add Git version control additionally for backup and observability purposes. Additionally, you can then point your LLM (like Claude) to this folder to start asking questions about it)

Tools required: Obsidian or Cursor for local KBs, Notion or InfraNodus for cloud-based KBs, optionally: Git (with an additional private GitHub repo to back up to the clloud), InfraNodus or Claude for LLM queries

Steps: Put all your source materials and notes into a folder, organize them without getting into too much detail about the organization at first

Our Demo Setup: Claude Code documentation

For the sake of the demonstration, we will use Claude Code's documentation. We will use a custom script to create a vault of markdown files from these documents. This vault will have the same folder structure as original documentation site but all the content will be on our local hard drive as markdown files.

We then open the vault in an IDE (an advanced text editor for coding) like Cursor AI or VSCode. The reason we use Cursor AI is because it can be used to navigate the file structure but it is also highly customizeable. We can add the InfraNodus graph view plugin to visualize the content of the repository, and open Claude Code in terminal to use AI on it. Cursor has its own AI agent on top, which makes it possible to run several AI workflows at once. 

We can also open this knowledge base in Obsidian, however, Obsidian only shows MD files, has worse code formatting, and its AI capabilities are very limited.

Step 2: Adding a Semantic Layer to Your Knowledge Base

Once the knowledge base is created, you can already start using it with a file viewer or using an LLM inside. The problem here, however, is that you will have a lot of disjointed bits and pieces of information and just like it's going to be hard for you to make sense of the relations between them, your LLM will also struggle to produce truly interesting insights. 

The reason is that by default your LLM will use vector-based search (RAG) in order to extract the most similar statements to your query from your whole knowledge base (forming a context) and then use this context to provide the response. However, insights are often located in gaps or require multi-hop reasoning (sometimes across non-obvious paths), so the results your LLM will produce will be great for getting a general overview but not so good for generating new ideas or identifying interesting gaps in research.

While most LLMs today have powerful harnesses that address this problem, they obviously do not reveal how they're made to have a leading edge over other models. However this opacity also completely removes observability and control, so you can rarely clearly see what's happening under the hood. 

That's why you may be interested to add your own semantic layer on top: to be able to see what's happening under the hood and also better control the reasoning process of the model. Adding your own layer also lets you better understand how your knowledge is structured and have always-on high-level overview of your ideas. 

During the last months, several proposals have come out to help people build this semantic layer. The most popular one at the moment is the LLM Wiki setup proposed by a prominent AI research Andrej Karpathy. This approach can further be extended by adding a layer of knowledge graphs and / or using GraphRAG retrieval system that will have a more contextual representation of information in the knowledge base.

Advanced workflows include creating a custom ontology combined with a database layer, which then lets the model produce very precise responses (this is for instance used in enterprise grade tools provided by Palantir). 

For personal use, adding an LLM Wiki / knowledge graph layer can be sufficient, because it can be used both by humans and machines to have a better overview of the content, provide additional reasoning paths and structure for identifying and bridging the gaps. At the same time, it's not as complex and lengthy to set up as a proper database-driven ontology (which would probably be an overkill for a small organization or individual use). 

Our Demo Setup: Using InfraNodus to Create a Semantic Layer

In our demo setup, we will use the InfraNodus skill to create a semantic layer in the shape of InfraNodus-hosted knowledge graph on top of the Claude Code wiki.

In order to do that, we need to

1. install the InfraNodus skill and connect the InfraNodus MCP server to your Claude
2. open the vault in Cursor, then 2
3. open Terminal
4. launch Claude inside: claude (you may need to install Claude Code before via Anthropic)
5. then inside claude as the InfraNodus skill is already installed, type in /infranodus 
6. the infranodus skill will take you through the questionnaire - we recommend to start with analyzing a folder (e.g. 01-getting-started with the basic concepts of Claude Code)
7. the skill will create the infranodus folder in your vault with the manifest.json file that will describe the knowledge graphs generated for your vault. It will also produce a report file with the main findings (topics, gaps, ideas to develop the text further).
8. because you connected the MCP server, InfraNodus will make the graph analysis and insight generation tools available to your Claude model

FAQ: Choosing a Knowledge Graph vs an LLM Wiki

The most advanced setup would combine an LLM Wiki with a knowledge graph, however, it is often not necessary to mix the two. Whether you want to use one or the other or combine them both really depends on your objectives and the level of complexity you're able to handle, especially in maintaining the knowledge base. 

Option 1: Using a Knowledge Graph for Your Second Brain

A knowledge graph is a very useful layer because it can actually be quite easy to set up and maintain. When used correctly, it can provide a reasoning map for your AI to hop across the graph nodes and edges and provide richer context to the model to generate better responses. 

The basic setup can be achieved using InfraNodus where you use the InfraNodus skill to generate knowledge graphs for specific folders of your repository. The skill will write down the names of the graphs generated for each folder in a special manifest.json file and add instructions for your AI to use that file when answering questions related to that content. 

When asked a question about a certain aspect of knowledge present in your knowledge base, Claude will consult the CLAUDE.md file which contains instructions to use the infranodus skills where it can be useful to extract an answer from a relevant graph based on the query. Under the hood, InfraNodus uses a powerful GraphRAG algorithm which creates an enriched context based on your query that is based not only related statements but also on graph traversal results. Meaning that when you ask about, for instance, a question that relates to the topic "A", it will look not only for the content that mentions "A", but also the relations inside your repo that connect that topic to "B" and then connections that topic "B" has to topics "C" and "D". 

Additionally, InfraNodus focuses on the gaps in your knowledge base. So if you ask a question about a certain topic, it will provide a response that does not only address the question but also attempts to find and bridge a structural gap in related context. This leads to better insights and allows to resurface less obvious latent ideas that can lead to research breakthroughs. 

You can also build a knowledge graph using other tools, such as Graphify or Neo4J. In the case of Graphify, its parser will create local graphs for your repo and then its python script will traverse the graph to provide additional context to your LLM. In our experience, Graphify is a bit aggressive pushing its tool use ahead of the model's own, but it can be interesting to use in some instances where you'd like to get a second opinion in addition to the model's default output. 

Option 2: Building an LLM Wiki for Your Second Brain

Another approach is to build an additional layer of LLM Wiki on top of your knowledge brain. As the name suggests, it is basically a wiki for your LLM — a structured representation of data in your vault that will be used by your AI for additional context. So instead of retrieving the context directly from your files, it will have a structured understanding of the main ideas inside as well as relations between them and enhance the responses with this additional data. 

While there are many different ways to set up an LLM Wiki, the most popular way is to use Andrej Karpathy's approach (via an LLM wiki skill) where you instruct your LLM to create a structure that lists the main concepts and relations between them inside your vault in special folders. Your source data is stored in the "raw" folder, while the content generated by the LLM wiki skill is stored in specific folders which will then be queried by the model. 

As you can see, the LLM Wiki approach creates an additional layer of machine-generated content in your vault, so we recommend not to apply it to your main documents folder. Instead, you can create another folder where you copy all the documents on a certain topic (manually or using an LLM) and then run the LLM Wiki skill there in order to not pollute your original repository with machine content. Then you work just in that folder and integrate the insights you obtained in your main vault when needed. 

Option 3: Combining an LLM Wiki with a Knowledge Graph

It is also possible to combine an LLM Wiki with a knowledge graph. In this setup, you have a machine-generated LLM Wiki layer (in plain text files), which adds a semantic layer over a portion of your content (as we recommend in the Option 2). If you use the InfraNodus LLM Wiki skill, it will also generate knowledge graphs based on that content. The skill can then refer to those graphs in order to get the additional graph insights (as described in the Option 1) for the particular queries where they could be useful. 

Step 3: Getting Insights from Your Knowledge Base

Now that we talked about the different ways to set up a knowledge base, let's see a practical example of how we can set one up and then use it to generate insights.

We can use the model itself or the built-in graph view extension. The model can be useful for asking specific questions while the graph view extension can be useful for finding what questions to ask.

We can use the setup we created both for getting the responses from the knowledge base as well as understanding its structure and finding blind spots and areas where it could be better developed. 

RAG vs LLM Wiki vs Knowledge Graph

Let's first see how the model responds to the questions based on the different types of setup we outlined above. 

At the moment, we have:

• A vault of complete Claude Code documentation in markdown format
• We have it opened in Cursor AI with the InfraNodus Graph view plugin
• We also have Claude Code connected to it, so we can ask questions to the repo
• We have the InfraNodus MCP server and skills connected to Claude, so we can use additional knowledge graph analysis tools to extract insights about the repo
• We generated a knowledge graph from the "Getting Started" folder of the documentation (in Step  2) and will now query it for insights. 
• Alternatively, we have the LLM Wiki setup where there is a separate wiki folder with structured information about the repo (if we used the LLM wiki skill from InfraNodus)

Now when we ask a question to the knowledge base using one of the AI tools (e.g. "Tell me more about prompt cachine"), the response can be produced in the following ways:

Here's a screenshot of the model's reasoning flow in the LLM Wiki mode. As you can see, it first addresses the index.md file in the wiki folder generated by the skill, then it reads the concepts and log, finds the correct file with the knowledge, then uses it to provide the response.

Using the Knowledge Graph View to Get Insights

Another way to generate insights is to use the InfraNodus knowledge graph view plugin (either in Cursor AI or Obsidian) to visualize the content of a specific folder / file or the whole repo. The graph helps us have a better contextual understanding of the knowledge base, so that we know what questions to ask and also can optimize the knowledge base itself with new information and input. Specifically, it enables us to:

• Get a topical overview of the content
• Use the topical clusters to zoom into the specific aspects of content
• Understand what the main content gaps between the topical clusters are
• Focus on gaps to find questions that would link the topical clusters
• Reveal the less represented topics to develop the discourse further

In our example, we right click on the "Getting Started" folder and ask Cursor AI to visualize the content of this folder using the InfraNodus graph view extension. 

We see the graph on the right, which highlights a triad of topical clusters that are not very well developed: Memory tools, Context caching, Project styles. Then we can:

1. use AI: Generate a Question button to 
2. generate a research question inside the extension itself. 
3. we can then feed it to Claude Code in Terminal 
4. Claude uses the knowledge graph to provide a response

The model provides a response that talks about the importance of using files with model instructions, such as CLAUDE.md or STYLE.md, to help the LLM agents maintain context and not only rely on prompt caching, which may be reset with model changes or session reloads:

"Style consistency survives session history, model/mode switches, and compaction only if the style lives in the file-encoded prefix layer — the CLAUDE.md hierarchy, agent definitions, and memory files — never in conversation turns. The design has three parts: encode each level as a stable file ordered by volatility, route it to subagents through their definition files plus the delegation prompt, and treat every in-chat style correction as a pending file edit."

As you can see, this sort of response can be used both to better understand the content or to develop the product. We identified underrepresented topical clusters and asked the model to connect them in an interesting way.