DEV Community

Cover image for Building an AI-native Second Brain with Multi-RAG, Knowledge Graphs, and MCP
Nishikanta Ray
Nishikanta Ray

Posted on

Building an AI-native Second Brain with Multi-RAG, Knowledge Graphs, and MCP

#ai #claude #rag #mcp

Claude is incredibly good at reasoning.

But reasoning is only as useful as the context available to it.

Your architecture might be in GitHub. Your notes might be in Obsidian. Your decisions might be buried in Slack. Your research might be in PDFs. Your project history might exist across hundreds of conversations.

The information exists.

The problem is that your AI doesn't have a unified way to understand it.

So I started thinking:

What if Claude had a persistent Second Brain?

Not another chatbot. Not another vector database.

A knowledge layer that Claude can query, learn from, and write back to.

What Is a Second Brain?

A Second Brain is a personal knowledge management system that helps you capture, organize, connect, and retrieve information outside your biological memory.

Tools like Obsidian made this idea powerful.

You can write simple Markdown notes and connect them:

InsightTrack
    │
    ├── [[DuckDB]]
    ├── [[PostgreSQL]]
    └── [[MCP]]
Enter fullscreen mode Exit fullscreen mode

Obsidian then creates a visual graph of those relationships.

But there is a limitation:

Obsidian knows the relationships you explicitly create.

AI can take this much further.

Imagine having:

architecture.md
      │
      └── mentions DuckDB

GitHub PR #481
      │
      └── changes DuckDB queries

Slack discussion
      │
      └── explains why DuckDB was selected

benchmark.md
      │
      └── contains performance results
Enter fullscreen mode Exit fullscreen mode

A human may never manually connect all four.

An AI-native knowledge system can discover those relationships automatically.

From Second Brain to AI Brain

A traditional Second Brain mainly answers:

"Where did I save this?"

An AI-native Second Brain should answer:

"What do we know about this, where did it come from, and how is it connected to everything else?"

That requires more than vector search.

It requires multiple retrieval strategies working together.

Why Traditional RAG Isn't Enough

A typical RAG architecture looks like:

Documents
    ↓
Chunking
    ↓
Embeddings
    ↓
Vector Search
    ↓
LLM
Enter fullscreen mode Exit fullscreen mode

This works extremely well for semantic similarity.

Ask:

"What was the reasoning behind our analytics architecture?"

Vector search can find relevant discussions even if the exact wording is different.

But now ask:

"Where is SYNC_BATCH_SIZE defined?"

That's an exact identifier.

Keyword search is better.

Or ask:

"What services depend on PostgreSQL?"

That's a relationship question.

A knowledge graph is better.

This is why I think a serious AI Second Brain needs Multi-RAG.

Multi-RAG: Different Questions Need Different Retrieval

Instead of relying on one retrieval technique:

Semantic Search
       +
Full-Text Search
       +
Knowledge Graph
       +
Metadata Filtering
       +
Reranking
Enter fullscreen mode Exit fullscreen mode

Each method solves a different problem.

Semantic RAG

Good for understanding concepts.

"Why did we choose DuckDB?"

Keyword RAG

Good for exact information.

"Find references to SYNC_BATCH_SIZE."

Graph RAG

Good for relationships.

"Which services depend on PostgreSQL?"

Memory Retrieval

Good for decisions and persistent context.

"What did we decide about the analytics architecture?"

Together, they provide much richer context than vector search alone.

The Architecture

[INSERT THE ARCHITECTURE DIAGRAM HERE]

The important idea isn't any individual component.

It's how the components work together.

Obsidian / Documents / External Sources
                │
                ▼
           Event Queue
                │
                ▼
        Processing Workers
          │      │      │
          ▼      ▼      ▼
       Metadata Embedding Graph
          │      │      │
          └──────┼──────┘
                 ▼
          Knowledge Layer
                 │
      ┌──────────┼──────────┐
      ▼          ▼          ▼
   Vector      Search      Graph
   Search      Index       Store
      │          │          │
      └──────────┼──────────┘
                 ▼
          Retrieval Engine
                 │
                 ▼
              MCP / API
                 │
                 ▼
          Claude / GPT / AI
Enter fullscreen mode Exit fullscreen mode

Obsidian Is the Human Interface

I don't see Obsidian as the entire Second Brain.

I see it as one of the best human-facing knowledge interfaces.

You can continue writing naturally:

# Analytics Architecture

InsightTrack uses [[DuckDB]] for analytical queries.

Data originates in [[PostgreSQL]].

See [[Pulse]] for the AI analytics layer.
Enter fullscreen mode Exit fullscreen mode

Obsidian gives you human-readable notes and a native graph.

The AI system adds another layer on top.

Two Graphs, Two Purposes

This architecture can maintain two different graphs.

Obsidian Graph

Created from explicit links:

[[InsightTrack]]
       │
       ▼
   [[DuckDB]]
       │
       ▼
  [[Analytics]]
Enter fullscreen mode Exit fullscreen mode

This is primarily useful for human navigation.

System Entity Graph

Automatically extracted from all available knowledge:

InsightTrack
      │
     USES
      │
   DuckDB
   /    \
READS   SYNCED_FROM
 /          \
Enter fullscreen mode Exit fullscreen mode

Pulse PostgreSQL

The system graph can be built from:

  • Markdown
  • Source code
  • Git commits
  • Pull requests
  • Database schemas
  • Documentation
  • Conversations
  • Meeting notes

This graph isn't just for visualization.

It becomes part of retrieval.

Knowledge Engineering + Graph Engineering

This is where the architecture becomes more interesting than a normal RAG application.

Knowledge Engineering turns raw information into structured knowledge.

Meeting Transcript
        ↓
     Summary
        ↓
   Action Items
        ↓
