The Second Brain, Part Two: The Context Layer

The thing that got drilled into the team was simple: your assumptions about how things work need to take the reality on the ground into account. The way you approach a shoot in Addis Ababa is not the way you approach a shoot in London. Same eye, same gear, same intent — but if you brought the wrong frame for the context, the work suffered. Not because anyone in any of those places was harder to photograph, but because context is relative to the sphere you’re working in, and ignoring that sphere produces work that does not capture the true meaning of the place that it was captured in.

I think about this constantly with AI now.

The Database Is Built. What Flows In?

In Part One, I laid out the architecture — a Postgres database on Supabase, an MCP server in front of it, and an argument that owning your own memory layer is the single most underrated decision you can make as an AI user in 2026. If you read it, you know the case: every platform is building a walled garden of memory, none of them talk to each other, and the only way out is to own the foundation yourself.

That was the vessel. This is the next question: what do you put in it?

Because here’s what I’ve learned in the months since I started running this thing: the architecture is necessary, but it is not sufficient. A Second Brain that’s stuffed with everything is just a junk drawer with better lighting. The discipline of what flows in and how it connects to what’s already there — that’s what separates a system you reach for daily from a database you forget you have.

I’m calling that layer the Context Layer. And it has two parts.

Why Multi-Source Context Beats Single-Source Detail

Before I get to the framework, let me walk you through the example that made all of this click for me.

Imagine you have an Excel spreadsheet with ten years of sales data. A thousand records. By itself, you can see when each sale happened and how much it was worth. That’s useful, in the way that a single ingredient is useful.

Now add typed conversation notes for each sale — actual saved text from your discovery calls. Suddenly you can ask different questions. What was the key point that converted that customer? What’s the most common need across the deals that closed? You’re not just looking at outcomes anymore; you’re looking at the language that produced them.

Add calendar events from the last ten years. Now you can compare the date the conversation started with the date it closed. You can see how many times each customer had to be re-engaged before they bought. The pattern of patience required to win a deal becomes visible across a decade.

Each connected source doesn’t add a single new fact. It multiplies what you can ask.

I went through something like this last year evaluating vendors for a project. Several conversations with several vendors, and I needed to build an evaluation matrix. I could have done it with just the meeting notes and gotten somewhere reasonable. But then I added the emails, the presentations, and the response-time deltas — how long it took each vendor to come back when I asked a real question.

That last layer changed the analysis entirely. Two vendors looked identical on capability. The one that consistently turned around responses faster, and went deeper on the questions I’d actually asked, turned out to be the one that wanted the work. The one that took three weeks to send back a deck didn’t. That’s invisible in meeting notes alone. It only shows up when you can see the fabric between sources.

When the technical capabilities are close, the relationship signal often matters more than the specs. You can’t see that signal unless your context layer connects the threads.

The Two Keys

OK, framework time. Here is the discipline I’ve landed on after a few months of actually living with this.

Key 1: Pre-Labeling

Filter at the source. Don’t let your capture mechanisms harvest everything. Decide what’s allowed in before it hits the brain.

In practice: every client email gets a client tag at the inbox level. Every meeting transcript is labeled with project, attendees, and topic before it gets ingested. Every newsletter I want to keep is tagged at the moment I read it.

Here’s why the tagging matters — and this is the part that took me a while to internalize. The tags aren’t for you to find things later. The tags are for the automated collection to know what to pull.

The scheduled jobs we’ll get to in a minute aren’t smart. They don’t read your inbox and intuit which messages are important. They run a query against a tag — get everything labeled “client”, pull the transcripts marked “platform redesign” — and bring back exactly what the tag points to. No tag, no query target, no automation. The tag is the contract between you and the system: this is what I’ve decided matters, and this is what I want the brain to pull in for me, automatically, on a schedule, while I’m doing something else.

That changes the work you do up front. You’re not labeling things for your own future search convenience. You’re defining the slices of your data your future automation is allowed to touch.

This sounds tedious, and the first time you set it up, it is. But once the filter exists, you stop poisoning your context with noise that doesn’t matter. The brain pulls in only the client-tagged emails, only the project-labeled transcripts, only the deliberately-saved newsletters. You’re not deciding what to ignore on the way out — you’re deciding what to allow on the way in, which is the much easier place to make that decision.

The principle: a great Second Brain is not the one that captures the most. It’s the one that says no to the most.

Key 2: Combining Sources

Connect threads across systems using shared keys. Dates connect meetings to calendar events. Project names connect tasks to commits. Attendee names connect transcripts to email threads. The relevance fabric across your tools is built out of these shared identifiers.

My setup pulls from meeting transcripts plus calendar events plus task lists plus git commits plus project management updates. None of them, individually, gives me much. All of them, connected by dates and names and project tags, gives me a context-rich view that no single tool can produce.

