MetaNova V3: how my second brain is actually built

Three weeks ago I rebuilt my second brain from scratch, after deleting two earlier versions in one morning. I've written about that day in Deleting my second brain twice in one morning. This piece is about what came out of it: MetaNova V3, how it's put together, and what happened when I filled it with my real work last week.

I'm writing it now, at 24 March, because it's the first time the design has carried real weight. It's no longer a tidy empty structure. It holds my ventures, contacts and decisions, it runs my morning coaching, and since Friday I can talk to it over WhatsApp.

Why V3 is shaped the way it is

V3 was built by running ten published design skills in order, each committed separately, against my own context. The skills come from Muratcan Koylan, who shared his own setup and the method behind it openly. Each skill answered one question about how an AI should read and remember a body of work. How much should it load at once? How should memory be stored so it doesn't get corrupted? How do you stop one area of work bleeding into another?

The answers shaped everything below. I'll go through them as they actually exist in the folder, because I think the structure is more useful to see than to describe in the abstract.

Three levels of instructions

The biggest problem with my first attempt, Bobble, was that the AI read too much before I'd asked anything. By February its start-up routine used 46% of its working memory. I wrote about that in Bobble: my first go at a second brain.

V3 fixes this with three levels, and a rule about how to move between them:

• Level 1, always loaded. Two files: an overview (CLAUDE.md, the file Claude Code reads first) and a rules file (AGENT.md) with the core rules, a routing table and an index of what's where.
• Level 2, loaded per task. One instruction file for each area: identity, network, ventures, memory, content and so on. Each is named after its folder, like IDENTITY.md or NETWORK.md.
• Level 3, loaded on demand. The actual data: contact lists, decision logs, venture status files.

The rule is written into the rules file in plain words: never load a level 3 file without first reading its level 2 instructions, and never load all the level 2 files at once. So if I ask for help preparing for a meeting, the AI reads the network instructions and then searches the contacts, without touching my content plans or legal work.

The routing table is a list of "when Adrian asks for X, do Y". Morning check-in runs the coach. Prepare for a meeting with someone checks the contacts and past interactions. Log a decision appends to the decision file. It's not clever, and that's the point. The AI doesn't have to work out where things live.

The seven core rules

This is the part I'd copy first if I were starting again. The rules file opens with seven rules, and I'll give them as they're written:

1. Always read the relevant area's instruction file before operating on its data. Never guess at structure.
2. Append to JSONL files, never overwrite. Archive by marking an entry "archived" instead of deleting it.
3. Update timestamps when changing tracked data.
4. Cross-reference by file path, not by copying content.
5. State the active area before every file operation. If you can't name one, break the task down.
6. Source and confidence are mandatory on every memory entry.
7. Load one venture at a time, never all of them.

Rule 2 needs a word of explanation. JSONL is a plain text file with one record per line. The first line of each file describes what the records look like. New records go on the end. Old records are never rewritten. If a decision is reversed, that's a new record saying so, and the original stays where it was.

This is the direct answer to Bobble's wall. Bobble's memory files were documents that the AI rewrote and extended, so they only grew and nothing was ever clearly history. A log of dated records can be read from the end. The AI looks at the last ten decisions, not all of them.

Rule 6 is the one people ask me about. Every entry in the memory files has to say where it came from (a meeting, an email, something I said, an extraction run) and how confident it is. An AI will repeat a guess in exactly the same tone as a fact. If something it tells me turns out to be wrong, I can follow it back to the entry, see the source and see whether it was marked as a guess.

What's in memory

The memory folder holds a few separate logs, each with a different job:

• decisions: what was decided, when, and why
• experiences: things that happened and what I learned
• failures: what went wrong, the root cause and how to prevent it
• entities: durable facts about people, tools, projects and ideas

There's also a recovery procedure in the rules file that I've found surprisingly useful. It names four ways a long AI session goes wrong: confusion (mixing up areas), poisoning (a wrong fact spreading), distraction (too much irrelevant detail) and lost-in-the-middle (forgetting the task). Each has a fix. If the fix doesn't work, start a new session and log what happened as a lesson. Having names for these makes it much easier to spot them.

