The Second Brain That Works While You Sleep

For most of my adult life I have been a bad note-taker in a very specific way. Not the kind of bad where you take no notes — I take too many. Voice memos recorded from a moving auto-rickshaw in Kochi. Browser tabs left open for six months as a proxy for intention. Obsidian files named “capture 2024-11-03” that never got touched again. A folder called “IMPORTANT READ THIS” in my iCloud that has 340 items in it and I have read approximately none of them.

The problem was never capture. The problem was processing. A note you dump and never revisit is not a second brain. It’s a second landfill.

I tried the usual fixes. Getting Things Done. Roam Research. Tiago Forte’s PARA. Zettelkasten the proper German way. Some of these helped in bursts. None of them scaled to the way I actually live — across Kerala, Bangalore, Dubai, and periodically Vietnam, running parallel projects at Zero, fielding late-night ideas about education systems that I’ll forget by morning. The labor of processing notes is non-trivial. And labor doesn’t scale when it’s just you.

So I built a system where the labor runs without me. A local agent swarm that processes what I dump during the day, while I sleep, and leaves a morning briefing I can actually read. Here’s what it looks like, how I built it, and — because this is the part no one tells you — where it breaks.

The Architecture: Specialization Over Generalism

The system I settled on has five agent roles. Not one smart agent doing everything. Five dumb-ish agents doing specific things, in sequence, with handoffs between them.

The Scout reads everything that landed in the inbox folder since its last run. Raw clips, PDFs, voice-memo transcripts, pasted URLs, half-sentences I typed at 1am. Its only job is to fetch any missing sources — if I dropped a link, it retrieves and saves the content. No source, no note. That’s the prime directive, and the Scout enforces it at step one: if it can’t retrieve a source, it flags the item rather than processing it.

The Cataloger turns raw captures into atomic notes. One idea, one note. If a raw capture contains three distinct claims, it becomes three notes. Each note gets a unique ID, a title that is a statement (not a vague topic), a body of three to five sentences maximum, and a source: field that must be populated. This is pure Zettelkasten mechanics, and I am not going to pretend I invented them — Niklas Luhmann had this figured out before I was born.

The Cartographer links things. It reads the atomic notes the Cataloger produced and compares them against the existing vault. It looks for conceptual connections and writes bidirectional links using Obsidian’s [[note-title]] syntax. It also generates a short synthesis thread when three or more notes converge on the same concept — a paragraph-length “here is what these ideas have in common” that I review manually before it gets promoted.

The Critic is the one I am most glad I added. Its only job is to read the atomic notes and flag contradictions — places where a new note conflicts with an existing note in the vault. It writes a [FRICTION] comment directly into the note file. Not a deletion. Not a resolution. Just a flag for me to decide.

The Editor writes the morning briefing — a short Markdown file, never longer than one page, that summarizes what the swarm processed, what new links were found, what the Critic flagged, and what synthesis threads were added. It also lists items the Scout couldn’t fetch, so nothing disappears silently.

What a Processing Cycle Actually Looks Like

Let me show you a real example from last week, slightly compressed.

Raw capture, dropped into inbox at 11:47pm:

“YC essay — founders are not sales-averse, they are embarrassment-averse. The fear is not rejection, it’s looking like you care and being told no. Different diagnosis, different fix. Link: https://paulgraham.com/…”

The Scout fetches the essay, saves the full text as a sidecar file in /sources/. The Cataloger reads both my note and the source, then produces:

---
id: 20260614-0047
title: Founder sales reluctance is embarrassment aversion, not rejection aversion
source: [[sources/pg-do-things-that-dont-scale-2013]]
stage: atom
---

Paul Graham distinguishes between fear of rejection and fear of embarrassment in early sales.
The argument is that founders avoid sales not because they expect refusal but because caring
visibly and being told no feels like public failure. This reframes the problem: the fix is not
confidence coaching but recontextualizing what rejection means. A no from a stranger is data,
not judgment.

