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 #mcp #claude #rag

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

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 (13)

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.

Collapse
 
nishikantaray profile image
Nishikanta Ray •

Exactly — the goal is not more retrieval, but provably better retrieval, with MCP exposing the evidence and trace behind every result.

Collapse
 
hannune profile image
Tae Kim •

In my pipeline I ran into a version of this six months back: Postgres and PostgreSQL were separate clusters, and traversals from one side just didn't reach the data on the other. Found it only when a query came back half-empty and I dug into the graph manually. The tricky part was the threshold; set cosine at 85% on normalized names but that collapsed things that should've stayed separate. How are you handling service name normalization, or hasn't it been an issue yet?

Collapse
 
mansio profile image
Mikhail •

The Postgres/PostgreSQL split is the same failure shape as a bug I hit on the code side, just one level up — there it was two definitions of the same symbol name in different directories, here it's two spellings of the same entity in different clusters. Both get treated as "found a match" with no signal that there might be a second, disconnected node representing the same real thing.

A single cosine threshold probably can't win here either way — 85% collapsing things that should stay separate is the same trade-off my path-based downranking hit: any single global heuristic tends to be right in one direction and wrong in the other. What worked better for symbol resolution was combining signals rather than picking one threshold — proximity/context plus a corroborating signal (for you maybe: same connection string, same port, co-occurrence in the same PR/commit) rather than name similarity alone deciding it.

Collapse
 
nishikantaray profile image
Nishikanta Ray •

Agreed — I haven’t implemented entity resolution yet, but I’ll treat it as a multi-signal problem rather than a single threshold.

Collapse
 
nishikantaray profile image
Nishikanta Ray •

Haven’t hit this issue yet, but it’s a good edge case to account for

Collapse
 
suraj09 profile image
Suraj Suradkar •

Really interesting architecture. The part I keep wondering about with an AI-native knowledge layer is what happens when the knowledge itself changes.

A decision can be correct today and become obsolete six months later. A newer ADR might contradict an older decision, a repository change might invalidate a relationship, or a previously important memory might no longer be authoritative.

So I'm curious how you'd approach knowledge freshness and authority in this kind of system.

Is the harder problem actually retrieving the right context, or knowing which context should still be trusted when multiple sources disagree?

Collapse
 
nishikantaray profile image
Nishikanta Ray •

I think retrieval finds the candidates, but freshness and authority decide what to trust—using timestamps, source priority, and supersedes/contradicts relationships to handle conflicting knowledge.

Collapse
 
suraj09 profile image
Suraj Suradkar •

Yeah, that distinction makes a lot of sense. Retrieval and trust feel like two separate layers — finding the relevant context is one problem, deciding whether that context is still authoritative is another. I think that second layer becomes especially important as project knowledge accumulates over months.

Thread Thread
 
nishikantaray profile image
Nishikanta Ray •

Exactly — retrieval finds the information, while the trust layer decides what’s still valid and authoritative.

Collapse
 
mansio profile image
Mikhail •

This maps closely to what I've been measuring on a real MCP codebase-intelligence server (Python, 50K LOC). A couple of things that showed up empirically and might be useful for the "which retrieval method for which question" framing:

  • Query-agnostic graph ranking (PageRank) vs query-aware retrieval (BM25) isn't close on exact-file retrieval — RAG won 50% vs 36% Hit@Gold on a dense call/import graph, n=50. PageRank alone tends to just surface structural hubs, not what's actually relevant to the question. Might be worth factoring into your "Graph RAG" section — the graph seems more useful as a complement to query-aware search than a retrieval method on its own.

  • On the "one retrieval call vs several" angle: I ran a paired comparison (N=30) between a multi-tool agent flow and a single composed context call. The aggregated call won decisively on latency and round-trips, but only when it includes source+symbols by default — an aggregator that's too eager to compress (or too selective) tanks recall fast. Something to watch if the MCP layer here ends up doing composition server-side.

  • One practical failure mode worth flagging for anyone building the entity graph: symbol/definition lookups can silently resolve to the wrong file if there's a same-named shadow definition elsewhere in the repo (e.g. in experiments/ or tests/). Cheap to guard against, easy to miss until it poisons a whole retrieved context block.

Curious whether you're planning to measure retrieval quality once this is running, or if it's staying architecture-first for now.

Collapse
 
nishikantaray profile image
Nishikanta Ray •

Definitely planning to measure it—this is exactly why I want the architecture to be evaluation-driven.

View full discussion (13 comments)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.