Building a Second Brain: Why I Stopped Trusting Any Single AI With My Memory

A client mentions a recurring issue in a Tuesday meeting. I make a mental note. By Thursday, I’ve had four more meetings and the note is gone — not forgotten exactly, but buried under the weight of everything else. Three weeks later, another client describes the same problem in different language, and I don’t connect the dots because the dots live in different systems.

If you’re a solopreneur or consultant, you know this feeling. The information exists somewhere. You captured it, probably. But it’s scattered across meeting transcripts, chat threads, project notes, and the hazy recollection that someone said something important about something relevant at some point.

This is the problem I set out to solve. And the solution I landed on is something I’m calling my second brain.

The Problem As I See It

Here’s what I find interesting about the current AI conversation. People debate models endlessly. Which one is smarter. Which one codes better. Which one hallucinates less. Those differences matter — I’m not dismissing them. But the thing that actually determines how useful AI is in my daily work has nothing to do with model selection.

It’s memory.

Every time I open a new chat with any AI tool, I start from zero. My role, my projects, my constraints, the decision I made last Tuesday — all of it needs to be re-explained or it doesn’t exist. I’ve watched myself spend the first four minutes of a Claude conversation just getting it up to speed on context I’ve already provided a hundred times. That’s not collaboration. That’s orientation.

Yes, Claude has memory now. ChatGPT has memory. They’re getting better at it. But here’s the catch that Nate B. Jones articulated clearly: Claude’s memory doesn’t know what I told ChatGPT. ChatGPT’s memory doesn’t follow me into Claude Code. My phone app doesn’t share context with my coding agent. Every platform has built a walled garden of memory, and none of them talk to each other.

What you’ve really got is five separate piles of sticky notes on five separate desks. That’s not memory. That’s the illusion of memory.

And the problem goes deeper than inconvenience. Platform memory is a lock-in strategy. You spend months building up context with one tool, and now switching to a better model means abandoning all that accumulated knowledge. Not because the new model is worse, but because your context is trapped in the old one. Your knowledge becomes a hostage to a platform’s business model.

Why Note-Taking Apps Don’t Solve This

The idea is to capture your thinking in an external system so your biological brain can focus on having ideas instead of holding them. Tiago Forte’s CODE methodology — Capture, Organize, Distill, Express — has helped a lot of people get their information under control.

But there’s a structural limitation that’s become more obvious as AI agents enter the picture. Tools like Notion, Obsidian, and Apple Notes were designed for the human web — pages, databases, toggles, cover images. Beautiful for you to browse and organize. Not designed for an AI agent that needs to search by meaning rather than folder structure.

The AI features being added to these tools are bolt-ons. “Chat with your notes” is fine, but it’s one AI searching one app. What about the other five tools you use every week? You’ve traded one silo for another.

Jones draws a distinction I agree with: there’s the human web — fonts, layouts, interfaces designed for human eyes — and there’s the emerging agent web — APIs, structured data, systems built for machine-to-machine communication. Your note-taking apps were built for the first. What I needed was infrastructure for the second.

FORGE is a reader-supported publication. To receive new posts and support my work, consider becoming a free or paid subscriber.

What I Actually Built

Recently, I started experimenting with a different approach. The inspiration came from Nate B. Jones’s Open Brain architecture: a Postgres database on Supabase with an MCP server in front of it.

If that sounds technical, the concept is straightforward. Postgres is a database — the most boring, battle-tested way to store data you can imagine. It’s not chasing a growth metric. It’s not VC-backed and needing to hit a valuation target. It’s just a reliable, standard way to keep information organized. You want that boringness because everything else needs to plug into it.

Supabase gives you a free Postgres database in the cloud with a web interface, so you don’t need to be a database administrator to set one up. And MCP — Model Context Protocol, created by Anthropic and open-sourced in November 2024 — is what connects AI tools to that database. Think of it as USB-C for AI. One protocol, and any AI that speaks it can read and write to your data.

So I set up the database. Then I connected MCP servers for the services I actually use: Google Chat, Google Calendar, Gmail, Granola for meeting transcripts, Google Tasks. Then I connected Claude Code’s Cowork feature, which lets me schedule automated sessions that pull information into the system and generate reports.

The result: my meeting transcripts, tasks, project updates, and notes all flow into a single database that any AI I use can query. I can open Claude and ask about a conversation I had three weeks ago. I can ask for patterns across client meetings. I can get a daily digest of commitments I’ve made. And if I switch to a different AI tool tomorrow, it has the same access to the same brain.

One brain. Every tool. Memory that never starts from zero.

What Didn’t Work (At First)

I want to be honest about the learning curve, because the concept is cleaner than the reality.