17 March: loading the real thing

For two weeks after the rebuild, V3 was a structure with placeholder content. On Tuesday 17 March I filled it. Over about five minutes the AI committed four phases of data population, drawing on an extraction I'd run earlier across my email, messages and documents.

The memory phase alone loaded:

• 1,393 decisions, pulled from the history of my past AI sessions
• 5,272 durable facts about people, tools, projects and concepts
• 7 key experiences with the lessons from each
• 6 documented failures with root cause and prevention
• 27 tools, with their real status and notes

Five ventures got their own status files. My identity and brand files were filled from real material. The contacts went into the network area.

That evening I built a venture-focused morning check-in, then rebuilt it three times in an hour and a half, each time pulling in more of the performance coach I'd used every day in Bobble. The next day I gave up on the hybrid and moved the coach itself across. It knew how to ask how I was doing, and it now reads across all my projects.

18 March: a log for work in progress

On the 18th I hit a problem I hadn't planned for. I often run several AI sessions in parallel, one on legal work, one on a venture, one on admin. They were all writing their "where I've got to" notes into a single scratchpad file, and they were overwriting each other.

The fix followed rule 2. Work in progress now lives in its own JSONL log called workstreams. Each session appends an entry when it stops, with a summary and a prompt for the next session to pick up from. No session ever rewrites another's entry, so parallel sessions can't collide. The next day I logged over sixty workstreams into it, which was the first time I'd had everything I was juggling in one place.

The same day I turned on a tool called Entire, which records each AI session and links it to the commit it produced. If I want to know why something changed, I can replay the session that changed it.

20 March: one home for skills

A skill, in this setup, is a written procedure the AI follows for a recurring job. Drafting an email in my voice is one. Scoping a legal fee is another. Coaching me in the morning is a third.

By March I had skills spread across three projects: Bobble, MetaNova and a third project called Meta that coordinated the other two. The same skill could exist in two places and drift apart. On Friday 20 March I moved them into one shared skills folder that every project reads from. At 11:49 the first commit moved 42 skills. Half an hour later it was 53, sorted into 10 categories.

Then I ran an audit against Anthropic's published guide to writing skills. Of 67 skills checked, 23 met the standard and 44 needed fixes: wrong names, files in the wrong place, scripts that pointed somewhere else. By the end of the day, 64 of 67 passed. The fixes were mostly boring, which is how you know the audit was worth doing.

20 March: talking to it over WhatsApp

The same afternoon, I built a small WhatsApp connector, about 200 lines of code, using a new feature in Claude Code for receiving messages from outside. It means I can send a message to a dedicated WhatsApp group and get an answer from the same AI that has my files, skills and memory.

That evening I ran my wind-down coaching session over WhatsApp instead of at my laptop. It's early, but it already feels like a bigger change than any of the structure above. A second brain that I can only reach at my desk is still a desk tool.

What's not right yet

It would be a bit rich to write all this without saying what's wrong with it.

My own notes are in the rules file. Next to the routing table I've written that it's too specific and won't scale: it lists individual tasks rather than general patterns. The same note sits next to the multi-area procedures. And the file index in the overview duplicates the better one in the rules file. All three are on my list.

There's also a lot of documents still in the repo for me to read rather than for the AI. I've started filing them in one dated folder, but the honest answer is that the repo is half a store for the AI and half a document store for me, and those pull in different directions.

If you're structuring your own files

You can do the core of this with an ordinary folder and a text editor. No code needed.

1. Write a one-page overview and a one-page rules file. These are the only two files the AI should read every time.
2. Give each area of your work its own short instruction file. Say what's in the folder, what the files mean and how to update them.
3. Keep anything that changes as dated entries in a log. Decisions, lessons, work in progress. Add to the end, never rewrite.
4. Make the AI say where each fact came from. And how sure it is. It takes seconds and saves hours.
5. Put your recurring procedures in one place. One copy of each, so they can't drift.

If you'd like a hand working out what your own version of this looks like, let's have a chat.