The Cartographer notices the vault already has a note titled “Rejection-sensitive founders avoid product feedback loops” from a Marc Andreessen interview I processed two months ago. It writes a bidirectional link between the two. Then it surfaces a synthesis thread because there’s a third note — one I made from a Lenny Rachitsky podcast about why first-time founders oversell in demos — that maps to the same underlying pattern.

The Critic checks the atom against existing vault notes and finds one from a different source that claimed “founders avoid sales because of low confidence, not fear of embarrassment.” It writes:

[FRICTION]: Conflicts with [[20251102-sales-confidence-claim]]. That note attributes
avoidance to general low confidence; this note attributes it specifically to embarrassment
as a social emotion. These may be compatible but need reconciliation. Human review needed.

I see this in my morning briefing. I go look at both notes. I decide the embarrassment framing is more precise and update the older note accordingly, citing both sources.

This is the thing the system cannot do for me: decide what is true. It can surface the tension. The resolution is mine.

The Folder Structure and Staging Layers

The vault is organized by refinement stage, not by topic. I cannot stress how much this matters. If you organize by topic, you create premature taxonomy — you’re forced to decide “is this note about psychology or about sales?” before you understand it well enough to categorize it meaningfully. Organizing by stage lets you defer that decision until the note has earned its place.

/vault
  /0-inbox          ← raw drops, untouched
  /1-atoms          ← atomic notes, Cataloger output
  /2-threads        ← synthesis threads, Cartographer output
  /3-reviewed       ← human-reviewed notes I've touched
  /sources          ← fetched source content
  /briefings        ← nightly Editor output
  /audit            ← weekly audit logs

A note only moves forward when it’s ready. The swarm only moves things from 0-inbox to 1-atoms. It never promotes anything to 3-reviewed — that’s a human gate. The Editor’s briefing every morning is my prompt to do the five-minute review that actually closes the loop.

The House Rules Charter

The agents all read a short Markdown file called CHARTER.md at the start of every run. It has six rules:

1. No source, no note. If a claim cannot be traced to a retrievable source, it gets flagged, not processed.
2. One idea, one note. Split ruthlessly. Compound notes are not allowed.
3. Flag, don’t delete. Contradictions get [FRICTION] tags. Nothing is deleted without human confirmation.
4. Ask before touching 3-reviewed. The reviewed folder is human territory. Agents write to it only with a pending confirmation that must be approved before the next run.
5. Commit before and after every run. The vault is a git repo. The swarm runs git commit at the start of its run (snapshot of state before processing) and again at the end. If anything goes wrong, I can roll back to any point.
6. Weekly audit. The Editor generates a full audit log every Sunday: total notes processed, FRICTION flags resolved vs. pending, synthesis threads promoted vs. still in draft, Scout failures. I read this. If the numbers look wrong, I investigate before the next run.

Rule 1 is the prime directive and the most important guardrail I have. Without it, a well-intentioned agent will hallucinate citations, synthesize claims that were never in any source, and slowly corrupt the vault with confident nonsense. The rule is binary: source is there, or item does not move.

The Technical Setup

The swarm runs locally on my M3 MacBook Pro. I’m using Claude as the model for the orchestration and synthesis steps — specifically the Sonnet tier for the Cataloger and Critic (fast, cheap, accurate enough for atomic-scale reasoning) and Opus for the Cartographer’s synthesis thread generation, where I want deeper conceptual connection-making.

The agents are wired together with a simple Python orchestrator that I wrote in an afternoon. It reads the CHARTER, runs each agent in sequence, passes the output of one as context to the next, and handles the git commits. There is nothing exotic here. The orchestrator itself is about 300 lines.

The whole thing is exposed to other tools via MCP — Anthropic’s Model Context Protocol. This means my vault is mounted as a resource that other agents can read and write to with permission. When I’m doing research for Zero, I can point a research agent at the vault and ask “what have I already captured about this?” before it goes and fetches new sources. The vault becomes an input to downstream work rather than just an output of daily capture.

