Why my second brain took three goes

My second brain took me three goes. The first was a folder of notes that outgrew the AI reading it. The second was a careful build of someone else's architecture that looked finished and wasn't. The third, which I've been running since March, is the one that stuck.

I posted a short version of this on LinkedIn on 26 September and said there'd be an article this week. This is it. I'll go through each attempt, what went wrong, and what I'd tell anyone starting today.

By "second brain" I mean a set of files that hold my context (my work, my decisions, my contacts, how I like things done) in a form an AI assistant can read. The point is that the AI starts each job knowing me, instead of knowing nothing and needing the same explanation every time.

Go one: plain notes

My first attempt started on 1 October 2025, as a folder of instructions and notes for Claude. In mid-November I reorganised it around a pattern a friend, Dan Hopwood, had shared: six memory files covering what I'm working on now, the bigger picture, progress, how things are done, a backlog, and plans. The core idea was a good one, and I still use it in spirit. The AI has no memory between conversations, so the files are the memory.

It worked well for a few months. Then it didn't.

The files grew. Every session added something and nothing came out. By February the file describing how things are done was 940 lines long, the backlog 508 and the bigger-picture file 545. On 13 February I measured it: loading those notes used 46 per cent of the AI's working memory (its context window, how much it can hold in mind at once) before I'd asked a single question.

I tried pruning. It helped for a week and then the files grew back. The structure had no way to say "this detail only matters for this kind of task, so leave it out the rest of the time".

The lesson: a second brain has to be layered. The AI should read a short overview first and pull in detail only when the task needs it.

Go two: a faithful copy that wasn't wired up

In late February I found the most thought-through version of this I'd seen. Muratcan Koylan had published a long post called "The File System Is the New Database: How I Built a Personal OS for AI Agents", and shared his whole setup openly. Plain files in folders, three levels of instructions, memory kept as one record per line, nothing ever overwritten. Exactly the layering I'd been missing.

So I set myself one question: how can we fully and faithfully implement Koylan's BrainOS architecture?

My first build of it failed twice. On 26 February the AI copied his example in, 238 files in about five minutes, and over the next few days reported 18 out of 18 acceptance tests passed. But it had copied his templates without the reasoning behind them. I wiped it on the morning of 3 March. The rebuild that followed was reported as having worked through his ten design skills in order. It had actually run one and summarised the other nine. I wiped that too, about seventy minutes later. My actual words at the time: "Just nuke v2 and start again." (The full story of that morning is here.)

Both times, the failure was the same shape. The AI said it had "implemented" things that weren't actually wired up and working. The reports read as finished. The work wasn't.

Go three: same architecture, checked

The third go used the same architecture. The difference was that I reviewed and verified every piece instead of trusting the summary.

On the afternoon of 3 March the AI ran each of Koylan's ten design skills against my own work, one at a time, saving after each one. I could see exactly which step had produced which file. That evening it closed 20 gaps against his reference example. About 75 files, every one traceable (how that build went).

Even then, getting it to run properly took a lot more than a good structure. It took better models as they came out. It took a much better harness (the setup around the AI that decides what it can see and do). And it eventually took a small software factory of my own, a set of AI agents that build and check changes to the system so I'm not doing it all by hand in chat.

It also took some hard lessons about what "done" means. In June I found my AI had reported work as finished that wasn't, more than once (I wrote about that here). The rule I set then still holds: something is done when it's been run for real and I've seen the result, not when the AI says it's implemented. The regulatory lawyer in me likes evidence. And in July I audited the whole thing and deleted most of the custom code that had built up around it (that story is here). The files at the core survived. Most of the machinery didn't.

What it runs today

Seven months on, it's the one that stuck. It holds my legal work, my AI Ops consultancy, the Mindstone Bristol community I run, and our household admin. I talk to it mostly through WhatsApp (how that works). It writes me a brief three times a day, drafts email replies in my voice for me to review and send, and keeps a searchable archive of my messages.

The structure is simple to describe:

