# Build Your Own AI Second Brain: Get Any AI Agent Working the Way You Do > How I built an AI second brain any agent can read: twelve rules across four stages to own, structure, connect and automate the knowledge your AI is missing. ***You explained your work to an AI already this week. Tomorrow you'll do it again.*** AI models are generalists, but your best work isn't. Your taste, your context, the way you actually do the job: that's the thing no model comes with. So when you start a new project how do you hand that to your AI, without re-explaining yourself in every prompt? This is the problem I've been trying to solve for myself over the last year and a half. And I'll tell you right now I don't think it'll ever be answered completely. But once I started sharing my progress with other people, I could see how much I'd actually done and everyone wanted to learn more. So I started by turning it into [a talk](/speaking/) to share at meetups and have spent the last few weeks documenting it in this article and series of other posts yet to come. I hope by sharing my journey it will inspire your own journey. ## You've got a real brain. Your AI agent doesn't. That's the whole problem. Your working knowledge has developed out of thousands of unique interactions that you probably never wrote down. Mistakes you've made, ideas that worked or a random nugget of information someone told you from a completely different industry that you applied with great success. None of it is documented anywhere, which is exactly why meetups and conferences exist: so we can share things we maybe can't write down, or, if we did, some know-it-all would have a go at it on LinkedIn. Your AI agent knows none of this, and likely never will as these models are trained on general knowledge. And while some models are fine-tuned for more specific tasks like coding, vision and computer use, if you ask them a question about a niche like SEO or marketing, you'll get an average answer back because that's precisely what it's built to do. In 2024, researchers gave a group of writers various AI models to generate stories and then blindly judged the results. Writers who'd scored low on a creativity test before using AI got a real uplift: [up to 10.7% more novel, and up to 26.6% better written](https://www.science.org/doi/10.1126/sciadv.adn5290). However, the writers who already scored high in the creativity test got no uplift at all. Their stories were rated exactly as well with the AI as without it. Interestingly though researchers also found the AI-assisted stories were way more similar to each other than the human-only ones were. Individually better, collectively narrower. And you can't model-switch your way out of it either: a separate study found [LLM responses are more similar to other LLMs' responses than humans' are to each other](https://arxiv.org/abs/2501.19361). That's what a model does to your output: it lifts the floor, and it flattens everything toward the middle. If you're new to a field, that's a great trade-off, but, if you've got fifteen years of hard-learned judgment, you're being handed the average and asked to be happy with it. Your taste in your niche is the edge no model ships with. So teach it how you do your job. ## Better prompts are not the answer The first thing everyone reaches for is a better prompt. Tell Claude it's a specialist with a hundred years of experience. Right? At least this is what half the YouTube top 10 AI hacks videos will tell you. But unfortunately, you'll find the results aren't what you'd hope for. One of the most-cited studies against this idea ran four model families over 2,410 factual questions and found that adding a persona to the system prompt [didn't improve performance at all](https://arxiv.org/abs/2311.10054), and sometimes made it worse. Where a persona did help, no method of choosing one beat picking one at random. However, an earlier version of that same paper concluded the opposite, and the authors reversed themselves after testing it more widely. There's research on the other side too, so nobody has settled this. But the [best-designed study I've found](https://arxiv.org/abs/2605.29420) explains why everyone's arguing about it. It broke the results down by what actually changes rather than reporting one score. Through testing 1,140 questions and 38 expert roles, it found a consistent trade-off the averages were hiding. While role prompting reliably increases expertise depth, it also reliably reduces clarity. You get more framing, more caution, more structure, more jargon. However, what you don't get is a better answer. Their conclusion: persona prompting reshapes how a response reads, rather than improving what the model can do. Which sounds obvious once it's said out loud. A persona changes how the model sounds. It can't tell the model something it doesn't know. So that's the whole ceiling on prompt engineering, and it's why the returns are marginal. You're rearranging what's already in there. However well you write the instruction, you're not adding anything the model didn't have when you started. ## Skills have the same problem The more sophisticated move is agent skills. A skill is a small file of instructions, like how to run a content audit or how to format a report. The agent opens it when it decides the skill is relevant, so you're not retyping the recipe every session. That's better than a prompt, and it's closer to where this is going, because it's a file the agent can reference rather than something you type into a box. It isn't free, though. Every skill you install costs you context whether you use it or not. At startup, the agent loads [the name and description of every installed skill](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) into its system prompt, so the shelf is always in the room even when you only want one book. I've got close to a hundred installed, which is about 10,000 tokens spent before I've typed a word. Then there's triggering, which is an educated guess. The agent decides whether to open a skill off that short description, and if the wording is slightly off, it simply never fires. In fact, I deleted 50+ skills this month: the entire persona and recipe skill set that shipped with the Google Workspace CLI, because not one of them had ever triggered, despite having it do similar tasks. Neither of those is the real limit though. The real limit is that a skill tells the agent **how to do something** and nothing at all about what **you've done**. It's a recipe, not a fact. And it lives exactly where the prompt lives. Point a beautifully written skill at something you mentioned 20 turns earlier, and it'll likely still lose the plot, just like the prompt did. Both of them are instructions sitting inside the conversation, and the conversation is the part that breaks. ## The messy middle What you're hitting are the limitations of the context window. Every session has a fixed amount of room, and it all goes on the same pile: your prompt, the skill it opened, the files it read, every wrong turn and every correction you made along the way. And where something sits in that pile decides whether the model will still see it at all. In another study Stanford researchers moved relevant information around inside a model's context and measured what happened. They found [performance is highest when the context sits at the beginning or the end, and drops off significantly in the middle](https://arxiv.org/abs/2307.03172). They called it "lost in the middle", and it held true even for models built specifically for long context. It's helpful to think of context retrieval much like a curved graph where each end of that curve is more likely to influence the conversation while probability declines as the curve declines to the middle. The reason this happens is for me one of the most useful things to understand about AI models. ![U-shaped curve of retrieval accuracy across the context window: high at the start, sagging through the middle, recovering at the end](./_attachments/ai-second-brain/the-messy-middle.png "The messy middle: what's loaded first or said last gets seen, the middle gets missed.")

