How I Built a Second Brain

I joined Ascend as COO 8 months ago.

Ascend is a 24/7 travel concierge for some of the world's most demanding clients. We are at >$25M ARR with a team of 80+ across several continents. It was a big step up for me personally.

I am not a naturally organised person. I have forced myself to become more productive over the years using every tool on the market.

Pre-AI, it was 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 have 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 single markdown document is waiting for my review every morning before 8am. It has today's priorities, draft replies for the emails and Slacks that matter, and a plan for anything I want handled while I am not at my desk.

It looks like this:

From there, the logistics take care of themselves:

• Every meeting I am in (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 catches anything I missed, updates the relevant wiki pages, and queues any follow-ups for tomorrow.

It sounds intimidating. It is not. Underneath, it is just 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, and Garry Tan's GBrain. I have merged their ideas into something that fits me.

1. Listen

Every night, a handful of scheduled Claude Code routines run in the background.

Each one is a small cron-style job that connects to a single source, pulls the day's new activity via its API, and writes the result into an archive folder in my vault.

Granola

Meeting transcripts

Fireflies

Backup transcripts

Gmail

Email threads

Slack

Channel + DM history

WhatsApp

Personal + group chats

Calendar

Events + invitations

Nothing else touches this folder. If I ever want to go back to a raw transcript or an original email, it is there, untouched.

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.

2. Organise

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

So once the nightly capture finishes, another script runs. It reads every new raw file and updates the relevant pages in my wiki. For each new file, it does four things:

1. Scans for the entities that appear in it: people, topics, companies, projects.
2. Finds the corresponding wiki page, or creates a new one if the entity is new to me.
3. Updates the page following a fixed structure — the same shape every time.
4. Adds cross-links back to every other page it mentions, so the graph keeps tightening.

The pattern is Andrej Karpathy's, simplified. A schema file at the root of the vault (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.

But doesn't this consume a ton of tokens?

No. Two things keep the cost low.

First, the archive is never loaded into Claude's context when I ask a question. It is an audit trail, not working memory. Queries read the pre-synthesised wiki pages, which are short.

Second, the nightly organise pass does not re-process everything. A cheap classifier (Haiku-class) triages each new raw file first and decides which wiki pages actually need updating. The expensive synthesis only runs for those pages.

The monthly bill is a Claude Code Max subscription.

Why a Wikipedia and not a vector database

Most second-brain systems today use vector search: stuff everything into an embedding database, retrieve chunks at query time. That approach scales, but it is brittle for personal knowledge.

It loses context. It cannot be read by a human. 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 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 skill runs. It generates the markdown document you saw at the top of this post and drops it into my inbox folder.

The contents are pulled from four places:

• My calendar for today. What is on the schedule, what I need to prep for, what is optional.
• My inbox. Emails worth reading this morning, sorted by importance, noise filtered out.
• My wiki. Context on anyone I am meeting today and any topic that is coming up.
• My task system. Today's priorities from Google Tasks and Asana, plus anything overdue.

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.

The whole vault lives in Obsidian, which renders the markdown beautifully and has a commenting system built in. Obsidian Sync mirrors the vault across all my devices in real time, so the brief is just as editable from my phone on the train as it is from my laptop.

I read through the brief and leave comments on each section, the way you would leave comments on a Google Doc or a Notion page:

I tick off tasks I have already handled. I answer any clarifying questions Claude has left me.

Then I tell Claude in the terminal that I am done. 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.
• 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 small rules run quietly in the background, regardless of what I am working on.

The boring, necessary ones:

• Destructive commands like rm -rf or force-pushes get blocked before they run.
• Any write to an external service (sending an email, posting to Slack, creating a calendar invite) needs my explicit approval.
• Slack is hard-wired read-only. The system can read every thread but it cannot post on my behalf. Ever.

The more interesting ones, 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 wiki entry, so fleeting thoughts become permanent knowledge only when usage justifies it.

So have you automated your entire work life?

No. I have not.

I have streamlined it.

What this actually gives me is the ability to offload massive parts of my day — the repetitive work, the context-gathering, the first-draft writing, the logistics — to Claude Code. That frees me up for the two things that actually need me: planning and review.

I now spend roughly 90% of my time in those two modes. I plan: figure out what needs doing, frame the ask, set the constraints. I review: read what Claude has drafted, correct it, ship it. Everything in between — the execution — runs in the background, often on multiple projects in parallel.

The efficiency gain is enormous. I can run more projects at once than I ever could before, and I ship with tighter quality than I used to because I am spending my attention on the parts where attention actually helps.

But nothing about this is fully automated. Every email still gets a human pass before it sends. Every draft gets my edits before anyone sees it. Every important decision still sits with me. The system is an assistant, not a replacement — and the moment I start trusting it to act on my behalf without review is the moment it stops working.

Build your own

If you want to try this, I have collapsed the whole pattern into a single markdown file you can paste into Claude Code. It scaffolds the folder structure, the starter skills, and the hooks. You bring your own inputs.

If you do end up building your own version, drop me a note at hi@omarismail.com.