How I built a second brain

I joined Ascend as COO 8 months ago. This is a company generating >$25M ARR, operating a 24/7 travel concierge for some of the world's most demanding clients, with a team of 80+ spread across several continents. It was a big step up for me personally.

I am not a naturally organised person. I've forced myself to become more productive over the years using every tool on the market. Pre-AI, I was always trying new productivity stacks — Todoist and Things for tasks, epic Notion boards for docs, my inbox carved up into a crazy number of folders. Post-AI, I tried most of the productivity tools that added an AI layer — Notion AI, Asana AI, a dozen others. Next to Claude Code, they all feel like toys.

Over the last 12 months I've been evolving my own second brain. My goals were simple:

• Never lose an important piece of information.
• Never forget an action item.
• Walk into every meeting fully briefed without spending hours preparing.
• Know what I need to focus on today above all else.

Today, a markdown brief waits for me in my Obsidian vault before 8am every morning. It looks like this:

Every meeting I am in, and there are 15 to 25 a week, gets listened to, summarised, and routed. My personal action items land in Google Tasks. Team action items become Asana tickets, assigned to the right owner. Every evening, a final pass reads the day's transcripts, catches any action items I missed, updates the wiki pages for the people I spoke to, and queues any follow-up messages I need to send tomorrow.

Underneath, it is a folder of markdown files and a few Python scripts.

Here's how it works.

The pattern

A good second brain does three things.

The thinking is borrowed from an incredible community of Claude Code tinkerers. Andrej Karpathy's LLM Wiki. Noah Brier on Dan Shipper's AI & I podcast. Garry Tan's GBrain. I have merged their ideas into something that fits me.

Most people I have shown it to get intimidated and assume it is too complex to set up. It is not.

1. Listen

Every night while I sleep, a handful of small Python scripts run on my machine. Each one connects to a different source, pulls the day's new activity, and writes it to an archive folder in my Obsidian vault.

Each script writes its output as a plain markdown file, named by date and source, into a folder the system will read from but never edit. If I ever want to go back to a raw transcript or an original email, it is there in its original form.

The reason this matters: manual capture is the single biggest failure mode of every second-brain system I have tried. I forget to tag things. I forget to clip pages. I forget to write things down. Automating the capture entirely removes me as the point of failure.

A note on volume, since the raw folder grows quickly. Nothing in it gets loaded into Claude's context at query time. It is an audit trail, not working memory. The organise step reads each new file once, writes its summary into the wiki, and from then on everything that matters about that file lives on the wiki page, not in the transcript.

2. Organise

Raw transcripts and threads are noise. Nobody wants to scroll through 14,000 words of a ninety-minute Granola transcript to remember what Sarah committed to on Tuesday.

So once the nightly capture finishes, another script runs — a Claude Code skill that reads every new raw file and updates the relevant Wikipedia pages in my vault. Here is what it does for each new file, in order:

1. It scans the file for the entities that appear in it: people, topics, companies, projects.
2. For each entity, it finds the corresponding wiki page, or creates a new one if the entity is new to me.
3. It updates the page following a fixed structure — the same shape every time.
4. It adds cross-links from the updated page back to every other page it mentions, so the graph keeps tightening.

The pattern itself is Andrej Karpathy's, simplified. The archive folder is sacred — the LLM reads it but never edits it. The wiki folder is fully LLM-owned, and gets rewritten every night. A schema file at the root of the vault (in Claude Code this is called CLAUDE.md) defines the rules: when to create a new page, how to cross-link, what never to do. That schema co-evolves with the system as I use it.

A quick note on cost, since I get asked. The organise pass does not re-process everything every night. A cheap classifier (Haiku-class) triages each new raw file first, deciding which wiki pages actually need updating. The expensive synthesis pass only runs for those pages. Queries at read time hit the pre-synthesised wiki, not the raw archive, so the context stays small. The monthly bill ends up small enough that I do not budget for it.