The schedule is a cron job. It runs at 2am, finishes by 2:30, and the morning briefing is waiting when I open my laptop at 7. On nights when I’ve dumped a lot (sometimes 30-40 raw captures after a long day of calls and reading), it runs a little longer. On light days, 10 minutes.

For people who want an off-the-shelf local desktop agent rather than building their own orchestrator, tools like Kimi Work — Moonshot AI’s local desktop agent that can mount folders and drive browser sessions — show where this category is heading: agents that run directly on your machine, touch local files, and can be scheduled to run at specific times. The gap between “build your own” and “configure an off-the-shelf tool” is closing fast in 2026. I built mine because I wanted fine-grained control over the CHARTER and the folder structure. Most people probably don’t need to go that far.

What Breaks (And When)

I said I’d tell you where this falls apart. Here it is.

The Scout fails on paywalled sources. If I paste a link to a Financial Times article I read on my phone, the Scout cannot retrieve it. The item gets flagged, not processed. This is correct behavior per the CHARTER, but it means I have to go back and manually paste the relevant excerpt before the note can move forward. I’ve added a habit: if it’s paywalled, I copy the key passage before I drop the link. But I forget sometimes.

The Cataloger creates atom granularity inconsistently. Sometimes it splits one idea into three notes where two would be better. Sometimes it merges what should be two ideas into one. The inconsistency isn’t random — it tracks the ambiguity in my original capture. If I write a clear, focused note, the Cataloger performs well. If I write a rambling 200-word brain dump, it guesses at my intent. The output quality is a direct function of my input quality. This is not a bug in the agent. It’s a bug in me.

Synthesis threads go stale. The Cartographer creates synthesis threads that are accurate the day they’re written and become slightly less accurate as new notes add nuance. I don’t have an automated way to refresh a synthesis thread when its constituent atoms are updated. Right now I do this manually during the weekly audit. It’s on my list to build an agent pass for this, but it’s not done yet.

The git commit occasionally fails when there’s a merge conflict from a note I edited manually during the day while the swarm was processing something related. This has happened three times. Each time I’ve resolved it manually, and each time it took about fifteen minutes. The fix is to not manually edit notes during the swarm’s processing window. I now treat 2am-3am as a read-only window for the vault.

The FRICTION flags pile up if I don’t review them. I went two weeks without properly reviewing the morning briefing (I was in Vietnam, the schedule was off). I came back to 23 unresolved FRICTION flags. Working through them took a Sunday afternoon. This is the maintenance cost that the system cannot eliminate — it can only make the cost explicit and deferred rather than invisible and accumulated.

The Deeper Why

I have tried to explain to people why I built this instead of just hiring a research assistant. The honest answer is that the value isn’t in the output — it’s in the structure the system imposes on my own thinking.

When you know that everything you capture will be processed against everything you’ve ever captured, you start to capture more carefully. You write the note in a way that will make sense to an agent that has no context for what you were thinking when you wrote it. That discipline makes the note better for you, not just for the system. It’s the same thing that happens when you know code will be reviewed — you write cleaner code, not because the reviewer is watching but because the expectation of external reading changes how you think about what you’re producing.

The contradiction surfacing is the feature I value most. I hold a lot of beliefs that are inconsistent with each other. I don’t think this is unusual — most people do. But most knowledge systems let you accumulate inconsistencies without ever showing them to you. The FRICTION flag doesn’t resolve the inconsistency. It makes me look at it. That’s all. But that turns out to be most of the work.

I ran fifteen-plus startups before Zero, and the common failure mode across most of them was not lack of ideas. It was ideas accumulating without ever being confronted by each other. Things we believed in one context that would have immediately died if tested against things we believed in another context. A system that surfaces tension is more valuable, to me, than a system that tells me what to think.

The morning briefing is now genuinely the first thing I read. Not my email. Not my Slack. The briefing. Because it’s the only document I receive that was built specifically for what I was thinking about yesterday, organized against everything I’ve been thinking about for years, with the contradictions already flagged. It’s the closest thing I have found to waking up with a smarter version of last night’s thinking already done for me.

The labor, finally, scales. The ideas can compound the way they always should have.

---