Building HimankBarveKG — a Personal AI Knowledge Graph

A few months ago I found myself asking Claude the same question for the third time that week: "What's the current status of the Mayash Foundation website?" Every new session started cold. All that context — the decisions made, the work done, the things left to do — evaporated when the window closed.

That's when I started building HimankBarveKG.

What Is a Personal Knowledge Graph?

A knowledge graph is a structured way to represent entities and the relationships between them. In the software world, you'll find them powering recommendation engines, semantic search, and enterprise knowledge management systems. But the concept scales all the way down to one person's life and work.

HimankBarveKG is my personal AI-powered knowledge graph. It stores everything that matters to my work: active projects and their current state, decisions I've made and why, skills I'm developing, tasks I've completed, and notes that don't belong anywhere else. The graph isn't just a flat list — it has nodes (entities) and edges (relationships). "HimankBarveKG depends on Cloudflare Workers" is a relationship, not just a note.

The Architecture

The system runs as a Model Context Protocol (MCP) server, which means any AI assistant that speaks MCP can use it as a tool. Claude Code, the AI coding assistant I use daily, integrates with it natively.

The MCP server exposes a set of tools:

  • kg_get / kg_list — read nodes from the graph
  • kg_write / kg_patch — create or update nodes
  • kg_graph_upsert — manage entities and their metadata
  • kg_graph_add_edge — record relationships between entities
  • kg_task_create / kg_task_update / kg_task_complete — task lifecycle management
  • kg_search — full-text and semantic search across the graph

Each node is a markdown file with YAML frontmatter describing its type, status, and metadata. The file format is intentionally human-readable — I can browse and edit my knowledge graph in any text editor, and I do.

Why MCP?

The Model Context Protocol is Anthropic's open standard for connecting AI assistants to external tools and data sources. By building HimankBarveKG as an MCP server, I get a few things for free:

Persistence across sessions. When I start a new Claude Code session, the first thing it does is check my knowledge graph. It knows what I was working on yesterday, what decisions I made last month, and what the next priority is.

Structured updates. At the end of every coding session, Claude updates the graph: appending to Recent Activity, updating Current State, logging decisions. The discipline of maintaining structured notes is largely automated.

Cross-project awareness. When I'm working on the hbarve1.com portfolio site, Claude can look up HimankBarveKG's architecture to make sure the blog post I'm writing is accurate. The graph creates connections that a flat file system can't.

The Session Pattern

Here's how a typical Claude Code session works with HimankBarveKG in the loop:

  1. I open Claude Code and describe what I want to work on.
  2. Claude checks the KG for relevant context — project state, open tasks, recent decisions.
  3. We do the work.
  4. At the end, Claude patches the KG: activity log, state update, any new decisions or edges.

Over time, the graph accumulates a rich picture of how my projects evolve. I can ask "what have I built in the last 30 days?" and get a real answer. I can ask "what decisions have I made about the Mayash Foundation architecture?" and see a chronological record.

Lessons From Building It

Start with the schema, not the UI. The shape of the data matters more than how you view it. I spent time on the frontmatter conventions and edge types before writing a single query. That investment paid off.

Automation is the only way to keep it current. A knowledge graph you maintain manually is a knowledge graph that goes stale. By encoding the update protocol into Claude Code's CLAUDE.md instructions, I made updates the default behavior at session end, not an afterthought.

Relationships are more valuable than nodes. I thought the value would come from having all my project summaries in one place. The real value comes from the edges: knowing that HimankBarveKG is a dependency of hbarve1.com, that Tapas uses the same MCP pattern, that Code for Dharma was a predecessor to Mayash Foundation.

Human-readable storage is non-negotiable. JSON databases and SQLite are fine for apps. For personal knowledge, I need to be able to grep my graph, read it in a text editor, and version-control it with git. Markdown with YAML frontmatter hits that sweet spot.

What's Next

The current version works well for solo use. The next phase is making it smarter:

  • Semantic search using embeddings so I can find nodes by concept, not just keywords.
  • Tapas integration — Tapas is my habit and session tracker (another project I'm building). Linking daily habits to project velocity will surface patterns I can't see manually.
  • Consulting context — as I take on IT consulting engagements for dharmic institutions, the KG will track client projects, decisions, and institutional knowledge separately from my personal work.

Try It Yourself

The architecture is general. You don't need to be a full-stack developer to benefit from a personal knowledge graph — you just need a few markdown files, a consistent schema, and a way to query them.

If you're using Claude Code, the CLAUDE.md file is the right place to encode your update protocol. Tell Claude what to write, when to write it, and where. After a few sessions, you'll have something worth having.

The tools don't have to be elaborate. The discipline is the product.

I write about software engineering, AI systems, and building technology for dharmic and cultural institutions. If this resonated, reach out — I'm always happy to talk shop.