Why a Wikipedia and not a vector database

Most second-brain systems today use vector search. They stuff everything into an embedding database and retrieve chunks at query time. That approach scales, but it is brittle for personal knowledge. It loses context. It can't be read by a human. And it does not compound — every query is a fresh search into the raw corpus.

The Wikipedia pattern is the opposite. Every piece of knowledge is pre-synthesised into a human-readable page. Pages link to each other. When new information arrives, the system does not retrieve chunks, it rewrites the relevant pages.

The cost is write-time compute. Every new meeting triggers a pass that updates several pages. The benefit is read-time simplicity. When I want to know what I know about someone, I open one page and read it. Reading my wiki feels like reading a real Wikipedia about my world.

The entire vault is browsable as connected notes through Obsidian. The knowledge graph image at the top of this post is the actual graph.

3. Surface

This is where the system stops being about knowledge and starts being about getting things done.

Every morning at around 7:45am, another Claude Code skill runs. It generates the markdown document you saw at the top of this post and drops it into my inbox folder. The filename is today's date. The contents are pulled from four places: my calendar for today, my inbox, my wiki, and my task system. I open it when I sit down with coffee.

The brief is interactive

This is the single most important part of the whole setup.

The brief is not a static report I read and close. It is a shared working document between me and Claude Code, edited back and forth across the day.

I read through it and leave comments on each section, the way you would leave comments on a Google Doc or a Notion page. "Yes, draft that reply, but say we can meet next Wednesday." "Move this task to tomorrow." "Ask Priya for her number on this." "Skip the 3pm, I'm blocked." I tick off tasks I have already handled. I answer any clarifying questions Claude has left me.

When I am done, I tell Claude Code in the terminal that I have finished editing. It reads my edits and goes off to execute. By the time I am out of the shower, the replies I asked for are sitting in my Gmail drafts, the calendar invites I requested are sent, the tasks I ticked off are closed in Google Tasks, and anything I was not sure how to answer is surfaced in a follow-up brief later in the day.

It feels just like working with a real human assistant.

The rest of the daily loop

The morning brief is the entry point. From there, a handful of other skills take over through the day.

None of this is ever sent on my behalf without approval. Every email draft lands in my Gmail drafts folder waiting for me to review. Every outbound message sits as a task for me to fire off.

Guardrails

A few Claude Code hooks run quietly in the background, regardless of what I am working on.

The boring but necessary ones: any destructive bash command like rm -rf or git push --force gets blocked before it runs. Any write to an external API (sending an email, posting to Slack, creating a calendar invite) requires my explicit approval before it fires. Slack is hard-wired read-only — the system can read every thread but it cannot post on my behalf, ever.

The more interesting, second-brain-flavoured hooks, some running and some I am still adding:

• When I write a new note, it auto-links any person or topic I mentioned to their existing wiki page, so the graph tightens without me thinking about it.
• If a new note ends up with no links in or out of it, it gets flagged as "isolated" in the next morning's brief, so nothing quietly drifts off the map.
• Before a new query runs, the system checks whether I already wrote about the topic months ago, and surfaces the old note. This stops me rediscovering ideas I already had.
• When a daily note gets touched enough times, it graduates into a permanent Wikipedia entry, so fleeting thoughts become permanent knowledge only when usage justifies it.

Results after six months

What is still hard

The system is good at reading but imperfect at writing in my voice. Every email draft gets a human pass before it goes out. Every LinkedIn post, including this one, goes through three revisions before it reads like me. That is fine for now, but the bar keeps rising.

The bigger open problem is onboarding other people. Most people get intimidated by the setup and never start. To fix that, I have collapsed the whole pattern into a single markdown file you can paste into Claude Code to bootstrap your own version. It scaffolds the folder structure, the starter skills, and the hooks. You bring your own inputs.

If you build your own version, drop me a note at hi@omarismail.com.