The second brain that does the work

Two years of saving things had left me with 340 articles, collected between 2023 and 2025. I had used ten of them.

That is a second brain working exactly as designed. It is also why the idea fails.

The premise is a good one: keep everything you learn in one place outside your head, so your thinking compounds instead of evaporating. People build them in Notion, in Obsidian, in apps made for the purpose. I had been building mine for years across several tools, and what I had to show for it was a very well-organised place where ideas went to be quiet.

So in April I rebuilt mine around a different question. Not where do I put this? but what will read this back to me, at the moment it matters, without being asked?

Why this is not a bookmark folder

A bookmark is a filing cabinet. Its purpose is retrieval: you go to it when you already know what you want, which means it only ever helps with questions you thought to ask. That is why 330 of my 340 never came back out.

A ship's log is a different instrument. It is written every watch whether or not anything happened, it is never rewritten, and the entries recording the mistakes are the ones that keep the ship off the rocks the following year. You do not read a log to look something up. You read it to find the pattern you were too close to notice at the time.

The other half of the difference is who does the reading. Most people meet AI as a chat window: you type a question, you get an answer, you copy it somewhere useful, and the conversation is forgotten. The version I set up can open files on my laptop, read them, and write new ones back. I stopped carrying knowledge to it, and it started keeping the notes itself.

Why it was worth building at all

AI made building cheap. Taste is the thing that is still scarce.

When anyone can generate a screen in seconds, the advantage goes to whoever's output actually looks and feels like the product it belongs to, rather than like generic AI slop. That judgement already existed in our team, spread across a design system, a set of patterns, and a lot of opinions that had never been written down anywhere a machine could reach.

So the thing to capture was not information. It was judgement, written down and made executable. Not a chatbot with a nice prompt: a system that knows what good looks like here, and produces it by default.

How I built it

Three layers, one system. A knowledge base, a set of skills that read it, and the finished work they produce, which flows back into the knowledge base.

It isn't a chatbot. It is our design judgement, written down and made executable.

Two files coordinate everything. A house-style file tells the assistant what a page looks like and what a log entry looks like, without which every session invents its own filing habits and you end up with a hundred pages in a hundred formats. The second is the routing list.

The build itself is the part I would do differently. April and May are the two quietest months in the whole log, because I spent them making folders and conventions before anything used them. About half of that has since been rearranged by contact with real work.

How it works

Anything worth keeping goes in: a requirements document, an article, a Figma URL, a screenshot, a PDF. It gets read, distilled and cross-linked against what is already there, so the same thing is never learned twice. Then the skills draw on it, and what they produce goes back in.

Three page types, all cross-linked. Sources, the entities they are about, and the concepts underneath, tied together with wiki links. An index catalogues the lot and an overview synthesises across it, so the more that goes in, the more useful each new page is.

It is also self-maintaining. A weekly ingest and lint keep the knowledge current, and a Friday review promotes new lessons into the skills.

A skill is a written set of instructions for one kind of job: generate screens, build a component, write a spec, wire a prototype, design the motion, build a deck. Each one loads the knowledge base as context before it starts, which is the whole trick. The output is on-brand by construction rather than by correction afterwards.

The interesting part is how a request gets routed. Where two skills could both apply, it decides by what I want out, not what I hand in. A design file tells you nothing about intent: I might want it extended, documented, or turned into a working prototype. So the assistant asks one question rather than guessing. A wrong guess costs twenty minutes. The question costs five seconds.

Underneath sits one rule that took me a while to understand: a session never edits its own instructions. If any run can rewrite the rules it follows, the rules drift toward whatever the last session happened to be doing, and nobody notices. A run may only record what it noticed. A review each afternoon puts each one in front of me to approve, reject or park, and a weekly pass keeps the notes from rotting.

The routine I would copy into anything similar is the weekly trawl through our chat channels, and it is deliberately hobbled. It writes only to a holding folder, and where it finds something that contradicts an existing page it raises the conflict instead of resolving it. Chat is full of confident answers that are out of date. Nothing becomes fact in there without a human saying so.

What I have actually made with it

145 finished pieces in 141 days: 87 web pages, 17 documents, 7 decks. Not concepts in a deck. Work that went into designers', PMs' and engineers' hands.

Search and filters, as a thing you can click. The whole entry point rebuilt as real HTML rather than a static mockup: the Buy and Rent tabs, the district field, and a recent-searches list where every saved search still carries the filters that made it. Stakeholders argue with a working screen instead of imagining one.

A compass for whatever is around you. Point the phone and the condos in that direction come back with their distance and bearing, nearest first, in a flat map view or through the camera. It runs on real device orientation and GPS, with a simulation to fall back on, which is how far a sensor-driven idea can be pushed before committing any engineering to it.

A listing turned into a poster. Give it a listing ID and it draws the listing: bedrooms, floor area, price against the district median, and property type, each mapped onto something you can see. Every poster prints its own legend in the corner, so the drawing explains how to read itself. The same four numbers go through five different drawing engines, and a flat in Bukit Panjang and a condo in Cairnhill come out looking nothing like each other, which is the point.

This is the least useful of the five, and the one I would defend hardest. Nothing else here would have been worth building if the system could only make the things somebody asked for.

Three listings, three drawing engines, the same four attributes underneath. Click any of them to read the legend.

What made those possible

The first run set the pattern. Five days in, a requirements document went in and four designed screens came out. What mattered was not the screens but the log entry underneath, which listed three corrections and one unanswered question. The work is recorded with its failures, not just its result. A log of successes teaches you nothing, because success has no detail in it.

Context stopped being re-explained. One 640-line document, about 8,000 words, describes roughly 36 components and how we use them, and can be pasted whole into any other tool. Before it existed I reassembled that by hand at the start of every project, slightly differently each time.

Work gets picked up rather than restarted. Sixteen projects have been returned to across separate sessions. One interface went from design file, to working prototype, to a built version, each stage reading the last. That only works because the outputs live somewhere durable instead of in a chat history that scrolls away.

The same job got faster by being rewritten. Two of the busiest skills do the same task. One takes 25 to 35 minutes per run; the faster version takes 8 to 15, with all the same quality checks and a shorter judgement pass at the end. The fast one overtook the original within weeks.

Mistakes stopped repeating. The log holds 115 corrections. A typical one: prices should show the local currency symbol rather than the three-letter code, fixed on 8 prices across two screens. Small and dull, and that is the point, because it is exactly the sort of thing I would otherwise re-explain forever. Twenty-one have been approved into the instructions, alongside a memory of 136 single-fact notes. Several of those are things the assistant got wrong twice.

A correction does not stop at the thing it fixed. It runs the whole way round, and the next run reads the changed instruction before it starts.

If you are building one

Do not build the structure first. That is the trap the second brain idea walks you straight into: it is far more satisfying to design the shelving than to do the work that fills it.

Build the smallest loop that survives a mistake instead. Do the work. Write down what went wrong. Make sure the next attempt reads that note before it starts. Everything above is that one loop, run 747 times, and the folders and routines all arrived later, each one in response to something that had already gone wrong once.

There are 47 entries sitting in my review queue as I write this. Every one is a mistake I have already made, already diagnosed, and not yet stopped from happening again. Clearing them is the next thing I do.