A client comes back months after a project with a “small” change. Or someone asks, “Why did we decide to do it this way?” You know the answer exists somewhere, but the relevant decision is buried in a large inbox, a handover, a Drive document, an attachment and a few half-remembered messages. The information exists. The reasons behind it are scattered.
The first job is reconstruction. What had been approved? Which constraint made the original decision sensible? What was excluded? What had already failed? Without those answers, the newest message starts to look like the whole story.
Reconstruction takes time and makes judgement worse. A small request loses the constraint that made it non-trivial. A rejected direction returns as if it were new. A useful method becomes an instinct that cannot be explained or handed over.
I did not build a Second Brain because I wanted a more impressive note-taking system. I built one because too much useful work was disappearing between projects, conversations, tools and versions of myself.
It is for the ordinary moment when work resumes and I can remember that we made a decision, but not everything that made it sensible. It gives that missing background somewhere to live, so I can return to the work with the important detail intact instead of rebuilding it from fragments.
The aim is not to remember more or replace thinking. It is to retain enough of a decision that future-me can understand it, challenge it, revise it and use it again.
A Second Brain is not a second personality
The name can make it sound more dramatic than it is. A Second Brain is simply an external system for retaining the context that your ordinary memory should not be expected to carry forever.
In my case, it is private, Markdown-first and organised as normal files rather than a black box. It holds reusable methods, current project context, decisions, risks, source notes, working assumptions, creative material and handovers. The files are versioned, browsable and readable without a particular app being open.
Markdown is useful because almost any app can display it, and it is quick to write and read. Its plain structure also gives an AI less formatting to work through, so a selected record usually takes less context to query than a pile of heavily formatted documents. More importantly, it lets the information remain useful after the moment that created it.
A note that says “client wants cleaner homepage” is not much use six months later. Cleaner than what? For whom? Was the issue visual hierarchy, a message problem, an untested offer or a stakeholder preference? What was already approved? What was deliberately excluded? Which source should overrule a casual comment if they conflict?
The difference between a pile of notes and a useful memory system is not the number of folders. It is whether the system retains enough context to answer those questions honestly.
I needed somewhere for the reasoning to go
Most knowledge systems are good at storing outputs: a final deck, a signed proposal, a published page, a finished design. Those things matter. But the useful part of the work often sits around them.
Why did we choose this route? What evidence supported the claim? What risk did we accept? What should a future collaborator not assume? Which version is current? What remains unresolved?
Those are not administrative leftovers. They are the conditions that make a later decision safer.
I work across strategy, design, websites, writing, art and AI-assisted workflows. The work looks different, but the continuity problem is the same. A brand strategy needs to survive the presentation. A website needs to retain the decisions behind its structure. A poem or visual series needs to keep its images, influences and earlier versions from becoming interchangeable. An AI-assisted task needs a clear source boundary, otherwise the model is invited to sound certain about material it does not properly understand.
Without a record of what led to the decision, each return to the work becomes a small act of archaeology. Sometimes that is useful. Often it is just expensive. I need somewhere to record those decisions while they still have their original shape.
What it actually contains
I do not try to capture everything. That would create a private archive of noise, which is not the same as memory. The system earns its maintenance cost when it helps with a real next decision.
The most useful material falls into a few practical layers.
Canonical knowledge is the durable layer: methods, definitions, reusable standards, identity and voice context, and records that should guide more than one task. This is where I keep the things I do not want to reinvent every time I open a new brief.
Current context is the moving layer: what is active, what has changed, what is blocked, what the next person needs to know and what should not be treated as settled. A current-context note is deliberately less grand than a strategy document. Its job is to make a return to the work less foggy.
Decision and risk memory records not only what happened, but why. It preserves the trade-off, the source basis, the uncertainty and the condition under which a decision should be revisited. This matters because a decision without its reason is easy to misread as arbitrary.
Source and status boundaries make the system safer to use. I need to know whether something is confirmed, an assumption, in conflict, outdated or still needing verification. I also need to know whether it is private, client-safe, public-ready or not for reuse at all. A neat summary that erases those differences is worse than an untidy record that keeps them visible.
Reusable methods and handovers let the system compound. A quality check, writing framework, launch sequence or lesson from a difficult project becomes more useful when it can guide the next task without forcing anyone to reconstruct it from scratch. A handover applies the same principle under pressure: what is complete, what is open, what matters next and what must not be lost?
Once context is preserved consistently, it can be compared across projects. Repeated requests, fixes, scope gaps and effective approaches stop looking isolated. Patterns emerge, processes improve and ideas connect beyond separate client folders.
It is the minimum structure I have found useful for keeping work legible over time. From there, I can see links and threads between projects, then build further knowledge, processes and skills from my own material.
It becomes more useful when it shapes the next task
At first, the system helps me keep track of what happened. Over time, it can do more than that. A useful email becomes a context record. A solution I use repeatedly becomes a method. A method that works across projects can become a skill: a clear process for handling a familiar kind of work, with the right checks, source boundaries and definition of done already built in.
That is where the value starts to compound. I am not asking or relying on AI to invent a new process every time. I can point it at my own proven method and the relevant project material, then ask it to apply, compare or improve the work. The process is repeatable, but the context still changes the answer.
Structure is what makes this possible. A search can find words; a well-kept record gives an assistant enough to find the decision, its source, its status and the method built from it.
This does not make judgement automatic. It makes previous judgement available. It helps me see recurring patterns across projects, improve the method and spend less time rebuilding a way of working from scratch.
Storage is not memory
Most people already have storage: drives, inboxes, project tools, chats and folders full of files called final-final-2.
Storage answers: where is it?
Memory has to answer more difficult questions: is it current? Can I trust it? What does it affect? Where did it come from? What am I allowed to do with it? What would change the decision?
That is why I do not think a Second Brain begins with a tool comparison. It can be a folder of Markdown files, a notebook, a carefully run project system or something else entirely. The important part is preserving enough of the work for a later decision.
For a broader business view of this problem, I wrote earlier about why a business needs a memory. That piece is about operational continuity across clients, teams and projects. This one is narrower and more personal: the system I use to stop my own practice from being governed by whichever message I saw most recently.
AI made the need clearer, not simpler
AI did not create the need for a Second Brain. It made the cost of weak context easier to see.
There is a lot of noise around being for or against AI. I find that framing less useful than a simpler one: it is a tool. In my own work, it helps me search and use the material I have already kept. A single well-scoped question can surface an earlier handover, a technical change made during a build, or the constraint that matters when a client returns months later with a request.
The hard work happens earlier. I turn selected email, handovers and supporting material into a record while the detail is still available, rather than asking an assistant to assemble Gmail links, Drive files and additional documents every time the question returns. The Second Brain holds the record; the assistant helps me find the relevant part of it.
That does not mean I hand over judgement. It means I do not waste time trying to remember where a detail lived before I can decide what to do with it.
An assistant can search, compare, summarise and help turn a body of material into useful work. But it cannot know which note is current, which assumption was never confirmed, which source is private or which decision was superseded unless the system makes those distinctions available.
This is where I part ways with a lot of AI conversation. People talk about connecting a model to “all the knowledge” as if more material automatically produces more understanding. It does not. More material can mean more stale versions, more missing boundaries and more confidence built on the wrong source.
I use AI as an interface to a governed body of material, not as a replacement for it. The system should make it easier to ask: which sources are allowed to influence this task? What changed in the last handover? What is confirmed? What is missing? What still needs a human decision?
The answer may still be uncertain. The point is to keep that uncertainty visible rather than polish it away.
Start with one useful question, not a productivity system
You need a place for working material and a clear boundary around what an assistant may query.
That is how I use this repository: local Markdown for context, decisions, handovers, methods and source boundaries. I point a local AI assistant at an approved record or folder, then ask one scoped question. It retrieves context; it is not the source of truth.
For client, private or technical detail that needs to stay out of a cloud service, use a genuinely local route only after checking that it is local. Do not expose a whole filesystem: select the relevant material, keep its boundary visible, then ask.
A simple first setup
You do not need to become a systems person before this is useful. Download the small public starter as a ZIP and unzip it.
Open the folder in ChatGPT or a similar desktop AI app. Start with one real piece of work: a current-context note, a decision record and a method.
Then ask one plain question: “What changed, which source supports it, and what still needs a human decision?” If the assistant cannot show its sources and limits, improve the record—not the prompt.
Add whatever you want to start with to input/: an old handover, a useful email, meeting notes, a method or a current project file. Ask the assistant to turn it into the records you will need later: a decision, a handover, a source note or an update to current context.
Keep the folder as your source of record. If you use a cloud chat, add only material you are comfortable sharing.
After a few weeks, return to a paused task. If you can see what happened, what is confirmed and the next decision without reopening every tab, it is working. If not, add the missing context before changing the setup. That might mean turning useful older emails into short context files, or recording a decision that still only exists in a conversation.
The point is continuity, not control
I do not want a Second Brain that makes every thought permanent or turns creative work into admin. Some ideas should stay loose. Some notes should expire. Some problems need a new conversation, not an old answer forced into a new situation.
It does not remove judgement. It gives judgement better material to work with.
The most valuable thing the system gives me is continuity: a project can pause without vanishing, a method can improve instead of restarting, and a future collaborator—or a carefully constrained AI assistant—has enough context to help without inventing a backstory.
Every practitioner has some version of this problem. There is context you keep reconstructing: the decision behind the work, the client boundary, the source you trusted, the idea you nearly lost or the method you can feel but cannot yet explain.
That is probably where your Second Brain should begin.
If this kind of practical thinking is useful, follow along. I write about systems that make creative and technical work clearer without pretending that the system is the work.
No published comments yet.