(2026-05-04) Matsuoka Whats In Your Second Brain

Robert Matsuoka: What’s In Your Second Brain? The modern CTO toolkit isn’t just apps and coding tools. The real differentiator is a custom knowledge layer — databases, search indices, memory graphs, behavioral instructions that compound over time. No product gives you this. You build it.

Andrej Karpathy gestured at something similar last month when he posted a GitHub Gist he called “LLM Wiki.” His framing: stop using LLMs just to write code, use them to build and maintain a personal knowledge base instead

What Karpathy is describing isn’t a note-taking system. It’s a personal operational knowledge layer.

For CTOs specifically, that layer needs to be broader than a personal wiki — it needs live organizational data, agent-connected search, and context that persists across months of decisions. No app hands you that

The power isn’t Obsidian. It’s what you connect to it — MCP servers, search indices, knowledge graphs

Productizing this is theoretically possible and practically very hard, because the schema is the moat

The toolkit article got it half right

In What’s In My Toolkit: Claude Code and Family, I wrote about vanilla Claude Code’s core limitations: context evaporates, code search is keyword-based, memory doesn’t persist, execution is single-threaded. The tools I built — Claude MPM, mcp-vector-search, kuzu-memory — address each of those gaps.
But that article was about coding workflows. The real story is broader.

The same architecture that makes a coding session more effective — persistent memory, semantic search, specialized agents pulling from structured data — turns out to be extraordinarily useful for executive work. Understanding an organization, tracking decisions over time, querying data across systems, maintaining context across months of meetings and analysis.

the onboarding was just the starting gun. The second brain I assembled keeps compounding.

What’s actually in my second brain

The memory layer

kuzu-memory is a KuzuDB-backed knowledge graph that persists across every AI session

KuzuDB isn’t a product choice for its own sake — it’s graph-native, which means it handles relationships well

The search layer

mcp-vector-search provides semantic search across all project files. Not keyword search — semantic search with AST parsing

The databases

My CTO project has three:

• *cto.db — SQLite. Work classification, people analysis, contributor data, commit history. The operational database for running analyses and reports.&
• analytics.duckdb — DuckDB. OLAP queries and analytics. When I need to slice engineering output data in different ways or run something that would be painful in SQLite, it goes here.
• duetto_knowledge.db — The RAG-queryable knowledge

The schema reflects how I think about the organization, which is precisely why it’s useful.

The connectors

gworkspace-mcp handles Drive, Docs, Sheets, Gmail, Calendar, and more. I wrote my own rather than using the off-the-shelf options

Beyond Workspace: Notion API for product specs and planning documents. Extraction scripts for JIRA, Confluence, Slack, Datadog, and AWS

I use Obsidian. But it’s a front door, not the building. The vault holds my personal notes, research captures, and synthesized analysis. The Obsidian Web Clipper feeds raw material into the knowledge pipeline. Templates enforce consistent structure.

CLAUDE.md files everywhere

The context layer isn’t just data. It’s also behavioral instructions.

Every major directory in my project has a CLAUDE.md. The root CTO project one is 400 lines of conventions, routing logic, document lifecycle rules, and architectural decisions. Every subdirectory has a more focused version. Every specialized agent has its own constraints.

The productization question

Karpathy said there’s room for an incredible product. He’s not wrong about the gap. He might be wrong about the solution.

Context compounds, products don’t.

The schema is the moat

Products that force their schema on you — and every product does — are imposing someone else’s way of thinking on your problem. That friction is small at first and grows over time.

Privacy is structural, not incidental

When I built duetto-memory for enterprise use, the entire stack stays within our VPC, with memories encrypted to individual users’ OAuth keys. Not even IT can read them

Can anyone do this?

There’s an access problem here, and I’d be dishonest not to acknowledge it.

The irony is that the people who most need better organizational intelligence — executives without deep engineering backgrounds — are least equipped to build these systems. And the people who are most capable of building them are often less interested in the executive problems the systems could solve.

Karpathy’s LLM Wiki is explicitly a system for someone comfortable writing Python and working with file systems. His Gist has code in it. That’s a feature for his audience and a barrier for everyone else.

A few trends that will determine whether this remains a DIY space or gets productized

As more MCP servers mature, the configuration burden drops.

Searchable context beats raw window size.

structured, searchable context doesn’t have a ceiling

Local model quality. Karpathy runs Anthropic agents via Claude Code. But local model quality is improving fast

The people who need it most will have already built their own before any product ships. And in the process of building it, they’ll have accumulated the one thing no product can give them: months of their own operational context, organized the way their own mind works.
That’s not a consolation prize. That’s the whole point