Second Brain

The Second Brain

This will be a series of articles on the Second Brain. We will keep adding to it over time.

Where should the second brain live?

In our first article, we defined what a second brain actually is: the persistent layer of context, rules, and memory that turns an ephemeral AI chat into a reliable operating partner.

Once you decide you need one, the immediate question seems simple: Where do we put it?

Most teams treat this as a standard IT storage decision. Someone suggests Notion. Someone else suggests SharePoint for enterprise compliance. A technical founder wants a vector database or Neo4j graph. Someone else uploads twenty PDFs into a Claude Project and calls it a day.

Within a month, almost all of them hit a wall.

Across production setups we work with, we’ve watched teams move their memory four times in five weeks. None of those moves was about disk space. All were about workflow, permissions, and connectors.

Here is what we have learnt (the hard way) about where a second brain should live.

It is a connector decision, not a storage decision

The first mistake is choosing a home where your AI can only read.

In one program we worked with, the initial choice was an enterprise SharePoint instance. It checked every compliance box. But within days, the team discovered that corporate IT rules prevented AI agents from writing back to it. Every time an agent extracted a decision or updated a note, a human had to copy-paste the output.

That defeats the purpose. A second brain is not a digital archive; it is an active workshop.

Before committing to any platform, run one test: Can your AI agent both read and write to this location today, autonomously? If it can only read, you haven’t built a second brain; you’ve built a reading list. A caveat to this, while writing as a feature is important for the agent, it also means the agent can write incorrect things in your second brain, this is where human monitoring, agent guardrails and roll-back options play a role.

Don’t build inside the model’s walled garden

It is tempting to keep your memory inside Claude Projects, ChatGPT workspaces, or proprietary tool silos.

It feels frictionless on day one. But two problems hit immediately:

Copies drift. The moment you edit a note inside a vendor’s workspace, it decouples from your team drive. Within two weeks, you have competing versions of reality, and neither is trustworthy.
Harness churn. The AI tool you love today is not the one you will use eighteen months from now. Trapping institutional knowledge inside a vendor’s proprietary memory guarantees corporate amnesia when you switch providers.

Your data layer must outlive the model reading it. Plain Markdown files, CSVs, and standard folder hierarchies have survived forty years of computing cycles. Build your memory in plain files on standard file systems, ideally adding versioning through git; treat the LLM as a modular engine you point at those files.

Beware the knowledge graph trap

Whenever technical leaders (including ourselves) design an AI memory system, someone inevitably advocates for a knowledge graph, Neo4j, or complex GraphRAG pipeline.

We tried that. In an earlier production architecture, we deployed an automated knowledge graph backend. That meant 90-minute whole-graph rebuilds whenever files changed, brittle entity resolution, and constant schema debugging. The operational drag was enormous; the retrieval advantage was negligible.

We killed the graph backend completely, replacing it with flat Markdown files, YAML frontmatter, and deterministic local search (separate article on retrieval coming soon).

Unless you are indexing millions of cross-referenced legal filings, you do not need a graph database. At sub-5,000 document scale, structured Markdown and standard text search are faster, lower-latency, human-auditable, and free.

The sweet spot: Local-first, cloud-synced

The dilemma is usually framed as Local vs. Cloud:

Pure local gives you blazingly fast execution, privacy, and full access to local terminal tools. But shut the laptop lid, and your agent sleeps. Leave the company, and the memory leaves with you.
Pure cloud lets the team collaborate, but introduces the connector tax: rate limits, brittle OAuth tokens, and sync delays.

The architecture that works in production is local-first, cloud-synced: a dedicated local directory mirrored to a shared corporate drive. Your AI agents run locally against the filesystem at machine speed with zero latency, while background sync keeps the team’s master record updated.

Ownership is invisible until it breaks

Almost every second brain begins inside a personal cloud folder or laptop because someone wants to move fast.

Then the system reaches 1,000 files across 200 folders. When you onboard an intern, contractor, or autonomous daemon on a server, permissions collapse. You spend days executing messy bulk ownership transfers because personal accounts block automation.

From minute one:

Create the root folder under a dedicated company account, never a personal inbox.
Set up at least two team members with full admin recovery access.
Declare the location an invariant: no moving or re-architecting the folder tree without explicit sign-off.

Draw access boundaries before you save File #1

You cannot solve privacy by trying to remember what not to tell the AI. The moment you invite a teammate or connect an autonomous agent, everything in that folder is fair game. Give the agent permissions and access only to what it needs to do its work, open up more only when needed, and draw a hard line on what the agent is never allowed to touch.