Architecture Decision
        ↓
   Project Memory
Enter fullscreen mode Exit fullscreen mode

Graph Engineering connects the resulting entities.

Project
   ↓
Repository
   ↓
  API
   ↓
Database
   ↓
Developer
   ↓
Decision
Enter fullscreen mode Exit fullscreen mode

The result isn't just a collection of documents.

It's a connected knowledge model.

The Retrieval Engine

The retrieval engine is arguably the most important part.

Suppose you ask:

Why did we move analytics queries from PostgreSQL to DuckDB?

The system might retrieve:

GitHub PR
      +
Architecture Note
      +
Benchmark
      +
Slack Discussion
      +
Decision Memory
Enter fullscreen mode Exit fullscreen mode

Then rerank and combine the results.

Instead of giving Claude thousands of chunks, the system builds a focused context:

Decision:
Use DuckDB for analytical workloads.

Evidence:
- Benchmarks showed better aggregation performance.
- PostgreSQL remains the transactional source of truth.
- The architecture PR implemented the separation.
- The Slack discussion explains the operational trade-offs.
Enter fullscreen mode Exit fullscreen mode

Now Claude is reasoning over evidence + relationships + memory.

Long-Term Memory

A Second Brain shouldn't remember everything.

Otherwise, it becomes another giant database.

It should remember what matters.

For example:

Decision
────────────────────
PostgreSQL remains the source of truth.

Decision
────────────────────
DuckDB handles analytical reads.

Reason
────────────────────
Better analytical performance and isolation.

Status
────────────────────
Implemented.
Enter fullscreen mode Exit fullscreen mode

This is much more valuable than storing thousands of raw conversations.

The system should distinguish between:

Raw Data
   ↓
Information
   ↓
Knowledge
   ↓
Memory
Enter fullscreen mode Exit fullscreen mode

That's an important part of making AI memory useful.

MCP Connects the Second Brain to Claude

This is where the architecture becomes AI-native.

Instead of building a custom integration directly into Claude, expose the Second Brain through MCP.

For example:

search()
retrieve()
remember()
ingest()
graph()
timeline()
Enter fullscreen mode Exit fullscreen mode

Claude can ask:

search(
  "Why did we choose DuckDB?"
)
Enter fullscreen mode Exit fullscreen mode

The Second Brain handles the complexity.

Claude doesn't need to know whether the answer came from:

PostgreSQL
pgvector
Search Index
Knowledge Graph
Obsidian
GitHub
Slack
Enter fullscreen mode Exit fullscreen mode

It simply receives useful context.

Claude Can Write Back

This is where it becomes more than traditional RAG.

The flow isn't only:

Knowledge → AI
Enter fullscreen mode Exit fullscreen mode

It becomes:

Knowledge ↔ AI
Enter fullscreen mode Exit fullscreen mode

For example:

"Remember that we decided to keep PostgreSQL as the source of truth."

Claude calls:

remember(...)
Enter fullscreen mode Exit fullscreen mode

The system can then:

Extract Entities
       ↓
Extract Relationships
       ↓
   Create Memory
       ↓
Generate Embedding
       ↓
   Update Graph
       ↓
   Store Source
Enter fullscreen mode Exit fullscreen mode

The knowledge base becomes progressively richer.

The Model Doesn't Own the Knowledge

This is one of the most important ideas.

Today:

Claude
   ↓
Claude Memory
Enter fullscreen mode Exit fullscreen mode

Another AI:

GPT
   ↓
GPT Memory
Enter fullscreen mode Exit fullscreen mode

Another:

Gemini
   ↓
Gemini Memory
Enter fullscreen mode Exit fullscreen mode

Everything is isolated.

Instead:

             Claude
                │
               GPT
                │
             Gemini
                │
              Cursor
                │
                ▼
         ┌───────────────┐
         │  Knowledge OS │
         └───────────────┘
Enter fullscreen mode Exit fullscreen mode

The model can change.

The knowledge stays.

The Bigger Idea

I don't think the future is simply:

"Give Claude more context."

I think it's:

Build a persistent knowledge layer that every AI can use.

Obsidian can remain your human knowledge interface.

GitHub can remain your source-code system.

Slack can remain your communication system.

Your databases can remain your data systems.

Your AI assistants can remain your reasoning systems.

The Knowledge OS connects them.

Beyond the Second Brain

A traditional Second Brain helps you remember.

An AI-native Second Brain helps AI understand.

It combines:

  • Knowledge Engineering — turning raw information into structured knowledge
  • Graph Engineering — discovering entities and relationships
  • Hybrid Retrieval — combining semantic, keyword, and graph search
  • Long-Term Memory — preserving decisions and important context
  • MCP — making the knowledge available to AI agents and assistants

The result is something larger than a note-taking application or a vector database.

An AI-native Knowledge Operating System that combines Knowledge Engineering, Graph Engineering, Hybrid Retrieval, and Long-Term Memory into a unified platform accessible through MCP and APIs.

The LLM provides the reasoning.

The Knowledge OS provides the memory.

And MCP becomes the bridge between them.

Top comments (1)

Collapse
 
mads_hansen_27b33ebfee4c9 profile image
Mads Hansen •

The retrieval taxonomy is solid. The difficult part is proving that the router and fusion layer improve answers instead of merely adding more ways to retrieve the same stale claim. I’d build a gold set labeled by question shape and required evidence, then log which retrievers ran, candidate ranks, evidence coverage, contradiction rate, latency, and token cost. Compare against vector-only and keyword-only baselines, plus ablations with each retriever removed. For graph expansion, require the entry entity to come from cited evidence rather than a model guess. Exposing that retrieval trace through MCP would make search() return not just context, but a debuggable reason why this context won.