My first attempt was actually more ambitious than what I ended up with. I looked at OpenClaw — which has passed 190,000 GitHub stars and spawned over 1.5 million autonomous agents — and thought about building a fully autonomous system out of the gate. I backed off quickly. The security surface area was more than I was comfortable managing, and the failure modes weren’t ones I could predict or control. When an autonomous agent has access to your client data and communication channels, “what could go wrong” is a long list.

I also tried connecting too many services at once early on. The MCP connections worked individually, but debugging why a particular piece of data wasn’t flowing correctly across five integrations simultaneously was its own kind of misery. Breaking things down to one connection at a time, testing each before adding the next, was the obvious approach I should have started with.

The lesson was one I’ve written about before: manual excellence before automation. You need to understand what the system is doing before you let it run unsupervised. That understanding only comes from building incrementally.

The Part That Surprised Me

I expected the basic utility — search my notes, remember my meetings, stop re-explaining myself. That works, and it’s a relief. But the thing I didn’t expect is what happens when you have months of accumulated context that an AI can actually reason about.

I have a new project launching called Mynah. It’s for my clients — a tool built specifically to solve problems they’ve been describing to me across months of conversations. Here’s what’s different about how it came together: I didn’t have to go back through meeting notes manually. I didn’t have to rely on my imperfect memory of who said what and when. I queried my second brain for patterns across client conversations, and the consistent problems surfaced clearly.

Previously, identifying those patterns would have taken months of careful note review and a diligence in meeting documentation that I’m honestly not great at maintaining. The subtle cues — the things people mention in passing that reveal a real need — those get lost when your system for capturing them is “try to remember.”

Now I can use the problems people have been describing as the foundation for a solution spec. The data was always there in my conversations. I just didn’t have a way to see across all of it at once.

This is the compounding advantage that makes the whole system worth building. Every conversation captured makes the next pattern more likely to surface. Every decision logged gives the AI more context for the next question. One month in, my second brain knows my projects, my clients, my commitments, and the threads connecting them better than I can hold in my head. Six months from now, that gap will be wider. A year from now, it’s a fundamentally different way of working.

Jones describes the difference between two people: one who spends four minutes getting an AI up to speed every session, and one whose AI already knows her role, her projects, her constraints, and her decisions from last week. Same model, same capabilities — completely different outcomes. The variable is the memory infrastructure underneath.

I want to be careful here. Mynah could be a terrible idea. But the fact that I could go from scattered client conversations to a clear problem definition to a spec in days instead of months — that’s real, and it came directly from having searchable, AI-accessible memory.

Going Slow on Purpose

If you follow the AI space, you’ve probably noticed the pressure to adopt everything immediately. New agent framework? Deploy it. New autonomous system? Let it loose. The pace is genuinely staggering.

I’m taking the opposite approach, and I’d encourage you to do the same.

I’m deploying these capabilities one piece at a time, deliberately, with full understanding of what each component does and what risks it introduces. I started with the database. Then added one MCP connection. Then another. Then Cowork scheduling. Each piece got tested and understood before I added the next.

The people who deploy everything at once are the ones who get burned. Security issues they didn’t see coming. Costs they didn’t anticipate. Agents that did something unexpected because nobody thought through the permissions. I’ve seen it enough times to know that slow and controlled beats fast and chaotic every time.

I chose tools I can verify — Supabase with proper authentication, MCP servers I can audit, Claude Code sessions I can review. Controllable outcomes without exposing myself or my clients to unnecessary risk. The running cost on free tiers is roughly ten to thirty cents a month. You’ll spend more on coffee this morning.

What This Series Will Cover

This is the introduction. I wanted to lay out the why — why platform memory isn’t enough, why note-taking apps weren’t designed for this, why boring database infrastructure is the right foundation, and why going slow is faster than going fast.

Over the coming months, I’ll document what actually happens as I live with this system:

Part Two will cover the daily workflow — what capture looks like in practice, how much time it actually takes, the habits that stick and the ones that don’t, and how the system changes your relationship with your own thinking.

Part Three will go deeper into pattern recognition — how accumulated data reveals things you couldn’t see before, and what happened with Bench once I had months of client context to draw from. I’ll show the actual queries and results, not just the conclusions.

Future installments will cover scheduled automation, agent integration, the things that broke, and the things that surprised me.

Where to Start

If this resonates and you want to build your own, Jones’s companion guide walks through the full Supabase + MCP setup step by step. He tested it with someone who has no coding experience, and it took about 45 minutes.

But the architecture matters less than the decision to start. The specific tools will evolve. Postgres won’t. The principle of owning your own memory layer won’t. The compounding advantage of capturing your thinking in a system that every AI can access — that only gets stronger over time.

The biggest bottleneck in your AI workflow isn’t the model. It’s the fact that none of your tools remember what you told the others. Fix that, and everything downstream gets better.

I’ll show you what the daily reality looks like next month.