The messy middle: what's loaded first or said last gets seen, the middle gets missed.

It happens because the two ends of that curve are propped up by two different things. The start is held by the way attention normalises, which over-weights the first tokens whether or not they matter. The end is held by positional encoding, which biases the model toward what's nearest. The middle isn't weak for one reason, it's caught between these two. Bigger context windows don't fix this; you just take longer to reach it. A 2025 benchmark that stripped out the word-matching shortcuts found [11 of the 13 popular 128K+ models it tested dropped below half their own short-context accuracy at 32,000 tokens](https://arxiv.org/abs/2502.05167). Even GPT-4o fell from 99.3% to 69.7%. So everything you carefully explained an hour ago is sitting in there somewhere, competing for attention with everything that's happened since. There are things you can do about it like: chaining your sessions with one task per chat, editing the prompt instead of arguing with the output or loading the important stuff first. While all of that helps, re-explaining yourself inside every session is two steps forward, one step back. ## The fix isn't a better prompt It's giving the agent long-term memory. Something that lives outside the conversation, that it can go back to, check itself against, and re-read next session, without you sitting there feeding it the same information each time. That's context engineering, and once you start getting good at it, you'll barely even need prompting. With the right context, a clear goal and a one-line prompt, an agent can run for hours, if not days. So how do you actually achieve that? ## Onboard it like a new hire The best analogy I've heard for this is: everyone's about to become a manager. You might not have a single human report, but you'll be managing AI agents, and the better you get at it, the more of them you can manage in parallel. So if you think of your agent as a new employee who starts on Monday, and you need them doing things your way. What would you do? **Option 1:** You could have hired someone who already knows the job. They'll be good, and they'll do it their way rather than yours. That's basically your generalist AI model. **Option 2:** You could sit with them and show them. Every time. And hope some of it sticks. That's prompting and hoping the agent's memory system saves things. **Option 3:** You write things down, maybe in a company wiki, and they go and read it whenever they need it. That's context engineering. That wiki is your second brain. ## So what is a second brain? It's just a documentation system of docs and folders. Used for you to retrieve your personal knowledge, ideas, and daily information. That's it. You'll see it called a few different things: A second brain, an AI second brain, a personal knowledge base, a knowledge management system, or, if you've been reading about agents, a context layer. It's all essentially the same folder of notes at its core. For this article, I'll stick with second brain because it's the one people speak about most on YouTube, LinkedIn and Reddit. The idea is older than AI and was popularised by Tiago Forte through his book [Building a Second Brain](https://www.buildingasecondbrain.com/). The concept is to free your biological mind from trying to memorise everything so it can focus purely on thinking and creating. What's changed today is that you're not the only one reading it any more. Having spent [over a decade](/about-me/) trying to get robots to understand content through SEO, the analogy my brain reaches for is a website. You don't need to know anything about SEO for it to make sense, so stick with me, because it's the clearest way I've found to explain what makes a set of notes usable to an agent. An agent arrives at your second brain folder the same way a web crawler arrives at a website. It turns up cold, and it has to find the documents and understand what they're about. So build it like a site you're making crawlable for robots: - Clear information architecture, so it knows where to look - Easy to navigate and easy to read, with no fluff to wade through - Key concepts linked together, with hyperlink text that says what it points to - Clear titles, so it can tell what a document is without opening it - No duplication, so it never has to work out which of three versions is right ## It sounds like a lot of work It does, and writing thousands of pages of documentation about things you already know sounds miserable. Which is exactly why most people have never built a second brain before, and why company wikis go stale within a month of somebody setting them up. It's tedious, it's mundane, and it's the first thing to fall off the list once the novelty wears off. So don't! Back to our analogy: smart managers don't write all their own docs; they get the new hires to write them, and improve them on the way through. That's the system underneath all of this: you're not sitting down to document your job. You're building a system that documents itself and gets sharper every time you use it. ## The four stages Ok, so now all the context (pun intended) is out of the way, how do you actually build a second brain that delivers real results? Honestly, I don't know. But what I can tell you is the approach I've taken so far that has worked for me. To make this easier to follow, I've broken this up into twelve rules across four stages: - Own it - Structure it - Connect it - Automate it **Fair warning:** it gets more complex as it goes, and you don't have to implement all of it, or any of it. I'd rather you take two ideas and actually use them than attempt all twelve and achieve nothing. ![Four stages of building an AI second brain, Own it, Structure it, Connect it and Automate it, with three rules under each](./_attachments/ai-second-brain/four-stages.png "Four stages, twelve rules.")

Four stages, twelve rules.

## My second brain setup Everything from here on in describes my current setup rather than a general approach, so it's worth a minute to share what that setup is. I use an [Obsidian](https://obsidian.md/) vault for my personal AI second brain. Obsidian is a free, local-first knowledge management app where every vault is just a folder of markdown files on your machine. Because there is no database or proprietary cloud service, you face zero risk of vendor lock-in. While this playbook works perfectly fine with any folder of plain text files, I will focus specifically on my Obsidian setup from here on out. The AI agents I use are [Claude Code](https://www.claude.com/product/claude-code), [Codex](https://openai.com/codex), [Google Antigravity](https://antigravity.google/), and some local models for handling mundane jobs. But Claude Code is my daily driver, and it's what I'll be describing. If you haven't used it before, it sounds more intimidating than it is: it's just an AI agent with access to your computer's file system. It's also available inside the Claude desktop app, so you're not stuck in a terminal interface unless you want to be. When `CLAUDE.md` turns up later, that's the file it reads before you've asked it anything. Other tools look for `AGENTS.md` instead, and it's the same idea. I'll mostly say `CLAUDE.md`, because that's the name most people actually use. ## Own it Before you structure anything or wire anything into it, you need to know that the thing you're building will still be there next year, and that it actually belongs to you. ### Rule 1: Own your setup You don't own anything. What do I mean by that? That will be easier to explain with four quick stories, all from 2026. #### When the vendor changes the deal The first one you probably watched happen and thought, this won't end well. Every second post was some LinkedIn Bro telling you how [Claude Code and OpenClaw replaced their entire marketing agency](https://www.linkedin.com/posts/kushal-b-magar_claude-codeopenclaw-just-replaced-your-entire-activity-7430201724574871552-U0dB/). ![LinkedIn post claiming Claude Code and OpenClaw just replaced your entire marketing agency](./_attachments/ai-second-brain/kushal-magar-linkedin-replaced-your-agency.png)

One founder, one terminal, the full stack. You couldn't scroll two minutes without seeing these.

Of course, the other LinkedIn Bros were telling everyone to buy Mac Minis to run it all on, which led to [Apple completely selling out](https://www.wired.com/story/apple-sold-out-mac-mini-openclaw/). Then on 4 April, Boris Cherny, the creator of Claude Code, announced that [Claude subscriptions would no longer cover third-party tools like OpenClaw](https://www.engadget.com/ai/its-no-longer-free-to-use-claude-through-third-party-tools-like-openclaw-160912082.html). Flat-rate plans stopped working with outside agent tools and your whole stack, gone by a pricing-policy change. ![Boris Cherny's post announcing Claude subscriptions will no longer cover third-party tools like OpenClaw](./_attachments/ai-second-brain/boris-cherny-third-party-tools-announcement.png)

Starting tomorrow. Subscribers got a one-off credit and the option to buy usage bundles.

They never caught up on the Mac Minis, either. Months on, you still can't just go and buy one, so people were waiting on hardware for a setup that had already been switched off. #### When a government pulls the plug This one didn't come from a vendor at all. In June the US government issued an export-control directive, and Anthropic [switched off Fable 5](https://www.anthropic.com/news/fable-mythos-access) to comply. The most capable model in the world at the time, turned off by a letter from someone who was neither the company that built it nor the person paying for it. ![ABC News headline on Australians losing access to Anthropic's Fable 5 and Mythos 5 models](./_attachments/ai-second-brain/abc-australians-lose-access-anthropic-models.png)

Not just the US, everybody, Australians included.

#### When the thing you built on moves behind a paywall This one's more personal. I started building my second brain in Notion, and for good reasons: it was in the cloud, I could use it on my phone, and I could share a page with someone without thinking about it. Then I woke up one morning and [couldn't query my own knowledge base any more](https://www.reddit.com/r/Notion/comments/1uc5cje/did_notion_just_significantly_change_the_mcp/), because an overnight change to the way AI agents connect to Notion had removed database search from my pricing plan. Nothing I'd created had gone anywhere; I just couldn't access it using my AI Agent anymore without creating token-heavy workarounds. ![Reddit thread asking whether Notion just significantly changed its MCP capabilities](./_attachments/ai-second-brain/notion-mcp-change-reddit-thread.webp)

Not just me, either.

#### When the tool gets retired mid-talk This one's my favourite, because it happened to me in front of a few hundred people. I spent a bunch of time preparing a seven-minute lightning talk on [using the Gemini CLI for SEO analysis](/antigravity-cli-seo/), at a Google event, [Search Central Live Sydney 2026](https://rsvp.withgoogle.com/events/search-central-live-sydney-2026/schedule), and by the time the event was over, Google had [announced Gemini CLI was being retired](https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/) and rolled into Antigravity. Genuinely the same day. ![Regan on stage at Search Central Live Sydney 2026, presenting the lightning talk "Using Gemini CLI for SEO Analysis"](./_attachments/ai-second-brain/gemini-cli-lightning-talk.jpg)

Search Central Live Sydney 2026, presenting Gemini CLI for SEO.

![Gary Illyes on stage in front of Regan's Gemini CLI slide, with a speech bubble: "SEO isn't dead. But I've just been told Gemini CLI is."](./_attachments/ai-second-brain/gary-illyes-gemini-cli-joke.png)

Gary Illyes, later that day, in front of the same slide.

A couple of those have since been walked back: Fable came back, and I believe Notion restored what they'd changed. However, that's not my argument being undermined; that's my argument. Things in this space move so fast that the tool you built around in March can be gone, changed, restored and changed again by Christmas, and none of those decisions are yours to make. You're still going to need to pick vendors, and you should. Just don't let any of them hold the only copy of how you work to ransom. ### Rule 2: Keep it in plain files Plain files win. So keep them in plain text, on a machine you control. #### Reason 1: They're native An MCP is the standard way an AI agent connects to an outside tool like Notion. Unlike using the Notion MCP, models can read plain Markdown without anything in between: no API, no tool schema, no wrapper. Out of curiosity, I wanted to know what the convenience of Notion was actually costing me. So I had two agents fetch the same note, one reading a file and one going through Notion's MCP. The file read came to about 586 tokens. Through the MCP, it was about 4,373. Same note, seven and a half times the cost. That's the token tax. Now imagine you're doing this over 50 to 100 notes; every additional token you spend is one you don't have for actual work, which means you reach the messy middle much sooner. #### Reason 2: They're yours Every story in [Rule 1](#rule-1-own-your-setup) happened on rented ground. Building locally means nobody can send a pricing-policy email that risks your folder on your laptop. It works on a plane, it works when Claude or Notion are down, and nothing leaves the machine unless you send it somewhere. #### Reason 3: They're portable Finally, because it's just a folder of text, it can go anywhere: laptop, desktop, phone, tablet, server, NAS, cloud storage or even version control like GitHub. No paid platform required, which is the whole point of the next rule. ### Rule 3: Build it for any agent Have a look at how many AI agents have shipped between February 2025 and 2026 (Claude Code, Codex, Gemini CLI, Antigravity, [OpenClaw](https://openclaw.ai/), [Pi](https://github.com/badlogic/pi-mono) and [Hermes](https://hermes-agent.nousresearch.com/)), and then ask yourself which one of these do you want to bet the next five years on. ![Timeline of seven AI agents released between February 2025 and February 2026: Claude Code, Codex CLI, Gemini CLI, Antigravity, OpenClaw, Pi Coding Agent and Hermes Agent](./_attachments/ai-second-brain/ai-agents-timeline.png "Seven major agents in twelve months.")

Seven major agents in twelve months.

And that's before you get to the models themselves. In July 2026, we saw at least seven major models released (Anthropic Claude Fable 5, OpenAI GPT-5.6 Sol / Terra / Luna, xAI Grok 4.5, Moonshot AI Kimi K3, Google Gemini 3.6 Flash, Anthropic Claude Opus 5 and DeepSeek-V4-Flash-0731). ![Timeline of seven major AI models in July 2026: Claude Fable 5, Grok 4.5, GPT-5.6, Kimi K3, Gemini 3.6 Flash, Claude Opus 5 and DeepSeek-V4-Flash](./_attachments/ai-second-brain/ai-models-timeline.png "Seven major models in one month.")

Seven major models in one month.

The good news is you don't have to know, because a folder of markdown doesn't care. Any of them can read it. For me, that's not a hypothetical; my vault sits on my laptop and syncs to my phone and iPad, with a copy on a home server that's always on. I've even set up an authenticated remote MCP against that server, so I can talk to my own knowledge base from the Claude or ChatGPT apps on my phone via voice mode while I'm driving into the city. The whole thing backs up to Google Drive as well, which means the tools that don't support MCP, like Gemini and [NotebookLM](https://notebooklm.google/), can still read it. More usefully, it means I'm not stuck running one agent. While Claude Code is my daily driver for deep work, I've got local models handling the scheduled and mundane jobs where I care more about it being free and private than clever. And I've got Hermes Agent for doing research overnight and delivering a daily digest. They all read the same brain. When something better ships next year, and it will, I'll point that at the same folder and carry on. ![Diagram of one Obsidian vault at the centre, synced to laptop, phone, iPad and a home server, each running its own agents, with cloud apps connecting over an authenticated MCP and a backup to GitHub and Google Drive](./_attachments/ai-second-brain/where-my-vault-lives.png "One vault, every device, every agent.")

One vault, every device, every agent.

## Structure it Now that I've warned you why you need to own your second brain, the next step is to structure it. So, back to our website analogy: imagine we're building a website just for you and your AI agent. Much like a crawler, or a user for that matter, your agent starts at the root folder `/` and works through the menu of subfolders, looking for whatever is relevant to what you've asked it. And just like there are many ways to organise a website, there are many ways to organise a second brain. Here's mine. ### Rule 4: Structure it for search Structure beats memory. Before we get into how I structure mine, here's how I see the difference between you reading your notes and a machine reading them. As a human, I write notes to summarise information and to trigger memories already locked away somewhere in my brain. An AI agent has none of those memories, which means the things I'd normally leave unwritten need writing down too. So the job isn't storing your knowledge neatly; it's making sure that when an agent goes digging, it finds the right thing without you pointing at it. I do that with three layers. #### The organised: PARA There are loads of ways to organise a second brain. The one I use is [PARA](https://fortelabs.com/blog/para/), from Tiago Forte. It's four folders, sorted by how actionable something is rather than what it's about: - **Projects:** for things with an end state, like this article - **Areas:** for ongoing responsibilities you maintain, like SEO or the second brain itself - **Resources:** for references you'll want later, like the articles I clipped while writing this - **Archives:** for anything from the other three that's finished I chose it because it's simple, and because, well, the whole reason I ended up in SEO is that I love a clean information architecture. There's a second reason that matters more here, though: PARA is common enough that most models already know it from training. Write "file this per PARA" in a prompt, and you don't have to explain what you mean. #### The raw: your system of record PARA holds knowledge. It doesn't hold what happened. So alongside it I keep the messy stream of context: - **Daily Notes:** random thoughts, tasks, ideas, and an automated summary of what I actually did that day - **Meeting Notes:** notes from Google Meet and Granola, plus a copy of the transcript in case something didn't make the summary - **People:** one note per person I work with regularly, covering their role, skills and interests, with automated links to any meeting or project we've shared - **Clients / Companies:** the same idea for organisations, with a section for the people inside them This is the layer a lot of people skip, and it's the one that unlocks the real power of a second brain. "What was I meant to be doing on that US project?" stops being something you half-remember and becomes a file the agent can go off and read. Most of mine is captured automatically or filled in by scripts, so it isn't something I think about. #### The machinery: the underscore folders Then there's the plumbing, which isn't knowledge at all: - **`_inbox`:** somewhere to quickly dump anything worth keeping, an article, a social post, a piece of documentation, and hand it off to your agent to file properly later - **`_templates`:** so things stay consistent, and so you're not burning context describing the same shape from scratch every time. You just tell the agent to fill out the template - **`_utilities`:** where the agent keeps copies of skills, scripts and setup. This one matters if you use [Obsidian Sync](https://obsidian.md/sync), because dot-folders like `.claude` don't sync across devices The underscore is nothing clever: it sorts them to the top and tells both me and the agent that this is infrastructure rather than content. The three layers move in one direction. Something lands in the notes folders or gets dumped in the inbox, and the agent helps distil the good parts and file them into PARA. #### The agent README: AGENTS.md All of this structure only works if your agent actually follows it, and so far nothing makes it do that. Of course you could explain the layout at the start of every session, but we've already covered how that ends. Instead you can give your agent a README. So you write it down once, in the file the agent reads before you've asked it anything. [AGENTS.md](https://agents.md/) is the open standard for this, described by the people behind it as a README for agents, and most tools now look for it. However, Claude Code looks for `CLAUDE.md` instead, so I symlink the two and stop thinking about it. Mine sits at the root of the vault and covers everything I'd otherwise retype forever: the folder layout above, that I write in Australian English, where different kinds of note belong, what not to touch. It loads as part of the system prompt before I've typed a word. That's the whole mechanism, and it's why the structure holds. Keeping the file short matters more than you'd expect, which is [Rule 12](#rule-12-audit-it)'s problem. ### Rule 5: Save everything You've already paid for most of this once, either in dollars or in time. Save it. #### Research Anything I come across on a topic goes in, whatever format it's in: - Articles - YouTube videos - Social posts - PDFs - Images - Podcast transcripts For articles and social posts I use the [Obsidian Web Clipper](https://obsidian.md/clipper), one click in Chrome or the share action on iOS. For YouTube, I clip the URL and run a skill that pulls the transcript out. The rest gets copied in. The payoff isn't hoarding. It's that the article you referenced three months ago is a search away instead of gone, and an agent can quote it, cite it, or tell you what's changed since. #### Data Every keyword export, crawl file, rank report and API pull goes into the project folder it belongs to, not just the chat session it came from. Then I have my agent do four things that make it useful later: - **Add frontmatter on every pull:** where it came from, the date it was pulled, the range it covers, and the query or parameters - **Use descriptive, dated filenames:** `2026-08-gsc-queries-au.csv`, not `export (3).csv` - **Pull the most granular data available:** daily usually costs the same as weekly, and it means you can ask better questions of it later and append to it without re-pulling what you have - **Keep the raw file untouched and write a short summary beside it:** the agent reads the cheap summary first and only opens the big file when it needs to, which is the token tax from [Rule 2](#rule-2-keep-it-in-plain-files) finally working in your favour Some of this has a clock on it, too. Search Console [only holds 16 months](https://support.google.com/webmasters/answer/7576553), rolling forward every day, so unless you're piping it into BigQuery for every site you own, the history you didn't save is simply gone by the time you want it. #### Decisions The chat dies when you close the tab, and so does everything you figured out in it. When a session produces a decision, have the agent record it before you move on: - What you chose - Why you chose it - What you ruled out That last one is the sleeper. "What we ruled out" is what stops you, or an agent, cheerfully re-proposing a dead idea three months later. And if a session produced a prompt that keeps working, that isn't a decision, that's the beginning of a skill (hold that thought for [Rule 10](#rule-10-turn-workflows-into-skills)). ### Rule 6: Never destroy context [Rules 4](#rule-4-structure-it-for-search) and [5](#rule-5-save-everything) built the brain. Rule 6 is about not lobotomising it. #### The project contract Every project I run gets the same four files and one folder, no exceptions. I call it the project contract. I'd run my own version of this for a while, a `CLAUDE.md` in every project folder plus a template to fill out, and it worked to varying degrees. Later I restructured it to line up with [Google's Open Knowledge Format](https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing) and [Andrej Karpathy's llm-wiki](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f), in case either becomes a standard, and kept the extra files I'd found useful anyway. Do whatever works for you. - **`index.md`** is the front door: what this is, what done looks like, and a one-line summary of every other file. It's the first thing an agent reads when it arrives in that folder. - **`log.md`** is what happened, dated, session by session. This is the important one, because it makes "what's the state of this project" something an agent reads rather than something a human has to remember. - **`learnings.md`** is what building the thing taught you. This is the file that makes your fifth project sharper than your first. - **`questions.md`** is what you haven't decided yet. I added this one for myself, because chat sessions kept leading me down tangents I felt I couldn't leave unaddressed, like the order of the slides or whether something needed more research. Now they go in this file and I keep moving. - **`raw/`** is the receipts: transcripts, briefs, exports, voice memos. Never edited. The test for all of it is the cold start. If a brand new session rocked up to this folder today, could it work out what the hell is going on? #### The archive, not the bin So the project's finished. What do you do with it? Not delete it. It goes into PARA's archive folder, where the agent reads it as done and leaves it alone unless you ask. Leave it sitting in Projects, and the agent thinks you're still working on it. Delete it, and you've thrown away the exact thing this system exists to hold, and the next agent has less idea of where things got to, not more. ## Connect it You've now got a well-structured second brain. But what good is a brain without a body? That body is your agent harness. Without one, a model can only talk to you. It can think for you, but it can't do anything for you. ### Rule 7: Connect to your vault This is probably the most important step in the whole article: connecting your second brain to your AI agent. Ownership and structure matter, but as I said at the start, they're optional. In fact, once you've done this step you can hand most of the structuring work to the agent anyway. There are a lot of ways to connect an agent to your second brain, and I don't want you thinking of them as a ladder. They're just different doors in, each with their own pros and cons. Pick whichever makes sense for you and get started. #### Local: the one you'll actually use In Obsidian, the brains of the system are just files on your computer. To get started, launch any coding agent like Claude Code, Codex or Antigravity in the second brain folder and start doing work. It'll explore your folder structure and make edits to your files. You don't need any special connectors, and you get all the standard permission controls you've come to expect from a coding agent. You'll soon find this becomes the main project you launch your agent in, especially for anything to do with your day-to-day workflows, planning and ideation. You can still use the second brain while you're working on actual coding projects, though. Most coding agents let you add secondary folders to a project so the agent knows about them, or you can just give it the file path if you only need something in the moment. Most of these coding agents ship a desktop version now, too, so you get what used to be terminal-only in a decent interface for non-developers. #### MCP: for anything that can't touch your files The MCPs from [Rule 2](#rule-2-keep-it-in-plain-files), short for [Model Context Protocol](https://modelcontextprotocol.io/), are how an agent without direct access to that folder gets into your second brain. Connect one to Claude chat or Perplexity, for instance, and they've got tools to work with the vault. The straightforward option is the popular Obsidian [Local REST API](https://github.com/coddingtonbear/obsidian-local-rest-api) plugin, which gets you an MCP server for your vault without building anything. The catch is that it only works locally, so you need to be on the same machine with Obsidian open. For my own vault, I wanted to reach it while I'm out, because that's when I have my best ideas. So I've built something slightly more sophisticated: a persistent HTTP service on my home server, tunnelled securely through Cloudflare and authenticated with OAuth 2.0. That serves a secured remote MCP endpoint, which I add to Claude.ai as a [custom connector](https://support.claude.com/en/articles/11175166-getting-started-with-custom-connectors-using-remote-mcp), which in turn means the Claude mobile app can reach my vault. That's become a lot more powerful since Claude gained the ability to use tools in [voice mode](https://support.claude.com/en/articles/11101966-using-voice-mode). If you want to do this yourself, have a look at a repo like [obsidian-web-mcp](https://github.com/jimprosser/obsidian-web-mcp) and get Claude to help you set it up. #### Cloud storage: for the tools that support neither Again, it's just files, so you can keep your second brain in Google Drive, Dropbox or iCloud Drive. You get the best of both worlds: synced to your computer and your phone, and reachable through a cloud storage connector. Most AI tools ship those connectors by default with nothing to install, including platforms like Gemini and NotebookLM that don't support custom MCPs at all. So your agent can get at the files while you're at your machine, and also on the go, without you messing around building a remote MCP. You do need to be deliberate about which sync method you're prioritising, though. Personally I use Obsidian Sync, which I find a lot more reliable and which doesn't need everything sitting in my phone's local storage. If you're on another default sync method like me, set up a one-way backup to Google Drive instead. That way you can at least read the files on the go, and you're not inviting sync conflicts by letting two systems write to the same folder. #### Version control: backup and history for free Finally there's version control, which has a few upsides, especially if you're building something more collaborative. Create a new private GitHub repo, attach it to your folder as a remote, and you're off and running. It also lets you use [cloud environments](https://code.claude.com/docs/en/cloud-environments) in tools like Claude Code, so you can disconnect your device and pick it up later. The [Obsidian Git](https://community.obsidian.md/plugins/obsidian-git) plugin will automate commits and remote sync for you. It does work on phones, but fair warning: it's janky. Personally I don't want the hassle of managing git on my phone and dealing with merge conflicts. But I do want a private repo available, because some cloud agents work better with GitHub than with the Google Drive setup. So I back my vault up there anyway, because why not. ### Rule 8: Wire in your stack Now that your agent is working in your vault, you can give it access to the tools you use every day, so you never have to copy and paste a data export into a chat window again. There are three main ways to do it, and most tools support at least one, so nothing in your stack is out of reach. #### MCPs: easy reach, context-heavy An MCP wraps a platform's API and hands the agent a description of what each tool does. The agent uses those descriptions to work out which one it needs and what to feed it. Plenty of official MCPs, like Ahrefs, DataForSEO or Notion, are available as remote MCPs or as preconfigured options in your tool's connector marketplace. Others, including some official ones and most community ones, need you to run a local version through Node or Python, which is the case for the Search Console and Google Analytics MCPs. Just remember the token tax from [Rule 2](#rule-2-keep-it-in-plain-files). The more MCPs you install, the more tool descriptions get loaded, and the more context you've spent before you've asked a question. However, you don't have to disconnect them; keep the ones you use constantly enabled and leave the rest switched off until you know you'll need them. #### CLIs: lean and native, but you need a terminal The polar opposite. A CLI is a native terminal application, which is also how coding agents work with your files and folders in the first place. Because the agent can run the CLI directly, the same task usually costs a fraction of what it would through an MCP, mainly because nothing has to load schemas or translate between a structured API and raw text. Most of the major CLIs have agent skills available too, giving the agent clear instructions on how to drive them. Those skills generally cost less than MCP descriptions, because they're lazy-loaded: they only get pulled into the context window when they're actually used. My most-used CLI is the [Google Workspace CLI](https://github.com/googleworkspace/cli), which gives you access to every Google Workspace tool, so Gmail, Docs, Drive and Slides. The trade-off is that it needs a terminal, so it's a local-agent thing rather than something you'll use from your phone. #### APIs: the universal fallback When a tool gives you neither, have the agent write the API call itself, because at the end of the day it's just code. Sometimes that's the better option anyway. Handing an agent an MCP with hundreds of tools and variables is a huge amount of context for no reason. WordPress is a good example. Plenty of people have complained about its lack of MCP support, and while there's been progress there, most people don't need it at all. Most workflows are only ever reading, editing and publishing posts, and the REST API has done that for years. Give Claude the [WordPress REST API Handbook](https://developer.wordpress.org/rest-api/), ask it to help you build a skill for the Posts endpoint, and you're done. ### Rule 9: Run your stack from here The vault is your OS. As I said earlier, you'll find the default place you spin up a coding agent becomes this folder. Your vault turns into your AI operating system, integrated with all the tools you use day to day. Every session loads the context from the sessions before it, and as you work, everything keeps getting saved back in. So, much like your Mac or Windows OS, you're going to want to install apps, which here means connectors, that unlock what the system can actually do. Everybody's setup will look different. Here's mine. #### Productivity stack | Name | Category | Use case | |---|---|---| | [Obsidian Web Clipper](https://obsidian.md/clipper) | Research | One click from the browser, or the iOS share sheet, to save an article into the vault | | [YouTube Transcript API](https://github.com/jdepoix/youtube-transcript-api) | Research | Pulls a YouTube video's transcript in as a note, run through my `/yt-transcript` skill | | [Granola](https://www.granola.ai/) | Meeting notes | Records and summarises calls, notes and transcript both saved | | [Gemini Notes](https://support.google.com/meet/answer/14754931) | Meeting notes | Automatic notes on every Google Meet. Turn the transcript on as well | | [Apple Voice Memos](https://apps.apple.com/us/app/voice-memos/id1069512134) | Transcription | Ideas on the run. Action button remapped from silent to voice memo | | [Wispr Flow](https://wisprflow.ai/) | Transcription | Desk dictation, especially good while AI coding | | [Google AI Edge Eloquent](https://ai.google.dev/edge) | Transcription | Dictation that runs completely locally and offline | | [Notion](https://www.notion.com/) | Task management | Personal tasks and databases, plus anything worth sharing | | [Trello](https://trello.com/) | Task management | Collaborative boards at work | | [Rovo](https://www.atlassian.com/software/rovo) | Task management | Agent access to Jira and Confluence | | [Google Workspace](https://workspace.google.com/) | Collaboration | Gmail, Calendar, Drive, Docs and Slides through the CLI | | [Slack](https://slack.com/) | Collaboration | Team comms | #### SEO stack | Name | Category | Use case | |---|---|---| | [DataForSEO](https://dataforseo.com/) | Research | One connection to a lot of different APIs, including AI search data | | [Ahrefs](https://ahrefs.com/) | Research | Backlinks, keywords and rank tracking, with an MCP included | | [Semrush](https://www.semrush.com/) | Research | Keyword and competitor research, MCP available | | [Surfer](https://surferseo.com/) | Content optimisation | On-page scoring, now with an MCP as well as the API | | [Google Search Console](https://search.google.com/search-console/about) | Analytics and data | Query and page performance through a community MCP | | [Google Analytics](https://analytics.google.com/) | Analytics and data | Official API | | [BigQuery](https://cloud.google.com/bigquery) | Analytics and data | Export GSC and GA into it and you're no longer stuck with the rolling window from [Rule 5](#rule-5-save-everything) | | [Screaming Frog](https://www.screamingfrog.co.uk/seo-spider/) | Crawling | Full site crawls | | [Firecrawl](https://www.firecrawl.dev/) | Crawling and scraping | Scraping and search, clean markdown out the other end | | [Apify](https://apify.com/) | Crawling and scraping | The stuff that's hard to crawl, like LinkedIn or YouTube | | [Crawl4AI](https://github.com/unclecode/crawl4ai) | Crawling and scraping | Open-source crawling built for AI pipelines | | [Claude in Chrome](https://www.claude.com/chrome) | Browser automation | On-page validation in a real browser session | | [Chrome DevTools MCP](https://github.com/ChromeDevTools/chrome-devtools-mcp) | Browser automation | DevTools access for an agent | #### Tech stack | Name | Category | Use case | |---|---|---| | [n8n](https://n8n.io/) | Automation | Logic-based workflows that don't need AI, on a schedule | | [Make](https://www.make.com/) | Automation | Hosted alternative with agent features built in, less technical to set up | | [WordPress](https://wordpress.org/) | CMS and ecommerce | Reading, editing and publishing posts over the REST API | | [Shopify](https://www.shopify.com/) | CMS and ecommerce | CLI and MCP good enough to build the integration instead of buying the app | | [Figma](https://www.figma.com/) | Design | Design files through its MCP | | [Claude Design](https://claude.com/design) | Design | Design work inside the agent | | [Google Stitch](https://stitch.withgoogle.com/) | Design | Wireframing and low-fidelity prototyping | | [Impeccable](https://impeccable.style/) | Design | Taking the AI slop out of generated UI | | [Playwright](https://playwright.dev/) | Visual testing | Headless browser testing from the terminal | | [Claude in Chrome](https://www.claude.com/chrome) | Visual testing | Checking a page the way a person would | | [ChatGPT extension](https://chromewebstore.google.com/detail/chatgpt/hehggadaopoacecdllhhajmbjkdcmajg) | Visual testing | Checking a page the way a person would | | [GitHub](https://github.com/) | Deployment | CLI and MCP, plus the repo the vault backs up to | | [Vercel](https://vercel.com/) | Deployment | Hosting for the more interactive builds | | [Astro](https://astro.build/) | Deployment | The framework behind my own sites | | [Cloudflare](https://www.cloudflare.com/) | Deployment | Tunnels, DNS and Workers through the Wrangler CLI | | [Supabase](https://supabase.com/) | Deployment | Database when something needs one | | [Cloudways](https://www.cloudways.com/) | Deployment | WordPress hosting, has an MCP | | [GoDaddy](https://www.godaddy.com/) | Domains | Buying them | | [Instant Domain Search](https://instantdomainsearch.com/) | Domains | Finding them | ## Automate it Until this point, there is still a large burden on you to feed your second brain the context it needs. You're the one capturing it, filing it and keeping it current, which is fine for a few weeks. But it's also why most people's systems start to fall apart by month two. So the last stage is getting your second brain to feed itself. ### Rule 10: Turn workflows into skills The major challenge of building your second brain is making sure it doesn't become overwhelming. In the beginning, you'll find you have the energy to make sure you're continuously maintaining the system, but eventually you'll find that there are repetitive tasks you keep doing over and over again. Once this starts to happen, the system becomes a chore, and nobody wants to do chores. To simplify the process of creating your own second brain, Tiago Forte also developed a simple four-step method called [CODE](https://fortelabs.com/blog/basboverview/), which stands for Capture, Organise, Distil, and Express. Now that we have that process, we can look for ways to streamline it. There's an old engineering rule of thumb for spotting where to start, the [rule of three](https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)), attributed to Don Roberts and popularised by Martin Fowler: the first time you do something you just do it, the second time you wince at the duplication and do it anyway, and the third time you stop and refactor. Same test works here. Do it once and get on with your day. Notice you're doing it again, and make a note. The third time, write the steps down as a skill and never type it out again. Below I've outlined a few skills that I've created to help me with the repetitive tasks in my vault. None of the skills below do anything particularly clever. They just know where things live, what to do with them and what good looks like. And that's kind of the point: we already know what needs doing, the job is just to cod(e)ify it. | Skill | Stage | What it does | | ---------------- | -------- | ---------------------------------------------------------------------------------------------------------------------- | | `/pull-meetings` | Capture | Imports notes and transcripts from Granola and Google Meet, and files them by date | | `/yt-transcript` | Capture | Saves a YouTube transcript into the vault as a note | | `/voice-note` | Capture | Cleans up a rambling voice memo, asks about the bits it couldn't work out, and files something usable | | `/ingest` | Organise | Empties the inbox and files each item as project evidence or reference, with the frontmatter written | | `/archive` | Organise | Moves a finished project to Archives and writes its closing log entries | | `/daily-note` | Distil | Reads the day's activity across calendar, Slack, Jira, Trello, Gmail and the vault, and writes the daily log | | `/task-roundup` | Distil | Sweeps Jira, Trello, meeting notes and Slack for what I said I'd do, updates I've given and tells me what's still open | | `/blog-post` | Express | Drafts a post outline from vault source material and creates a content pipeline entry | | `/seo-meetup` | Express | Drafts monthly meetup content with key details, event page, LinkedIn post, Slack and X | The meetup skill is one of the clearest examples of what that buys you. For years I've co-hosted a monthly meetup called the [Sydney SEO Collective](https://www.meetup.com/organic-search-sydney/), and every month I need to do the same job: gather all the details, create the event page, write some LinkedIn posts, a Slack message, and an X post. Same process every time, but always a different speaker and content. It used to take an evening, and now it's one slash command that already knows my tone and what I wrote the 100 times before. ### Rule 11: Put your skills on a schedule Ok, so now you've turned the work you repeat into skills, you'll find there are many of these that don't need you at all. Tasks that can be done while you sleep so your next day is even easier. Every morning I want the same thing: what happened yesterday, what I said I'd do and what someone or something needs from me. That's three skills reading four sources, and there's no good reason I need to be sitting there typing them at seven in the morning before my day starts. Instead, my agents review my meetings, tasks, Slack and email, and then use the skills to write a daily brief into the vault. I read it with a coffee instead of opening thirty tabs to work out where I'm at. You can do this with Claude's [scheduled tasks](https://code.claude.com/docs/en/scheduled-tasks), or with cron on a machine that's always on. For my personal vault I've got a Hermes Agent that does this and also goes out looking for whatever's happened in AI and SEO, and drops a digest into the vault, so I don't end up scrolling through LinkedIn. ![Flow from meetings, tasks, Slack and email, through scheduled skills (/pull-meetings, /task-roundup, /daily-note), to a daily brief in the vault that you read with a coffee](./_attachments/ai-second-brain/morning-brief.png "The morning brief, written while you sleep.")

The morning brief, written while you sleep.

### Rule 12: Audit it Everything up until this point has been about adding. This last rule is about taking away. Over time, a second brain deteriorates the same way a website does. It gets bigger, it gets stale, and eventually it starts contradicting itself. And the one file that steers every agent is the one nobody ever thinks to go back and read: the `AGENTS.md` or `CLAUDE.md` from [Rule 4](#rule-4-structure-it-for-search). This file functions as a persistent user message injected at the start of a session. Which, if we remember back to the context diagram at the start, is where attention is most focused. That makes it the most valuable file you have and the easiest one to quietly wreck. It helps to notice that the file is doing two different jobs at once. Some of it is facts: where things live, what each folder is for, which board you mean when you say "my to-do list". No model is ever going to work that out on its own, so all of that stays. The rest of it is rules. Write like this, don't touch that, use this skill when you see that. And rules have a shelf life, because most of them were written to correct a model that has since got better at the thing you were correcting. So you're probably overdoing it. The awkward part is that you can't tell which lines are still earning their place by reading them, because they all look reasonable and you wrote every one of them for a reason at the time. The only honest test is to take them out and see what the model does without them, then add back the ones that actually break something, and only once you've watched it go wrong twice. That sounds drastic until you see how far the people building this stuff take it. When Opus 5 shipped, the Claude Code team deleted around 80% of their own system prompt. Not because any of it was badly written, but because so much of it had been correcting behaviour that the model now simply gets right. Boris Cherny's advice for the rest of us was blunt enough that I wrote it down: > "For people that aren't building agentic products, but are using Claude Code, every six months, delete your CLAUDE.md, delete your skills, delete your hooks. See what the model does and it might surprise you."