Before adding your first document, partition your directory into three clear zones:

Core Operating IP: Playbooks, PRDs, customer discovery notes, and process guidelines open to the entire team and all agents.
Client / Deal Confidentiality: Customer deliverables and NDA-bound notes restricted to specific project teams.
Corporate Governance: Equity, cap tables, compensation notes, expenses and private board debriefs kept in a strictly segregated folder that general team agents never touch.

The three rules to start with

If you are setting up your second brain this week, don’t overcomplicate it:

Keep it in plain text (Markdown + frontmatter) so it remains portable across whatever AI tools arrive next year.
Host it in a company-owned shared drive that your AI can both read from and write to autonomously.
Partition your folders on day one so you can safely share context with teammates without leaking your cap table.

In the next piece, we will dig into Ingestion: how to get real data into your second brain continuously without drowning in documentation fatigue.

What is the Second Brain, why do you need one?

As you go down the path of making AI agents useful for you and your team, you will hear the term Second Brain. With this article we attempt to explain what it means, and why you might need one.

A second brain is the persistent layer of knowledge, rules, memory and retrieval that sits between you and your AI agents, giving them the context they need to understand you, your work and the world they operate in.

Let’s start with setting a base for what AI agents are. Most probably you have used ChatGPT or Gemini or Claude in some way, and noticed that it remembers previous conversations, stuff you have told it about yourself, topics you have been brainstorming about etc, and it uses that piece of information to flavour your current conversation. This, like targeted ads on Google and Facebook, is personalization that makes your experience better with the tools.

ChatGPT and similar for the most part are passive - a web chat interface that responds to your questions and follow ups. The new age AI agent is different, it is sitting on your laptop, or a cloud server, something with access to documents you have not explicitly attached during the chat, something that can not just read those documents but also edit them either as per your direct instruction or as an indirect consequence of another instruction. These include the likes of OpenClaw, Hermes Agent, Grok Bot, Meta Muse … and so on. These agents are also long running, for hours or even days, they can keep working when you are not at your machine actively steering them.

There is an increasing call for these systems to be treated as your personal assistants or junior co-workers depending on the use case. Now think about what happens when humans take those roles. A personal assistant refers to:

Your email and chat to set up a morning brief for you.
Your calendar to manage meetings for you.
Your kid’s details to manage his tuition and sports class subscriptions.

Junior co-workers have an even broader scope.

They need to be on-boarded with company SOPs, jargon, relevant chat groups and more.
They need to understand what tools they have and how to use them to deliver effectively.
They need to understand the org and escalation hierarchy to alert stakeholders when needed.

All of what we stated above and much more is what makes the human perform well, and that too not immediately but over time with some observational learning, some failure and then correction points, some implicit understanding. This is exactly what an AI agent needs too, context, rules, memory, preferences, permissions … structured first and fine tuned over time.

You might have realized it, but it’s worth mentioning explicitly. This contextual knowledge for emails, SOPs, calendars,..etc is constantly updating with time. So Second Brain management on top of breadth and structure also needs the temporal vector to make the AI agent effective.

One last thing to add to the flux, large language models powering these AI agents have limited context windows, which means like a human at a given point in time they can only comprehend limited information, so you can’t dump all possible information and hope the agent will comprehend everything. To solve this we make indexes for the information, like a book index, only the index goes into the agent context, and depending on the search only the relevant part of the data is further retrieved, keeping the context window as light as possible.

So you are thinking, why do we need to worry about Second Brains ourselves, aren’t the big tech players doing this for us already? Yes you are right they are, and we will end up relying on that for a lot of systems we work with. But:

We want privacy and security, we are giving these agents sensitive information, think company IP or our health records. We want this to stay within our control. This means we define permissions and scope for the agent, so it gets only the minimum relevant context, to perform its task.
We want portability, for example we don’t want to just use Grok bot or OpenClaw, we want the option to move to new systems, or even use multiple of them at the same time, but if our second brain is stuck with one, we are stuck with it too.
We want human governance. If the agent makes and manages your second brain, it takes things you don’t want to be considered. If you govern it instead (make a framework not continuously decide what goes in) you can keep it optimized, updated, making agent calls cheaper and faster because only relevant data needs to be considered.

Hopefully with this you got an idea of what a Second Brain is, and why it is needed.

Simple mental model to remember:

You interact with the Agent
Second Brain is Knowledge + Memory + Context + Rules + Retrieval
Agent uses Second Brain to do relevant work for You
You govern Second Brain to make your Agents more relevant