Start your brain
Four plain text files on your own machine that give every AI tool you use a memory. About two hours, spread over two sittings.
The problem you actually have
You do not have a tool problem. You have a memory problem.
Every tool you run starts from zero each time you open it. So you re-explain your context five times a day and none of it survives the session. That is why a handful of good tools feels like a hundred loose projects.
Adding another tool does not fix this. A shared memory those tools read from does. It is four markdown files in one folder on your computer. That is the entire system.
1. Where the folder lives
One folder on a machine you own. Do not overthink the name. This is the whole thing you are building, start to finish:
Four things at the top level, two of them folders. That is the entire system. Everything else on this page is how to fill them in.
Put it on your Desktop or directly in your home folder. Copy the full path now, because you paste it into your entry-point file in Step 2 and every session depends on it being right.
/Users/yourname/Desktop/brain/Users/yourname/brain — often written ~/brain, where ~ is shorthand for your home folderC:\Users\yourname\Desktop\brainWindows: shift-right-click the folder, choose "Copy as path."
Paste that somewhere for Step 2. Do not retype it from memory, a single wrong character means your AI silently reads nothing.
2. Which machine
Start on the computer you already have. If you later want jobs running while you sleep, that is a separate setup and we will cover it in the next training. Do not buy hardware to start.
3. One primary interface
Exactly one tool becomes the one that reads the brain every session. Everything else gets demoted to a research tool or a pair of hands.
There is no wrong answer here. The files are the product. The tool is just what reads them. Every option below reads plain markdown off your disk, and the only real difference is what the instruction file is called. Switching later costs an afternoon; a folder you never wrote costs you the whole thing.
So pick in under a minute. Already paying for something? Use that. The hour you would spend comparing tools is the hour that was supposed to go into Identity.md.
Need help deciding? Three questions, one minute, and you get one name and one filename.
CLAUDE.md. It does not read AGENTS.md natively.CLAUDE.md from that folder at the start of every session without being asked. Also does project instructions and scheduled tasks. The best option here if you do not want a terminal at all.AGENTS.md natively, closest file to your working directory wins.AGENTS.md from the directory it runs in, keeps reusable procedures in ~/.hermes/skills/, and has scheduled jobs built in. The one on this list that goes furthest without adding a second tool later.AGENTS.md family plus CLAUDE.md, global rules from ~/.grok/, and .cursor/rules/ for compatibility. Widest file support of anything here, so it slots into an existing setup with no renaming.GEMINI.md, global copy at ~/.gemini/GEMINI.md. You can point it at AGENTS.md instead by setting context.fileName in its settings, which is worth doing if you ever run a second tool.~/.openclaw/workspace) and loads AGENTS.md, SOUL.md, USER.md, TOOLS.md into every session. Already shaped like this system, which is either a head start or a set of opinions to work around.AGENTS.md; scoped rules go in .cursor/rules/. The old .cursorrules file is legacy, do not start there.AGENTS.md natively. Pick on editor preference, the memory setup is identical.AGENTS.md.The pattern in that second table: a file on disk is loaded every session whether you remember it or not. A Project or Space you forgot to open is not. That gap is small on day one and it is the whole ballgame by month two, because you will not notice the sessions that ran without your context.
If you are already paying for one of these, use that one. The memory setup is nearly identical across every terminal agent above and the filename is the only real difference. Switching tools is not the upgrade; having a brain for the tool to read is.
Pick one just to get started. You are not marrying it. You are picking the tool that reads your files while you build them, and that is a decision you can change in an afternoon once the files exist.
Two reasons to commit to one for now. Two primaries means two instruction files, and within a month they disagree and you have no idea which one a session read. And every hour spent comparing tools is an hour not spent writing the files that actually make any of them useful.
Same goes for the model. Pick whatever your tool defaults to and move on. Which model for which job is a real question with a real answer, and it is the next training, not this one. The context layer you are building works with all of them.
I am setting up a folder of markdown files on my own computer that my AI tools will read as a shared memory. Before I write anything I have to pick exactly ONE primary interface: the tool that reads that folder every session. My tools right now: [LIST EVERY AI TOOL YOU USE OR PAY FOR. For each: what you use it for, and whether it can read files on your computer.] My machine situation: [e.g. "MacBook I close at night" or "Mac mini that stays on"] Do three things: 1. Sort every tool into exactly one bucket: PRIMARY CANDIDATE - reads local files, holds a working session RESEARCH - answers questions, no memory of me HANDS - takes actions or sends notifications, not a place I think 2. Recommend exactly one primary, and tell me in one sentence why, in words I could repeat to someone else. Favor the tool with an instruction file I control over the one with the nicer interface. If two tie, name the tiebreaker instead of picking at random. 3. Tell me the exact filename and path that tool reads its instructions from, so I know where my entry-point file goes. Rules: - Do NOT recommend I add a new tool. Too many moving parts is my actual problem. - Do NOT get into which model I should run. I am picking a tool and using whatever it defaults to. If I ask about models, tell me it is a separate decision and stay on the tool question. - If nothing I own can read local files, say so plainly and name the smallest change that would fix it. Then ask me to confirm the pick before we continue.
Help me pick
Three questions. There is still no wrong answer, this just stops you comparing tools for an hour.
The only answer that rules options out rather than ranking them. A terminal is the text window where you type commands instead of clicking. Never used one is a valid answer here.
The strongest signal here. Already paying usually settles it. Not every tool on this list can be the primary, and you will be told which.
Now stop thinking about the tool. It was never the hard part. Everything from here is writing four files, and those files work with whatever you picked, whatever you switch to, and whatever gets released next year.
How long these files should be
This is the part people get wrong in both directions, so here are the numbers up front.
CLAUDE.md is under 200 lines; 60 is tighter because yours points into a folder instead of containing it. Every line here is re-read on every single turn.Why the limit is real and not just tidiness. Long instruction files measurably reduce how well the model follows them. When a request has to compete with 400 lines of background, the request loses. You do not get a warning when this starts happening; you get an assistant that quietly ignores your rules and you assume it is just bad.
Some tools also truncate silently past a character budget, so rules near the bottom of a long file are never read at all.
The rule that keeps them short: anything loaded every turn stays tiny, anything loaded on demand can be as long as it needs to be. When a file gets fat, you do not compress the writing. You move a section into the folder and leave a pointer.
The check, once a month: open your entry point and count the lines. Over 60 means facts have crept in. Cut them to the folder.
Identity.md
One page. Who you are, and who you want the AI to be. Write this first even though it will feel like the least useful one.
Everyone builds the tools list first because it is concrete. Then every session re-negotiates tone, authority and priorities from scratch, forever. This file ends that.
Budget 30 minutes. The prompt below turns your AI into the interviewer so you can answer out loud instead of staring at a blank page.
Interview me to produce a one-page Identity document for my AI setup. It gets read at the start of every future session, so it has to be accurate rather than flattering. Run it as a real interview: - Ask ONE question at a time and wait for my answer. - If I give you a value statement instead of a concrete instance, push back once and ask for the specific example. "I value my family" is decoration. "I turned down a project because it meant traveling in December" is usable. - Do not write any part of the document until all ten are answered. - Never fill in an answer for me. If I am vague, ask again. WHO I AM 1. What does your work actually do, in one sentence, the way you would say it to a stranger at a bar? Not the mission statement. 2. Tell me about a decision in the last month where two things you care about pulled in opposite directions. What won? 3. What would you protect even if it cost you money? 4. What is this ultimately for? What does winning look like in five years? 5. Whose priorities matter here, and in what order? WHO I WANT THE AI TO BE 6. If it could do one task perfectly starting tomorrow, which one? 7. Do you want it to do what you say, or push back when it thinks you are wrong? Give me an example of a time someone pushed back on you and whether it landed well. 8. What can it decide on its own, and what has to come back to you first? Be concrete: money, anything sent externally, anything that touches a customer. 9. What would make you stop trusting it? 10. What should it never say or do, even if it is technically right? When all ten are answered, output exactly this and nothing more: ## Who I am - [role / craft, one line] - [the trade-off from Q2 or Q3, stated as what LOSES, not as a value] - [what this is ultimately for, from Q4] - [priority order from Q5] ## Who I want the AI to be - [assistant / analyst / operating partner, from Q6 and Q7] - [decide-alone vs. must-ask boundary, from Q8] - [what breaks trust, from Q9] - [hard no's, from Q10] Constraints: - Fits on one page, roughly 300 to 500 words. This file gets read at the start of every session, so length has a real cost. - Every line decision-relevant. If a line would not change what you do in a future session, cut it. - At least one line names something you are NOT allowed to decide alone. - Use my words. Do not upgrade my phrasing into corporate language. When you are done, tell me the word count. If it is over 500, do not hand it to me. Cut the weakest lines first and tell me which ones you cut and why. Finally, read it back to me one line at a time and after each line ask: "does this one make you wince?" If I say yes, do not defend it. Ask what is actually true and rewrite that line.
Answer out loud if you can. The real answer to question 2 usually arrives about ten seconds after the first one.
Identity.md at the top level of your brain folder, next to Tools.md. Not inside Canon, not inside Active. The file on disk is the only real copy, no matter which tool you use.USER.md (the "who I am" half) and SOUL.md (the "who the AI should be" half) in your workspace folder, since OpenClaw loads those automatically.If your tool cannot read local files, read this twice. You will be tempted to paste this file into a Project or Space and call it done. That works for exactly one thing: the AI knowing who you are. It does not give it your Canon notes, your Active projects, or anything you write next week.
So: the file on disk stays the master copy. The paste is a mirror, and mirrors go stale. Edit the file first, always, then re-paste. Never edit the text inside the Project and assume the file caught up, because it did not, and in a month you will not remember which version is real.
This is the actual reason the tools that read your folder are worth switching to. Not features. This.
The entry point
The one file your AI reads every single time. Under 60 lines, and it contains zero facts.
This is the always-on layer, so every line costs you on every turn. It holds four things and nothing else:
- The path to your brain folder.
- The read order. Which files to read, in what sequence, before doing work.
- Two or three rules that must survive even if the folder is unreachable. This is the only layer guaranteed to load.
- The context gate. Which requests require reading the brain first, and which do not.
CLAUDE.md. For Cowork, put it in the folder you attach and it loads every session. Neither reads AGENTS.md natively.AGENTS.md in the folder you work from. This is the cross-tool standard now stewarded by the Linux Foundation.AGENTS.md. It also accepts CLAUDE.md and reads ~/.grok/ for global rules, so whatever you already have will be found.GEMINI.md by default. To use AGENTS.md instead, set context.fileName to ["AGENTS.md","GEMINI.md"] in its settings file.AGENTS.md as the real file, then make CLAUDE.md a single line: @AGENTS.md. One file to maintain, both tools read it. A folder with only AGENTS.md loads zero instructions in Claude Code, silently.AGENTS.md in ~/.openclaw/workspace. Injected into every session automatically.Where to save it: in your brain folder, alongside Identity.md and Tools.md. One folder holds everything, and the only thing that changes between tools is what this file is named.
The one thing to get exactly right: the path inside it. Paste the full path you copied in Setup, do not retype it. A wrong path does not throw an error, it just means every session runs blind.
Write the entry-point file for my AI setup. This is the ONE file my primary tool loads every single session, so it must be short and contain zero facts. My primary tool: [TOOL] The file it loads: [CLAUDE.md / AGENTS.md / custom instructions] My brain folder: [/full/path/to/folder] My Identity doc is pasted at the bottom. Include these four things and NOTHING else: 1. The absolute path to my brain folder. 2. The read order: which files to read, in what sequence, before doing work. 3. The two or three behavior rules that must survive even if the folder is unreachable. Pull them from my Identity doc - the rules I would find unacceptable to lose in a degraded session. 4. A context gate: explicitly which kinds of request require reading the brain first, and which do not. Be concrete on both sides. Shape: "Anything involving a named client, project, or a claim about what exists or what was decided requires reading the brain first. Arithmetic, general knowledge, and casual conversation do not." Hard constraints: - Under 60 lines. Count them and tell me the number when you are done. If it does not fit, cut content, do not compress the writing. - ZERO facts. No client names, no account IDs, no history, no list of what is connected. Those all live in the brain folder, not here. - Test every line: is this a FACT, or a RULE about how to behave? Facts go in the folder. Rules stay in this file. - Put a review date at the top, six months out. Then do a second pass out loud: reread your own draft hunting only for facts that crept in, and list anything you find. Report the final line count. My Identity doc: [PASTE IT HERE]
Without guessing, answer this: [ASK SOMETHING ONLY ANSWERABLE FROM YOUR BRAIN FOLDER. Example: "what am I not allowed to decide without asking?" or "what is the priority order of my projects?"] Before you answer, tell me which files you read to get it.
If it answers from thin air instead of reading, the gate is not working and nothing after this matters. Fix it before moving on.
The moment this file starts holding facts, it has become a second brain, and second brains go stale silently while still being read with full confidence.
Tools.md
What is connected, what each thing is for, and the dead ends you already found.
Save it as Tools.md at the top level of your brain folder, next to Identity.md. Same place, same rule: the file on disk is the real one.
The dead-ends section is the part nobody writes and the part that pays off fastest. Every time you discover a tool cannot do something, write it down. Otherwise you re-diagnose the same failure in three months and it costs you the same afternoon.
## Routing - [which tool handles which kind of work] - Use what is connected before adding anything new. ## Connected | Tool | Used for | Notes | ## Dead ends - [what does not work, and why, so it is never retried blind]
Help me write a one-page Tools file for my brain folder. My stack, already sorted: PRIMARY: [tool] RESEARCH: [tools] HANDS / AUTOMATION: [tools] OTHER ACCOUNTS THAT MATTER: [email, calendar, storage, CRM, whatever] Interview me briefly to fill gaps, then produce: ## Routing - [which tool handles which kind of work, one line each] - Use what is connected before adding anything new. - When something new gets connected, update this file the same day. ## Connected | Tool | Used for | Notes | ## Dead ends - [what does not work, and why] Rules: - NEVER include credentials, API keys, or tokens. Not even test ones. This file says a connection exists; it does not contain the connection. If I paste one by accident, tell me and refuse to include it. - For dead ends, ask me directly: "what have you already tried with these tools that did not work?" Get at least one real entry. An empty dead-ends section means we skipped the most valuable part. - One page. This is an inventory, not documentation. If the Connected table is getting long, that is a signal I have too many tools, not that the file needs to be longer. Then ask me one question: is there a specific workflow I ALREADY RUN TODAY that needs a system my primary tool cannot reach? Do not suggest connector platforms unless my answer names a real, current workflow. If I name a hypothetical, tell me to skip it.
A connector dashboard showing "active" is a claim, not proof. Connections show green and fail on the first real call. Verify every one with an actual request before building on it. One honest connection beats ten fake ones.
Never put credentials in this file. Keys stay inside the tools that hold them.
Two folders
Not a document. This is where the hundred loose projects actually go.
Create both inside your brain folder, alongside Identity.md and Tools.md:
brain/ Identity.md Tools.md Canon/ finished, citable knowledge Active/ one note per live project
- Canon. Entry bar: would you cite this to do real work? If not, it does not go here. Keeps the reference layer trustworthy instead of just large.
- Active. One note per thread. A folder only when a thread earns it, meaning three or more notes. Most of your projects are one note, and one note does not get a folder.
Two folders, on purpose. A capture inbox is the obvious third one and it is deliberately not here. An inbox with no habit behind it becomes a junk drawer you stop opening, and a junk drawer full of unfiled notes makes the whole thing feel broken in week two. You add it later, once you are actually using this. It is the first item on the Next tab.
I have too many open projects. I am setting up two folders: Canon/ finished, citable knowledge. Bar: would I cite this to do real work? Active/ one note per live project Everything I have going on: [DUMP THE LIST. Messy is fine. Projects, clients, half-finished ideas, things you feel guilty about.] For each item tell me: 1. Canon, Active, or NEITHER 2. Whether it is genuinely ACTIVE (touched in the last 30 days) or actually dormant 3. The one-line note that should exist for it, if any Then apply these rules and tell me what they cut: - A folder gets created only when a thread has THREE OR MORE notes. Tell me which of my items are trying to be folders and have not earned one. - Nothing migrates from my old tools in a big bang. Only things I touch during real work move over. Tell me which items I should NOT move today. - If an item has no next action and I have not touched it in 30 days, say so plainly instead of filing it neatly. - I am deliberately NOT creating a capture inbox yet. If something does not belong in Canon or Active, do not invent a third folder for it. Tell me it stays where it currently lives until I touch it again. Be blunt about the dormant ones. Filing a dead project tidily is how it stays on my mind for another year.
git init in the folder, commit when you remember. Free, local, and it means an AI editing your files can never lose you anything. This is the single highest-value ten minutes here.The failure mode: building forty empty folders before there is content. That is not a brain, it is a second app you will abandon. Structure only when something needs it.
Capture the correction
Everything above is setup. This is the part that decides whether it compounds or decays.
Every time the AI gets something wrong and you fix it, that fix goes into a file in the same sitting:
- Wrong fact or preference about you → Identity.md or the project note
- Wrong claim about what is connected → Tools.md
- Wrong process → a note in Canon
- Something that needs doing → your task list
An uncaptured correction is a correction you make again next week.
You just got something wrong and I corrected you. Capture it before we continue so I do not have to correct it again next week. Tell me: 1. What you got wrong, in one line. 2. WHY. Was the information missing from my brain folder, wrong in it, or present but not read? 3. Which single file this belongs in: - a durable fact or preference about me -> Identity.md or the project note - a wrong claim about what is connected or what works -> Tools.md - a process that needs fixing -> a note in Canon - something that needs doing -> my task list 4. The exact line to add or change, written to be useful to a future session with no memory of this conversation. Then make the edit. Do not describe it and call it done. Make it, and tell me the file and line you changed so I can check. If the real problem is that my entry-point file did not send you to the right document, say that instead. That is a gate problem, and patching the content would hide it.
Then stop building
The brain grows from use, not from more setup. Resist spending week two adding structure instead of doing work inside it. When you have actually been running this for a few weeks and want the next piece, the Next tab has it in order.
The next three things
In order. Each one is deliberately held back from the build because it solves a problem you do not have yet, and adding it early is how people abandon this.
Do not start this tab until the Status tab is fully green and you have used the core for at least two weeks. Everything here is an upgrade to a working system. Bolted onto an unused one, it is just more setup.
1. Add the Inbox
A third folder, Inbox/: one drop zone for anything that does not have a home yet. Raw captures, links, half-thoughts, meeting scraps.
Why it waited. An inbox is a promise to sweep it. Build it on day one and you get a junk drawer that fills up, never empties, and makes the whole system feel broken by week two. Build it after you have a working habit and it becomes the pressure valve it is supposed to be.
You are ready when you have caught yourself with something worth keeping and no obvious file to put it in, more than once. That friction is the signal. Before that, the answer is that it stays where it already lives.
The rule that makes it work: the inbox gets swept on a fixed schedule, weekly, into Canon, Active, or the trash. An unswept inbox is worse than no inbox, because it splits your attention between two places that both feel unfinished.
I have been running my brain folder for a few weeks and I am now adding a capture inbox. I held it back on purpose so it would not become a junk drawer. My folder currently: Canon/ finished, citable knowledge Active/ one note per live project [LIST ANYTHING ELSE THAT IS IN THERE] Do three things: 1. Add a line to my entry-point file telling you what Inbox/ is for and, more importantly, what it is NOT for. It is not a second Active folder and it is not where things go to be avoided. Keep it to two lines; that file has a hard line budget. 2. Write me a weekly sweep routine as a prompt I can paste every Friday. It should make you read everything in Inbox/ and, for each item, either promote it to Canon, attach it to a note in Active, or tell me to delete it. Force a decision on every item. "Leave it in the inbox" is not one of the options. 3. Tell me the failure signal to watch for: the specific observation that means the inbox is not working and I should delete it rather than keep feeding it. Be direct about number 3. I would rather remove the folder than maintain a graveyard.
2. Write down your first repeated process
The second time you explain the same multi-step task to your AI, stop and write it down instead. Trigger, numbered steps with the exact commands, the pitfalls you hit, and how to verify it actually worked.
Why it waited. Processes written before you have run the task are fiction. The useful version gets written the first time something non-obvious succeeds after friction, while the friction is still fresh.
SKILL.md, loaded automatically when the task matches. The format is shared between them, so a skill folder copies across..cursor/rules/ with glob targeting, if the process only applies to certain files.3. Your first scheduled job
Something that runs without you starting it. A morning summary, a weekly sweep, a recurring pull.
Why it waited, and this is the big one. Automation multiplies whatever is already there. Point it at a good context layer and you get leverage. Point it at an empty or wrong one and you get confident garbage on a schedule, which is worse than nothing because you stop checking it.
Two rules from the day the second job exists. Every recurring job needs exactly one named owner in one list, or you end up with duplicates nobody remembers creating. And a job whose failure matters must deliver its output somewhere you will see it, because a job that fails silently reports success forever.
Stop after this. Beyond three jobs and a handful of processes you are running an operation, not a notes folder, and that needs an owner list and a review cadence before it needs more features.
Are you actually done?
If any box is unchecked, you are not. Do not add tools to an incomplete setup.
Current state
The only score that counts
Thirty days from now, one question matters: what is this doing that you used to do yourself? If the answer is "it knows more about me," it has not paid for itself yet. If the answer names a specific thing off your plate, it has.
It has been about 30 days since I set up my brain folder. Audit it honestly. I would rather hear it is not working than be told it is. Read the folder and answer with evidence from the files, not impressions: 1. LEVERAGE. Name specific things this now does that I used to do myself. If you cannot name one concrete thing, say "nothing came off your plate" plainly. "It knows more about you" does not count. 2. DECAY. Which files have not been touched since setup? A brain that only gets read and never written is already dying. 3. CORRECTIONS. Is there evidence corrections actually got written into files, or did they happen in conversation and evaporate? Look for edits, not for a log claiming edits happened. 4. FACT CREEP. Reread my entry-point file. Have facts crept in that belong in the folder instead? List every one. Also give me its current line count: it should still be under 60. 5. BLOAT. How long is Identity.md now compared to one page? If it has grown, tell me which additions were facts that should have gone into the folder instead. 6. FOLDER TEST. Any folders in Active/ with fewer than three notes? Those should be single files. Anything in Canon/ I would not actually cite? That is not canon. 7. THE HONEST QUESTION. Am I using this, or did I build it and abandon it? Answer directly. If the evidence says abandoned, name the one smallest thing that would make it useful again.