Beyond Chat History: Building an AI-Native Second Brain with Obsidian, GitHub, and MCP

Most AI assistants can discuss your plans. That does not mean they can maintain the system where those plans actually live.

I use AI assistants to think through decisions, review technical architectures, structure projects, and turn rough voice notes into useful plans. But I kept running into the same underlying problem: the conversation was intelligent, while the result remained trapped inside the conversation.

A good discussion might clarify a business strategy, change a routine, or define the next steps of a project. After the chat ended, however, the durable state of my work still had to be updated somewhere else. I either copied the result manually, left it buried in chat history, or began the next conversation with incomplete context.

That is not a knowledge system. It is a collection of temporary conversations.

I wanted a different model:

• one durable place for knowledge, plans, routines, and decisions;
• files I own and can inspect directly;
• version history for every meaningful change;
• access from different AI assistants instead of one vendor;
• explicit rules that tell an assistant how the system should be maintained;
• and controlled remote access from a normal chat interface.

The system I built combines four relatively simple components:

1. Obsidian as the human-friendly interface to a Markdown vault;
2. Git and GitHub as the storage, synchronization, and version-history layer;
3. a remote MCP server as a constrained bridge between AI clients and the repository;
4. operating rules that define how humans and AI agents work with the vault.

None of these components is revolutionary on its own. The useful part is how they work together.

The durable state lives outside the model

The foundation is a normal Obsidian vault. Obsidian stores notes as Markdown files, which means the content remains understandable without the application. I can open it in a text editor, process it with code, version it with Git, or move it elsewhere later.

My current structure distinguishes between temporary work and living state:

01 Inbox/
02 Projects & Plans/
03 Areas & Pillars/
04 Daily Execution/
_ai-context/
_attachments/
CLAUDE.md

Projects and plans have a target state. They can be completed, paused, stopped, or archived. Areas represent ongoing responsibilities and should describe what is currently true and useful. The Inbox is capture, not truth. Daily notes contain dated execution commitments rather than the complete project backlog.

This distinction matters because an AI assistant needs more than file access. It needs to understand the lifecycle of the information it is changing.

The most important file is not a note

The most important component of the vault is arguably its operating manual for AI agents.

Mine is currently called CLAUDE.md for historical reasons, but its role is independent of one model. It defines:

• what each folder is for;
• which files are authoritative;
• how projects differ from areas;
• which metadata fields the system expects;
• how daily execution notes should be created;
• when an assistant should ask before deleting or overwriting information;
• and which personal and company contexts must remain separate.

Without those rules, an assistant can write files but cannot maintain a coherent system.

Consider a request such as:

Turn what we just discussed into a concrete project and save it in my second brain.

That requires more than generating Markdown. The assistant has to determine whether the result is a project, a durable area update, a routine, or an inbox capture. It must choose the correct location, preserve required metadata, inspect related notes, and decide whether other files should change as well.

The rules turn a repository from passive storage into an environment an agent can operate within.

Why Git changes the character of the vault

Markdown is a natural fit for version control, but Git becomes especially valuable once AI agents are allowed to make changes.

Every meaningful edit is traceable. I can see what changed, when it changed, and who initiated the change. An assistant does not silently rewrite the operating state of my work without leaving a history.

The repository also becomes a shared integration point. Obsidian remains my preferred human interface, while local coding agents can inspect the structure, read the instructions, update multiple files, review diffs, and create commits using the same mechanics they already use for software.

This does not remove every dependency. GitHub is still a vendor, and Obsidian is still an application. But the canonical data remains ordinary Markdown with Git history. The system is not bound to a proprietary chat archive or one model's memory feature.

Why local agents were not enough

A local coding agent works extremely well when I am at my computer and deliberately operating inside a repository.

It is less useful when I am using a normal chat interface, working from my phone, walking, cycling, or speaking through an idea before I am ready to sit at a desk. I did not want the second brain to be available only when a particular computer and local coding session were active.

I wanted a normal AI client to have controlled remote access to the same canonical knowledge base.

That is where MCP became useful.

MCP as a controlled bridge

The Model Context Protocol provides a way for an AI client to interact with external tools and data. In this architecture, the client does not receive unrestricted shell access or a generic GitHub connection. It receives a narrow set of repository operations through a remote MCP server.

At a high level, the flow looks like this:

Chat interface
      |
      | authenticated tool access
      v
Remote MCP server
      |
      | repository-scoped operations
      v
Private GitHub repository
      |
      v
Markdown files and Git history

The server is deliberately constrained to one configured repository. Its tools can list the structure, read and search notes, and create or update files. Writes use the current file version to detect conflicts, and the exposed tool surface does not include deletion.

The two authentication relationships stay separate:

AI client  ->  MCP server
MCP server ->  GitHub

The credential used by the server to access GitHub remains a server-side secret. The model sees explicit tools, not the underlying credential. This boundary is one of the most important parts of the architecture.

What the workflow feels like

The value becomes visible after a normal conversation reaches a useful conclusion.

I can ask the assistant to read the operating rules and relevant project context, turn the discussion into a structured plan, place it in the right part of the vault, update a related execution note, and preserve the result in Git history.

The conversation is no longer the final resting place of the work.

Voice input makes this even more useful for me. I often think most clearly while moving, especially while cycling. I can dictate an unstructured explanation, review the converted text, and let the assistant transform the thought into a durable artifact. Work that would otherwise wait until I returned to a desk - and lose detail along the way - can enter the system while the thinking is still fresh.

The human still provides intent, judgment, and approval. The assistant handles much of the mechanical transformation and placement.

This is more than memory

It is tempting to describe this setup as "giving an AI memory." That is incomplete.

The vault represents:

• current state;
• commitments;
• operating rules;
• project history;
• reusable knowledge;
• strategic context;
• and evidence of what changed.

A model's internal memory may personalize a conversation, but it is not the same as a transparent, versioned, user-controlled operating system.

The durable state should remain inspectable outside the model. The model should be able to use that state, but it should not own it.

The limitations are part of the design

This system is not automatic truth and it is not risk-free.

Repository search is not a database query. Full-file updates require care. Structure still needs maintenance. Remote access creates a real security responsibility. Git is a poor home for large binary collections or rapidly changing application data. Most importantly, an AI assistant still needs supervision for meaningful changes.

Those limitations are not reasons to abandon the approach. They define where the boundaries need to be explicit.

For me, the result is not perfect memory. It is continuity: between conversations, devices, models, and the actual projects I am trying to move forward.

That is the larger idea behind the architecture. The model is not the system. The governed environment around it is.