Quick answer (TL;DR): An AI “second brain” is a small set of living documents — stored in a cloud folder both you and your AI assistant can reach — that give the assistant persistent memory across sessions. The core structure is: a standing handoff (single source of truth, read first every session), a master index, a profile/preferences file, a people file, a glossary, and a private notes file — plus one folder per recurring unit of work (projects, clients, cases) with one file per item. The assistant reads these at the start of every session and writes back at the end. The discipline that keeps it working: one source of truth per thing, version-stamped updates, and no silent duplicates.
This is the practical, copy-this-structure companion to the idea that you should use AI like a colleague, not a vending machine. If you’ve accepted that persistent memory is the unlock, this post is the exact blueprint.
Why files, not chat history
Chat history is a terrible long-term memory system. It’s linear, hard to search in practice, scattered across sessions and devices, and — critically — invisible to a fresh conversation. A new chat (or a chat on your phone, or one started by a teammate) can’t see what you discussed yesterday in a different thread.
The fix is to externalize memory into documents. Files are durable, structured, searchable, editable by you, and readable by every session. You move the memory out of the ephemeral conversation and into a stable structure that persists.
The shape that works is a mesh: a few top-level context files that describe your world, and folders beneath them for the recurring units of work. You don’t have to copy my exact files. You need to copy the shape.
The top-level files
These describe your world and rarely change much once written. Create them first.
1. The standing handoff (the most important file)
This is your single source of truth and the first thing your assistant reads every session. It contains:
- Current state — what’s in flight right now, across everything.
- What shipped recently — so you and the assistant share an up-to-date picture.
- What’s pending / blocked / waiting on others.
- The protocol — how sessions work (read this first, write back at the end, etc.).
- A change ledger — a dated list of what each session did, so parallel work can be reconciled.
If a reader of your brain could only open one file, this is the one. Mark it with a version number and timestamp in the header every time it’s updated, so the newest copy is always unmistakable.
2. The master index
A simple map of everything else in the brain, so a fresh session can orient in seconds. One line per file, with a note on what it’s for.
3. Profile & preferences
Who you are and how you like to work:
- Your role and responsibilities.
- Your working style (“execute and minimize,” or “always show your reasoning,” etc.).
- Communication preferences (tone, format, length).
- Your hard rules — the “never do X” and “always do Y” constraints that should apply to everything without re-asking.
4. People
The humans in your orbit:
- Names, roles, and how they relate to your work.
- Who reviews or approves what.
- Who needs careful handling, and why.
Include the real dynamics, honestly. A good colleague knows the politics; your second brain should too.
5. Glossary
Your domain’s shared language:
- Jargon, acronyms, and internal terms.
- Tool names and IDs.
- Dashboard and resource links.
- Anything a new hire would have to ask about twice.
This file alone prevents an enormous amount of “wait, what does that acronym mean again” friction.
6. Private notes
The honest internal layer, for your eyes only:
- Observations that shouldn’t surface to anyone else.
- Workarounds you’ve taken.
- Politically delicate things worth remembering but not worth saying out loud.
Every real working relationship has a “between us” layer. Make it an explicit file so it’s captured but contained.
The folders: one per recurring unit of work
Beneath the top-level files, create a folder for each type of recurring work. The categories depend on your job:
- A marketer might have campaigns, tickets, and meetings.
- A consultant might have clients, engagements, and proposals.
- A product manager might have features, launches, and research.
- A lawyer might have matters, clients, and filings.
Inside each folder, one file per item. Each item file holds:
- Scope — what this thing is.
- IDs and links — every reference number, URL, and pointer you’d otherwise hunt for.
- A dated log — append-only, newest on top, recording what happened and when.
- A private-notes section — the item-specific “between us” layer.
The item file is the source of truth for that item. Status might live in a separate live tracker, but the narrative, the context, and the decisions live here.
The rituals that bring it to life
A second brain is inert without a loop around it. Two rituals close the loop (and a third keeps it honest).
Opening ritual. At the start of every session, the assistant reads the standing handoff and relevant context files before doing anything. This rehydrates context from the files instead of from you.
Closing ritual. Before the session ends, the assistant writes back what changed — updating the standing handoff, the relevant item files, and the change ledger — and bumps timestamps. Skip this and the next session starts stale.
The reconcile (periodic). Every so often, have the assistant sweep all the places work arrives (messages, email, tickets, trackers) and cross-reference against your tracker to surface anything dropped. (This deserves its own deep-dive, and gets one later in the series.)
The rules that prevent chaos
A growing pile of files becomes a mess without a few disciplines:
- One source of truth per thing. No duplicate files for the same item. No “v2_final_FINAL.”
- Version-stamp updates. When a file is updated, mark the new version with a number and timestamp in the header so stale copies are obvious and safe to delete.
- Append-only logs. Don’t rewrite history; add to it, newest on top. The trail is valuable.
- Separate internal from external. Honest observations go in private notes; only what serves the audience goes in shared deliverables.
- Capture the principle, not just the instance. Write things in a way that’s reusable next quarter, not just for today’s fire.
A realistic note on tool limits
Whatever cloud storage and assistant you use will have sharp edges. Some assistants can create and read files but not edit them in place — meaning an “update” is actually a recreate (which is exactly why version-stamping matters). Some have file-size limits. Some integrations are flaky.
Do a capability audit early — actually test what your setup can and can’t do — and design your file conventions around the real constraints rather than the ideal ones. (This, too, gets its own post.) The version-stamp-on-recreate convention, for example, exists specifically because the tool I used couldn’t edit in place. The constraint shaped the method, and that’s fine.
A minimal starter version
If the full structure feels like a lot, start with just three files and add the rest as you feel the need:
- Standing handoff — current state + how we work.
- Profile & preferences — who you are, how you like things done, hard rules.
- One folder for your main type of work, one file per item.
Add the people file, glossary, and private notes when you notice yourself re-explaining the same things. The structure should grow to fit your actual friction, not arrive fully built and unused.
What you get
Once this is in place and the rituals are running, the experience changes completely. You open a session and the assistant already knows the state of play. You stop paying the re-explanation tax. Work compounds across sessions instead of resetting. And you’ve built something portable that isn’t tied to any one employer or tool — a genuine asset that’s yours.
Frequently asked questions
What files do I need for an AI second brain? At minimum: a standing handoff (single source of truth), a profile/preferences file, and one folder per type of work with one file per item. Add a master index, people file, glossary, and private notes as your needs grow.
Where should I store an AI second brain? In a cloud folder that both you and your AI assistant can access, so the assistant can read context at the start of a session and write updates at the end. The key is that the files are durable, editable by you, and readable by every session.
What is a “standing handoff” document? It’s the single source of truth your assistant reads first every session — holding current state, what shipped, what’s pending, the working protocol, and a dated change ledger. It’s the most important file in the system.
How do I keep the second brain from becoming a mess? Follow a few disciplines: one source of truth per item, version-stamp every update, keep logs append-only, separate honest internal notes from shared deliverables, and capture reusable principles rather than one-off specifics.
Do I need a technical background to build this? No. It’s a folder of plain documents and two habits (read at the start, write at the end). The structure and discipline matter far more than any technical skill.
This is Part 3 of a series on building a working method with AI. Next: what happens when you run several AI conversations at once — and the protocol that stops them from overwriting each other.