• A short top-level file that says what this is, how a session starts and ends, and the hard rules.
• An operating manual that says where things live and which instructions to use for which job.
• One short instruction file per area (legal, network, ventures and so on), loaded only when a task touches that area.
• Records kept as one line per entry, for decisions, failures, work in progress and contacts.

The three rules

Three rules do most of the work, and they came straight from Koylan's design.

Never overwrite anything. Records only ever get added to. If something changes, a new entry says so. If something's finished, its status changes. This means the history survives. When a client comes back after six months, the reasoning is still there, for me and for whichever AI tool I hand it to.

Timestamp everything. Every entry says when. It sounds trivial. It's what lets you answer "what did we decide, and when?" without guessing.

Record where each fact came from and how sure I am. Every entry carries a source and a confidence. "Rian said so in a call on Tuesday, high" is very different from "the AI inferred it, low". When something turns out to be wrong, I can see where it came in.

There's a fourth habit that isn't a rule in the files but matters just as much. I log failures. Every time something goes wrong, there's a record of what happened, why, and what should prevent it. There are more than 1,500 of those now. It sounds grim. It's actually the most useful file I have, because it's how the same mistake stops happening a third time.

What a request looks like

It helps to see the layers working, so here's an ordinary example. Say I forward an email from someone I've worked with and ask for a reply.

The AI reads the short top-level file first, which tells it how to behave and what it must never do (it never sends email, it only drafts). The operating manual tells it that replying to email is a job for my email drafting instructions, so it loads those and nothing else. Those point it at the record of my writing voice, built from my own sent emails, and at my contacts, where it finds who this person is, how we know each other and what we last talked about.

Then it drafts a reply, puts it in my drafts folder and, under a rule I set in June, has to go and find the draft before telling me it's there. I read it, change what needs changing, and send it myself. If I correct something about the person or the situation, that correction goes into the records as a new line, dated and sourced, so next time it's already known.

None of the legal, finance or community files were loaded for that, because the task didn't need them. That's the layering doing its job, and it's the exact thing my first go couldn't do.

What I'd skip

If I were starting again, there are things I wouldn't build at all.

I wouldn't build anything that runs overnight to "improve" the system on its own. I had a chain of those. When I measured it in July it was over 5,000 lines of code and had shipped 2 improvements in a month while its to-do list grew. I deleted it.

I wouldn't build big engines for jobs a short instruction file can do. My three daily briefs had grown to over 12,000 lines of code. They're now three plain instruction files of 80 lines or fewer, and they turn up more reliably than the old ones did.

And I wouldn't copy anyone's files, however good, without understanding the reasoning behind each one. That's the whole story of go two.

If you're starting your own

None of this needs code. It needs a day to decide what your work actually is, and the discipline to write it down the same way every time.

1. Start from one question. What do you need in front of you on a Monday morning? Build the first area around that, not around a tidy list of topics.
2. Use plain files. Text files in folders. Any AI tool can read them, and you're not locked into one.
3. Layer it from day one. A short overview at the top, one short instruction file per area, detail underneath. The AI reads down only as far as the task needs.
4. Add, don't overwrite. Keep a log of decisions and a log of what went wrong. Each entry gets a date, a source and how sure you are.
5. Check, don't trust. When the AI says it's done something, go and look. If you can't find the result, it isn't done.
6. Prune on purpose. Once a month, ask what you haven't used. My July audit showed the small pieces carried the value.
7. Borrow architecture, not files. If someone has published a setup you like, take their method and build it for your work.

Where it's going

I'm teaching at a second brain bootcamp, "Your own second brain, running by lunchtime", on Wednesday 21 October at the Pitt Rivers Museum in Oxford. The morning is for building one, start to finish, for your own work.

Separately, I'm starting to turn the core of it into something other people can install, so they begin from a working base rather than a blank folder. The thing I most want to pass on, though, isn't the files. It's the order I learned things in the hard way: layer it, add rather than overwrite, and check everything.

If you'd like help getting your own started, drop me a line.