When I ask “what was the last thing we talked about on the platform redesign?” — I’m not asking my note-taking tool. I’m asking a system that can pull the last meeting transcript, the calendar event around it, the tasks I committed to, the git commits I pushed in the following days, and the email I sent afterward. The answer is a synthesis, not a record.

That’s the difference between memory and notes.

The Discipline Qualifier

Now, an honest aside, because I don’t want anyone reading the above and concluding that the answer is to feed everything into the database.

You might read the two keys and think: more is better, capture more sources, tag more aggressively, connect more threads. I want to be careful here, because I don’t believe that.

I don’t want everything in my life involved in this system. There are conversations that should not be ingested. There are emails that have no business being indexed. There are areas of my work and life that belong outside the brain because outside the brain is exactly where they should stay.

The Second Brain is a tool, not a confessional. The discipline is curation, not capture-everything. I’ve developed systems that pull only from validated sources — client-tagged emails, named project channels, recorded meetings I chose to record. Everything else stays out, by design.

A useful test: if your Second Brain has access to data that you’d be uncomfortable explaining to a client, a partner, or yourself in three years — you put too much in. Take stuff out. The whole point of owning the layer is that you get to decide.

This matters more, not less, the longer you run the system. Once you’ve been capturing for six months, the cost of cleanup is higher than the cost of having said no in the first place.

The Scheduled Capture Layer

The last piece is what makes the system actually run without you.

Manual capture won’t survive a busy week. If your discipline requires you to log every meeting, tag every email, and import every commit by hand, you will fall behind within a month, and you will quietly stop using the system within two. I know this because I tried it.

What works is scheduled capture. Three mechanisms cover most of the surface, and each has a different role:

Supabase Cron runs inside the database. It’s a Postgres module that lets you schedule jobs in standard cron syntax — every minute, every hour, every Tuesday at 9pm. The jobs can run SQL, call database functions, hit HTTP endpoints, or trigger Supabase Edge Functions. No server to maintain. The minimum interval is one second if you need it that often (you don’t). This is where I run the automated pulls — every hour, a job hits the APIs of the services I’ve connected and pulls the latest data into the brain. I never think about it.

Claude Code Routines runs Claude Code sessions on a schedule. Anthropic launched these in mid-April 2026, and they fill a different gap: when you need an actual Claude Code session — with its tool access, its skills, its ability to read and write files in your repos — to run on a schedule. A routine is a saved configuration: a prompt, a repo, a set of connectors, packaged once and run automatically. Mine runs every Tuesday evening to pull the past week’s recommendations from one of my data services and stage them as research seeds for upcoming articles. It runs whether my laptop is open or not, from my Mac Mini.

ChatGPT Tasks runs ChatGPT prompts on a schedule. OpenAI shipped this feature in early 2025; it’s still in beta for Plus, Pro, and Teams. You get up to ten active tasks, recurring or one-off, and the results come back as a push notification or an email. If your brain lives more on the ChatGPT side, this is the equivalent capture engine.

You don’t need all three. You need the one closest to where your data actually lives. Pick the smallest version of this that solves your real bottleneck, then add the next one when you actually hit a limit.

What This Buys You

Once these pieces are in place — the architecture from Part One, the two keys, and the scheduled capture layer — something quiet starts to happen.

You stop briefing your AI tools from scratch. The context they need is already there. You ask a question and the answer arrives with the attendees, the dates, the prior decisions, and the related threads already in scope. Not because you remembered to provide them, but because the system did.

That’s the compounding return Nate B. Jones described in his original Open Brain piece, which kicked all of this off for me. Every captured thought makes the next search smarter. Every tagged transcript makes the next pattern more likely to surface. You don’t notice the gain on day one. By month six, the gap between your old workflow and the current one is unmistakable.

I haven’t figured out the cleanest way to measure that gain yet — and that’s the question I want to take on next. It’s easy to feel the difference; harder to put a number on it. If you’re thinking about pitching this to your CFO, that’s a real gap I want to close.

What’s Next

Part Three is going to go deeper into what happens when you’ve actually got months of this stuff accumulated and you start asking the brain real questions. I have a project called Mynah that I built almost entirely from patterns I queried out of accumulated client conversations. I’ll walk through the actual queries and what they surfaced — what was in the data that I couldn’t see, and what changed about the work because the data made it visible.

For now, if you’ve been sitting on a Part One implementation and wondering what’s supposed to happen next: it’s this. Decide what flows in. Connect the threads across your sources. Schedule the capture. Then watch what happens to the questions you can finally ask.

The architecture is the easy part. The Context Layer is the work.

Part Three lands next month. If you haven’t read Part One, start there — the architecture below the Context Layer is what makes any of this possible.