# A small brain _that works_. How to build a personal brain, for one person or a few: a folder of plain notes, kept in a shape that you and any AI assistant can read, and kept true by a few small habits. A free guide from somai, offered purely as education. Everything you can try on this page runs in your browser: nothing you enter is stored, sent or used for anything else, and reloading the page clears it. Contents ## Contents --- Disclaimer Read first. ## Disclaimer **This guide and the somai personal brain skills are offered free, purely as educational content.** They are provided “as is”, without warranty of any kind, and somai takes no responsibility for them or for anything that results from using them, including lost or exposed data, charges from third-party services, or decisions made on the strength of an assistant’s answers. Nothing here is legal, security, data-protection or other professional advice. The tools, plans and settings it describes were checked in October 2026 and change often: check each provider’s current documentation and terms before relying on them. You remain responsible for what you put into your brain, who can see it, and which services you connect it to. --- The two skills If you use Claude: two skills that do it with you. ## Two skills that do it with you Two free skills from somai follow this guide and do the building with you. They are written for Claude, and ChatGPT or any assistant that can open a web link can follow them from a pasted link. With an assistant that can't, the guide itself works. * **somai personal brain builder.** Use it once, over a few sessions. It asks whether a personal brain is right for you, then builds one with you, writing each file only after you've seen it and said yes. * **somai personal brain health check.** Use it monthly, or on a schedule. It runs your test questions, checks the inbox, links, summaries, duplicates and your vocabulary, and writes one dated report of what to fix. It changes none of your notes. Two ways to use them: paste a link into a chat, or download and install them. ### Paste a link Nothing to install. Copy one of these into a new chat in Claude, ChatGPT or another assistant that can open web links, and send it. Your assistant reads the skill from GitHub and follows it, one question at a time. In a chat that can't see your notes folder, it gives you the files to download instead of writing them. somai personal brain builder ``` Read the skill at https://raw.githubusercontent.com/Somai-Studio/somai-personal-brain-skill/main/skills/somai-personal-brain-builder/SKILL.md and follow its instructions. When it refers to a file in references/, open it from https://raw.githubusercontent.com/Somai-Studio/somai-personal-brain-skill/main/skills/somai-personal-brain-builder/references/ (for example https://raw.githubusercontent.com/Somai-Studio/somai-personal-brain-skill/main/skills/somai-personal-brain-builder/references/disclaimer.md). Help me build a personal brain. ``` copy for your assistant somai personal brain health check ``` Read the skill at https://raw.githubusercontent.com/Somai-Studio/somai-personal-brain-skill/main/skills/somai-personal-brain-health-check/SKILL.md and follow its instructions. When it refers to a file in references/, open it from https://raw.githubusercontent.com/Somai-Studio/somai-personal-brain-skill/main/skills/somai-personal-brain-health-check/references/ (for example https://raw.githubusercontent.com/Somai-Studio/somai-personal-brain-skill/main/skills/somai-personal-brain-health-check/references/disclaimer.md). Run a health check on my personal brain. ``` copy for your assistant If your assistant says it can't open the link, switch on its web search and try again, or download and install the skill instead. ### Or download and install Better if you'll come back to it: once installed, Claude offers the skill whenever it fits, with no link to paste. [Download the skills from GitHub](https://github.com/Somai-Studio/somai-personal-brain-skill/releases/latest): a ZIP for each. * **claude.ai and the Claude desktop app:** switch on code execution in your settings, open Customize → Skills, choose + → Create skill → Upload a skill, select the ZIP (don't unzip it), and switch the skill on. * **Claude Code:** unzip it and copy the skill's folder into `~/.claude/skills/`, or into a project's `.claude/skills/` folder for that project only. Menu names were checked in October 2026 and may have changed since. Full steps are in [the skills' README](https://github.com/Somai-Studio/somai-personal-brain-skill#install). The skills send nothing anywhere, and the disclaimer above applies to them too. --- § 00 Is it for you? A small brain that works ## A small brain that works _How to build a personal brain, for one person or a few._ **In two lines:** a personal brain is a folder of plain notes, kept in a shape that you and any AI assistant can read, and kept true by a few small habits. This guide shows you how to design one, build it with your assistant doing the typing, and keep it working - without depending on any single app. ### Who this is for You run your own work, or work closely with one or two others. You use an AI assistant most days. You can follow setup steps, but you don’t want to write code. And you’re tired of explaining the same background to your assistant every time - who the client is, what was decided last month, how you like things done. If that’s you, a personal brain is worth a few hours to set up and fifteen minutes a week to keep. **A few means up to about three people** who work closely together and can all see everything in the brain. Beyond that, a personal brain isn’t the right option - page 15 explains what is. ### What you’ll have after a month * About twenty to fifty good notes: the people, organisations, projects and decisions that matter to your work. * A short rules file that tells any assistant how your brain is laid out and how to behave in it. * An assistant that answers questions about your work **and tells you which note the answer came from**. * Twenty test questions that show you, every month, whether it’s still giving right answers. * One or two small automations - a morning brief, a weekly tidy-up report - running on your laptop or in the cloud. ### What it isn’t * **Not an app.** The method works with Obsidian, Notion, a plain folder and whichever assistant you prefer. Tools are named honestly, with dates, because they change. * **Not an archive.** Brains that try to keep everything get worse, not better. This one keeps less, and keeps it better. * **Not for a team or a company.** Once four or more people write in it or rely on it - or different people must see different things - you need a company brain, with permissions and review this guide doesn’t cover. Page 15 tells you when you’ve reached that point. **Readiness check** stays in your browser: nothing you enter is stored or sent ### Is a brain right for you? Ten questions, about three minutes. 1\. Where would your brain live? On my laptop only In OneDrive / Google Drive / iCloud / Dropbox In GitHub Not sure 2\. Who would write in it or rely on it? Just me Me and one or two others Four or more people A whole team, department or organisation 3\. Can you name ten questions you or your clients ask again and again? Yes, easily Some Not really 4\. Roughly how much would you start with? A blank page Some notes already Thousands of notes or documents 5\. Which assistant do you mostly use? Claude ChatGPT Gemini Microsoft Copilot A local model Several 6\. Does your organisation run on... Microsoft 365 Google Workspace Neither / just me 7\. Is your laptop often off or asleep when you would want jobs to run? Yes No 8\. Would anything in it be sensitive - health, pay, HR, client material under confidentiality? No Some A lot 9\. Could you give it fifteen minutes a week? Yes Probably Honestly, no 10\. Do different people need to see different parts? No Yes show my result ### How to read this guide The pages build on each other, but each stands on its own: | | Page | You’ll come away with | | -- | -------------------------- | ----------------------------------------------- | | 1 | Why method, not tools | The twelve principles | | 2 | The design: five layers | The whole picture on one page | | 3 | Start from your questions | Your twenty questions and test file | | 4 | Your ontology | Your types and relationships | | 5 | The shape | Your day-one decisions, folders and rules file | | 6 | Anatomy of a good note | A note you can copy | | 7 | Getting things in | Your “never goes in” list and an intake routine | | 8 | Connecting structured data | Pointers, live connections and snapshots | | 9 | Connecting your assistant | Your assistant reading your brain | | 10 | Windows | A way to see and edit it | | 11 | Automations | Jobs that run on their own | | 12 | Keeping it true | A weekly and monthly routine | | 13 | Prompt library | Every prompt in one place | | 14 | Use cases | Five worked examples | | 15 | Tools, honestly | What to use now, and when you’ve outgrown it | **About the “Seen in practice” boxes.** They come from real brains we’ve built or studied - personal, small-business and company. They’re there as evidence, not as a description of anyone’s system, so they carry no names. **About the evidence.** Where a claim rests on research we say so, and we say what kind: a measured study, a practitioner’s report, or a vendor’s own claim. Much of this field is the last two. Tool details are correct as of **October 2026**; check them before relying on them. **About responsibility.** This guide and the somai personal brain skills are offered purely as educational content, and somai takes no responsibility for them or for what results from using them. The full [disclaimer](#disclaimer) applies throughout. [contents ↑](#contents) [01 Why method, not tools →](#page-1) --- § 01 Why method, not tools ## Why method, not tools **In two lines:** the tools for AI-readable notes are settling down to the same few parts, and they’ll keep changing. What decides whether your brain works is how you use them - what you keep, the shape of each note, how you handle time, who decides what’s true, and whether you test it. ### A brain is a habit with files Look at what people are actually building in 2026 and most of it has the same four parts: 1. **Plain text files** \- usually markdown, the format with `#` headings and `**bold**` \- in a folder you own. 2. **A window** for reading and editing them - Obsidian, a text editor, sometimes Notion. 3. **An assistant** that can read and write the folder - Claude, ChatGPT, Gemini, Copilot or a local model. 4. **A short rules file** at the top of the folder telling the assistant how things are laid out. That arrangement was popularised in April 2026 by Andrej Karpathy’s “LLM Wiki” note: raw sources kept as they arrived, a set of pages the assistant maintains, an index, a running log and a rules file. Many of the setups people describe online are versions of it. The parts are cheap and swappable. The habits around them are not - and the habits are where brains succeed or fail. ### What goes wrong **Too much.** The commonest failure is loading everything in. One builder put about four hundred files into their assistant’s reach - notes, PDFs, chat exports, old email - and answers got worse, including resurfacing a constraint dropped eighteen months earlier. Cut back to about thirty files and three core documents (who we are, what’s active, what’s been decided), and the answers recovered. **Stale.** An out-of-date note doesn’t make an assistant unsure - it makes it confidently wrong. In a survey by a documentation vendor, three quarters of the people asked had seen an AI tool answer from a stale document. **Untested.** Most people never check. They find out their brain was wrong when it matters. **Abandoned.** The note-taking world has a long history of people building elaborate systems and walking away from them. One writer publicly deleted ten thousand notes built over seven years. AI makes a pile searchable; it doesn’t make it useful. ### What the evidence says | Finding | What it means for you | Kind of evidence | | ------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | ---------------------------------------------------------------------------- | | Assistants get worse as you give them more to read, even on simple tasks, and similar-but-wrong material hurts most | Keep less. Point the assistant at the right few notes rather than everything | Measured (studies across many models, 2024-2025; one run by a search vendor) | | Out-of-date information drags answers down even when the current version is also there | Mark old notes as replaced; don’t leave two versions side by side | Measured (2025) | | Plain word search is competitive with “AI search” at this size | You don’t need special search to start | Measured (several studies, mostly small) | | Assistants are poor at counting and listing across many documents | “How many…?” and “List all…” need a table, not a search | Measured (2025) | | A short summary and a few properties at the top of each note help the assistant pick the right one | Make every note describe itself | Measured (2025-2026) | | The most valuable content is decisions - including what you decided _against_ \- and how you work | Write those first | Practitioner reports, several | ### The twelve principles **Principle cards** stays in your browser: nothing you enter is stored or sent ### The twelve principles Open a card for the reason, the evidence and where the guide puts it into practice. Tick the ones you do already. 01 **A brain is a habit with files, not an app.** why, and the evidence Choose tools you can leave. I do this already 02 **Start from your questions, not your data.** why, and the evidence Write down the twenty questions you and your clients ask most. The brain exists to answer those. In practice: [page 3](#page-3) I do this already 03 **Write less, and better.** why, and the evidence Twenty good notes beat four hundred files. Evidence: Assistants get worse as you give them more to read, even on simple tasks, and similar-but-wrong material hurts most. (Measured (studies across many models, 2024-2025; one run by a search vendor)) I do this already 04 **Keep raw and distilled apart.** why, and the evidence Sources stay exactly as they arrived; what the brain "believes" lives in notes that cite them. Guesses are labelled as guesses. I do this already 05 **One note per thing.** why, and the evidence Each person, organisation, project, decision and definition has one home; everything else links to it. In practice: [page 4](#page-4) I do this already 06 **Every note describes itself.** why, and the evidence A clear title, a two-line summary at the top, a handful of properties. Evidence: A short summary and a few properties at the top of each note help the assistant pick the right one. (Measured (2025-2026)) In practice: [page 6](#page-6) I do this already 07 **Time is data.** why, and the evidence Date your facts. When something changes, mark the old note as replaced and point to the new one. Never overwrite silently. Evidence: Out-of-date information drags answers down even when the current version is also there. (Measured (2025)) I do this already 08 **Never copy live data in.** why, and the evidence Point to the system that holds it. Counts and lists come from a table. Evidence: Assistants are poor at counting and listing across many documents. (Measured (2025)) In practice: [page 8](#page-8) I do this already 09 **The AI drafts; a person decides.** why, and the evidence The assistant can propose, tidy and summarise. Nothing becomes "what we believe" until a person accepts it. I do this already 10 **Make two decisions on day one:** why, and the evidence where the brain lives and how it syncs, and what never goes in. Both are expensive to change later. In practice: [page 5](#page-5), [page 7](#page-7) I do this already 11 **Test it with your own questions.** why, and the evidence Every month. A perfect score means the test is too easy. In practice: [page 12](#page-12) I do this already 12 **Obsidian is a good window, not an engine.** why, and the evidence It's an excellent way to read, edit and see your notes. It doesn't make the answers good - the method does. In practice: [page 10](#page-10) I do this already Tick the principles you follow already, and the pages to start with appear here. > **Seen in practice.** “It ran” is not “it worked.” In one brain a daily import ran every morning for a week, looked healthy, and filed nothing. Every principle above has a version of this lesson behind it: check the outcome, not the activity. ### Sources * Andrej Karpathy, “LLM Wiki” (April 2026) - * Chroma, “Context Rot” (July 2025) - * Liu et al., “Lost in the Middle” (TACL 2024) - * JA Westenberg, “I Deleted My Second Brain” (June 2025) - * Slite, survey on stale documentation (June 2026) - * The remaining studies are listed on the [references page](#references). [contents ↑](#contents) [02 The design →](#page-2) --- § 02 The design five layers ## The design: five layers **In two lines:** a personal brain has five layers - notes in plain files, a graph of how they connect kept in those same files, pointers to the systems that hold live data, a way for your assistant to read it, and the habits that keep it true. Each layer is simple; the value is in having all five. **Layer diagram** stays in your browser: nothing you enter is stored or sent ### The picture Open a layer to see what it is, an example, and what goes wrong without it. 1. 5 Upkeep and trust: the habits The habits: an inbox where the assistant drafts and you accept, a weekly fifteen minutes, a monthly test, and automations that only create new files. Example: A draft lands in inbox/; you accept it before it becomes a note. **Without it:** the brain is right on the day you build it, and drifts from then on. Builds it: [Page 7](#page-7) · [page 11](#page-11) · [page 12](#page-12) 2. 4 Access: how your assistant reads it How your assistant reads the brain: a short rules file, a home page, and the assistant pointed at the folder. Example: AGENTS.md - rules only, never a summary of what is in the brain. **Without it:** each conversation starts from scratch, and the assistant guesses at your conventions. Builds it: [Page 5: the shape](#page-5) · [page 9: connecting your assistant](#page-9) 3. 3 Structured data: pointed to, not copied Records other systems hold - CRM, tasks, accounts - pointed to, connected to or snapshotted, never copied in. Counts come from tables. Example: A pointer note saying where the sales figures live, holding no figures. **Without it:** copied figures go stale, and the brain answers confidently with last quarter's numbers. Builds it: [Page 8: connecting structured data](#page-8) 4. 2 Knowledge graph: kept in the same files The connections between notes, written into the notes themselves: plain links in the text, named relationships in properties. Example: works\_at: "\[\[client\]\]" in a person's properties. **Without it:** "Who do we know at the client?" becomes a hunt through prose, and the answer depends on what the assistant happens to read. Builds it: [Page 4: your ontology](#page-4) 5. 1 Source of truth: a folder of plain files Everything the brain knows, in plain markdown files in a folder you own: sources kept as they arrived, and notes that cite them. Example: sources/ holds a meeting transcript exactly as it came; people/main-contact.md cites it. **Without it:** your knowledge lives inside a vendor's memory feature, where you can't fully see it or take it with you. Builds it: [Page 5: the shape](#page-5) · [page 6: anatomy of a good note](#page-6) Seen and edited through a window: Obsidian, Notion, a text editor ([page 10](#page-10)). ### Layer 1 - Source of truth: a folder of plain files Everything the brain knows lives in plain markdown files in a folder you own. There are two kinds: * **Sources** \- documents, transcripts, articles, exports - kept exactly as they arrived and never edited. * **Notes** \- one per person, organisation, project, decision, topic - written by you (or drafted by the assistant and accepted by you). Each one cites the sources it rests on. _Why plain files:_ every assistant can read them, every window can show them, they outlive any app, and you can see exactly what’s there. _Without it:_ your knowledge lives inside a vendor’s memory feature, where you can’t fully see it or take it with you. → [Page 5: the shape](#page-5) · [page 6: anatomy of a good note](#page-6) ### Layer 2 - Knowledge graph: kept in the same files The connections between your notes are written into the notes themselves: * **Plain links** in the text - “we agreed this with `[[main-contact]]`” - for passing mentions. * **Named relationships** in each note’s properties - `works_at: "[[client]]"`, `supersedes: "[[pricing-2025]]"` \- for connections you’ll ask about, filter or count. There’s no separate graph database to build or keep in step. Obsidian draws the graph from the files; Bases tables query it; your assistant reads it with ordinary search. _Without it:_ “Who do we know at the client?” becomes a hunt through prose, and the answer depends on what the assistant happens to read. → [Page 4: your ontology](#page-4) ### Layer 3 - Structured data: pointed to, not copied Your CRM, task tool, accounts and spreadsheets already hold their records. The brain doesn’t copy them. Instead it uses one of three patterns: * a **pointer note** saying where something lives and who owns it; * a **live connection** that lets the assistant ask the system directly; * a **snapshot** \- a dated copy written by an automation, marked as machine-made and never hand-edited - when a live connection isn’t practical. Questions that need counting or listing (“how many open deals?”) are answered from a table, never from searching notes. _Without it:_ copied figures go stale, and the brain answers confidently with last quarter’s numbers. → [Page 8: connecting structured data](#page-8) ### Layer 4 - Access: how your assistant reads it * A short **rules file** (`AGENTS.md`) at the top of the folder: how the brain is laid out, the note types, what never to do. Rules only - never a summary of what’s in the brain. * A **home page** that lists what’s where and links to the main views. * Your **assistant**, pointed at the folder - by opening it directly, through a connector, or by uploading the key notes. _Without it:_ each conversation starts from scratch, and the assistant guesses at your conventions. → [Page 5: the shape](#page-5) · [page 9: connecting your assistant](#page-9) ### Layer 5 - Upkeep and trust: the habits * New material lands in an **inbox**; the assistant drafts; **you accept** before it becomes a note. * A **weekly fifteen minutes** to clear the inbox and mark what’s been replaced. * A **monthly test** with your own questions. * **Automations** for the repetitive parts - on your laptop or in the cloud - that create new files and never edit yours. _Without it:_ the brain is right on the day you build it, and drifts from then on. → [Page 7](#page-7) · [page 11](#page-11) · [page 12](#page-12) ### Windows: how you see it The files are the brain; the window is how you look at it. **Obsidian** is the recommended window - good editing, a properties panel, a graph view and Bases tables over your notes. Notion, Logseq and a plain text editor are alternatives, each with trade-offs. → [Page 10: windows](#page-10) ### How this differs from what’s out there | Approach | What it gets right | What it leaves out | | ------------------------------------------------------------------------------------ | ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- | | **The “LLM Wiki” pattern** (plain files, an assistant-maintained wiki, a rules file) | Plain files; raw and distilled kept apart; a log | Named relationships, connections to live data, handling of time, a way to test it | | **Assistant memory and projects** (Claude, ChatGPT, Gemini, NotebookLM) | Nothing to set up | Locked to one vendor; hard to see exactly what it “knows”; hard to leave | | **Memory products and AI-built knowledge graphs** | Automatic | The graph lives in a database you can’t read or edit; their published benchmarks are contested | | **AI note apps** (Notion AI, Tana, Capacities) | Polished; types and fields built in | Your structure lives inside the app | | **Basic Memory** | Keeps a graph in plain markdown files - the closest to this design | A tool, not a method: it doesn’t tell you what to keep, how to handle time, or how to test | | **This guide** | All five layers, in files you own, with the habits that keep them true | Not a product - it needs fifteen minutes a week from you | We’d rather say it plainly: none of the individual parts is new. The combination, and the method for keeping it true, is the point. ### Sources * Karpathy, “LLM Wiki” - * Basic Memory - * Obsidian help: Bases - * See also the [references page](#references). [contents ↑](#contents) [03 Start from your questions →](#page-3) --- § 03 Start from your questions ## Start from your questions **In two lines:** before you write a single note, write down the twenty questions you most want your brain to answer. They decide what goes in, how it’s shaped, and - later - how you check it’s still telling the truth. ### Why questions come first Most brains start from data: “let’s get all my notes and email in”. That’s how they end up with four hundred files and worse answers. Starting from questions turns it round. You keep what answers a question you actually ask, and nothing else. The same questions do three jobs in this guide: 1. **Scope** \- they tell you what to write first (this page). 2. **Shape** \- the nouns and verbs in them become your types and relationships ([page 4](#page-4)). 3. **Test** \- with their answers written down, they become a monthly check ([page 12](#page-12)). > **Seen in practice.** One company brain started by collecting around two hundred real questions from the people who’d use it, then kept fifty of them - each with an answer someone had signed off - as its standing test. The first brain you build won’t need that many; twenty is plenty. ### Where to find your questions You already ask them. Look at: * **This week’s work.** What did you have to look up, or ask someone, or dig out of an old email? * **Your clients or colleagues.** What do they ask you that you have to think about before answering? * **Your assistant.** What background do you keep re-typing at the start of a conversation? * **Decisions.** What did you decide in the last six months that someone will one day ask “why did we…?” about? * **Handovers.** If you were away for a month, what would someone covering for you need to know? ### Five kinds of question Aim for a mix. Each kind needs something slightly different from the brain: | Kind | Example | What the brain needs | | ----------------- | --------------------------------------------- | ------------------------------------------------------------- | | **Look-up** | What’s our main contact’s role at the client? | One good note per person or thing | | **Relationship** | Who do we know at the client? | Named relationships ([page 4](#page-4)) | | **Why and when** | Why did we change our pricing in January? | Decision notes that record the reasons and what they replaced | | **Status** | Where are we with the client review? | Project notes kept current - or a pointer to the task tool | | **Count or list** | How many proposals did we send this quarter? | A table, not a search ([page 8](#page-8)) | If most of your questions are counts and lists, your brain should lean on tables and live connections. If most are “why”, lean on decision notes. ### Write the answer and where it should come from For each question, write four things: 1. **The question**, in the words you’d really use. 2. **Its kind** \- look-up, relationship, why and when, status, or count and list. 3. **The answer you’d expect**, as of today. 4. **The note it should come from** \- even if that note doesn’t exist yet. That last column is the important one. It tells you which notes to write first. Later, when you test, it lets you tell two different failures apart: the assistant **found the wrong note**, or it **found the right note and still answered wrongly**. Fix the first kind before the second. Example, in the file `how-we-work/test-questions.md`: | # | Question | Kind | Expected answer (as of 15 Oct 2026) | Should come from | | - | ----------------------------------------- | -------------- | ----------------------------------------------------------------- | ----------------------------------------------------------------------------- | | 1 | Who’s our main contact at the client? | look-up | Their head of operations, \[name\] | people/main-contact.md | | 2 | Why did we move to fixed-fee pricing? | why and when | Clients wanted cost certainty; hourly billing was losing renewals | decisions/pricing-2026.md | | 3 | What did we agree at the client kick-off? | look-up | Scope limited to operations; report due end of April | meetings/2026-03-03-client-kick-off.md | | 4 | How many active clients do we have? | count and list | Seven | the organisations view, filtered to active clients (views/organisations.base) | On top of your twenty, add two questions **the brain should refuse to answer** \- something on your “never goes in” list ([page 7](#page-7)). A good brain says “I don’t have that”, not a guess. That makes twenty-two in all. **Question builder** stays in your browser: nothing you enter is stored or sent ### Write your twenty questions Place 1 of 5 **This week's work.** What did you have to look up, or ask someone, or dig out of an old email? A question, in the words you would really use add question previous place next place Two questions the brain should refuse - something on your never-goes-in list ([page 7](#page-7)) Should refuse 1 Should refuse 2 download test-questions.md Your questions also go on to the ontology builder on [page 4](#page-4). ### Prompts for this step **Find my questions** \- run it over material you’re happy for the assistant to read: ``` Read [the folder / these notes / my last month of meeting notes]. List the questions that came up more than once, or that took real effort to answer - things people asked me, things I had to look up, decisions someone may later ask "why" about. Group them as look-up, relationship, why-and-when, status, and count-or-list. Don't answer them. ``` **Turn them into a test file** ``` Here are my twenty questions: [paste]. Create how-we-work/test-questions.md as a table with columns: number, question, kind (look-up, relationship, why and when, status, or count and list), expected answer (leave blank where I haven't given one), the date the answer was true, and the note it should come from (suggest a filename using our folders if the note doesn't exist yet). Add two questions the brain should refuse to answer because the material is on my "never goes in" list. ``` ### Sources * Anthropic, on building tests for AI systems: twenty to fifty simple tasks drawn from real failures is a good start (January 2026) - see the [references page](#references). * Hamel Husain, on separating retrieval failures from answer failures, and why a perfect score means the test is too easy - see the [references page](#references). [contents ↑](#contents) [04 Your ontology →](#page-4) --- § 04 Your ontology the things your brain knows about, and how they connect ## Your ontology: the things your brain knows about, and how they connect **In two lines:** decide the kinds of things your brain holds (people, organisations, projects, decisions…) and the handful of ways they connect, then write them down in one place. Start small, and add to it only when one of your own questions needs it. “Ontology” is a big word for a small idea. It is your list of **types** (the kinds of things you keep a note about) and **relationships** (the named ways one thing connects to another). You already have one in your head - “our contact works at the client”, “this decision replaced that one”. Writing it down is what lets you, a colleague and an AI assistant all file and find things the same way. ### Why bother Without an agreed shape, every note is filed a little differently. One builder found the same contact written three different ways across three sessions with an AI, because nothing told it which way was right. Answers then depend on which version the assistant happens to read. With a shape, two things become possible: * **Questions turn into filters.** “Who do we know at the client?” is no longer a search through prose - it is a list of every note whose `works_at` is the client. * **The graph means something.** The lines between your notes say _how_ things are connected, not just _that_ they are. > **Seen in practice.** In one personal vault of about 5,800 notes, 95% of the links sit in named fields - a person’s organisation, a meeting’s attendees, a project’s people. Questions like “who at this company have I met?” and “who has gone quiet?” became a filter rather than a search. ### Step 1 - Start from your questions, not from a diagram Take the twenty questions you wrote on [page 3](#page-3). Every type and every relationship has to earn its place by helping answer one of them. If no question needs it, leave it out. Ontology builders call these **competency questions**: the questions the structure must be able to answer. They do a second job later - they become your test (see [page 12](#page-12)). ### Step 2 - Nouns become types, verbs become relationships Underline the nouns in your questions and circle the verbs. The nouns that keep coming back are your types. The verbs that connect two nouns are your relationships. | Your question | Nouns → types | Verbs → relationships | | ---------------------------------------- | -------------------- | --------------------- | | Who do we know at the client? | person, organisation | _works at_ | | When did I last meet our main contact? | meeting, person | _attended_ | | Which decision replaced the old pricing? | decision | _replaced_ | | What’s still open on the client review? | project | _part of_ | | Who owns the onboarding project? | person, project | _owns_ | | Where did we get that figure? | source | _comes from_ | Most people find six to ten types and five to eight relationships cover nearly everything they ask. ### Step 3 - Begin with the starter set You don’t have to start from a blank page. This set covers the commonest questions for one person or a small team. Rename anything that doesn’t fit your work, and drop what you won’t use. **Eight types** \- set with a `type` property on every note: | Type | What it is | The question it answers | | ------------ | -------------------------------------------------------- | ------------------------------------------------------------ | | person | Someone you deal with | “Who…?” | | organisation | A company, client, supplier or group | “Who do we know at…?” | | project | A piece of work with an end | “Where are we with…?” | | meeting | A conversation on a date | “When did we last talk about…?” | | decision | Something settled, and why | “Why did we…?” | | topic | A theme or idea you come back to | “What do we know about…?” | | source | A document, article or recording you took something from | “Where did that come from?” | | note | Anything that doesn’t fit yet | \- (the catch-all, so nothing is forced into the wrong type) | **Six relationships** \- written as properties that hold links: | Relationship | Connects | Example | | ------------ | ---------------------------------------- | -------------------------------------------------------------- | | works\_at | person → organisation | Our main contact works at the client | | attendees | meeting → people | The 3 March review was attended by our contact and a colleague | | part\_of | anything → a project or topic | The pricing note is part of the client review | | owner | project or decision → person | A colleague owns onboarding | | supersedes | new decision → old decision | The 2026 pricing supersedes the 2025 pricing | | from | a fact or note → the source it came from | The headcount figure is from the Q3 board pack | Plus **`aliases`** \- the other names something goes by (its full company name, its initials). It isn’t a relationship; it stops the same thing getting two notes. ### What it looks like in a note Properties sit at the top of the note, between two lines of three dashes. Obsidian shows them as a neat panel; underneath they’re plain text any assistant can read. A person: ``` --- type: person title: Main contact at the client aliases: ["Main contact"] works_at: "[[client]]" summary: Head of operations at the client; our main contact for the review. updated: 2026-10-15 --- ``` A meeting: ``` --- type: meeting title: Client review kick-off date: 2026-03-03 attendees: ["[[main-contact]]", "[[colleague]]"] part_of: "[[client-review]]" --- ``` A decision that replaces an earlier one: ``` --- type: decision title: Pricing for 2026 status: accepted owner: "[[colleague]]" supersedes: "[[pricing-2025]]" from: "[[2026-01-board-pack]]" --- ``` Three small rules keep this working: * **Put links in properties inside quotes** \- `"[[client]]"`. Without the quotes the note’s properties break. * **Use a list when there could be more than one** \- `attendees` is always a list, even with one person in it. * **Don’t write the reverse.** There’s no `employs` on the client’s note. Obsidian’s backlinks and Bases find “everyone who works at the client” from the people’s notes. Writing both directions means two edits that will eventually disagree. ### Plain links or named relationships? You’ll use both. * **Plain links in the text** \- “we discussed this with \[\[main-contact\]\]” - for passing mentions. They cost nothing and need no decision. * **Named relationships in properties** \- for connections you’ll ask questions about, filter on, or count. The rule: **link freely in the text; promote a connection to a named relationship only when a question needs it.** > **Seen in practice.** One company vault designed thirteen relationship types up front. Across its real notes, 936 of 1,101 links turned out to be plain mentions, and eight of the thirteen types were never used. Start with the six, and plain links for everything else. ### Write it down in one place Keep a single **vocabulary note** \- for example `how-we-work/vocabulary.md` \- listing each type and relationship with: * what it means, in one line; * the question it answers; * its **template** (the blank note you copy to make a new one); * its **view** (the Bases table where you see all of them). List the **plain properties** every note uses as well - `title`, `summary`, `status`, `date`, `updated`, `checked`, `aliases`, `tags` \- so “use only the vocabulary” covers everything at the top of a note, not just types and relationships. Point your rules file (`AGENTS.md`) at the vocabulary note rather than copying it in. One home for the rules; everything else links to it. > **Seen in practice.** One vault had nine types but templates for only two of them, and saved queries for a plugin that wasn’t installed. Another used eleven types while its rules file listed nine. **Define a type only together with its template and its view** \- if you can’t be bothered to make those, you don’t need the type. ### Naming conventions * **Property names:** lowercase with underscores (`works_at`, not `Works At` or `worksAt`). Borrowing names from [schema.org](https://schema.org/Person) \- the vocabulary search engines use - keeps them recognisable to people and AI alike. * **Type names:** singular (`person`, not `people`). * **One note per thing.** Other spellings, nicknames and old names go in `aliases`, never in a second note. * **No abbreviations** you’ll forget in six months. ### Growing it, and pruning it Your ontology should change slowly and on purpose. * **Add** a type or relationship when a question you actually asked couldn’t be answered without it. Add its template and view at the same time, and a line to the vocabulary note. * **Check it against reality every quarter.** Ask your assistant to list every property in use and how often. Look for near-duplicates (`company` and `org`), typos, and fields that have drifted from what you meant. * **Retire** anything nobody has used in a quarter. Remove it from the vocabulary note and the template; let old notes keep it or clean them up. > **Seen in practice.** In one large vault a field documented as a short fixed list had grown to 38 free-text values, a documented field had been quietly replaced by another, and three near-identical fields for “last contact” had appeared. None of it was visible until someone compared the rules with the notes. ### Seeing it in Obsidian (October 2026) * **Graph view** draws links held in properties as lines, but every line looks the same - it shows _that_ things connect, not _how_. Use the **local graph** on a single note to spot orphans and missing links. * **Bases**, built into Obsidian, is where named relationships pay off. Embed a table on the client’s note that lists every person whose `works_at` is the client, and it stays up to date by itself. * **Plugins** such as Base Graph and Graph Link Types can colour or label lines by relationship. They’re young and optional - your data stays in the notes either way. Notion, Tana and similar tools have their own versions of types and relationships, but the structure lives inside the app. Here it lives in your files. ### Two shapes, both fine > **Seen in practice.** A personal brain built from years of email looked like a **relationship index**: thousands of short notes, almost all its links in named fields, built for “who do I know, and when did we last speak?”. A small business brain written by two people looked like an **operating manual**: a hundred and sixty longer notes, linked through the text around a home page, built for “what’s current and correct?”. Same method, different weights. Decide which yours is closer to - it tells you how much to lean on named relationships. ### What the evidence says * **Starting from questions** is long-standing practice in ontology design (Grüninger & Fox; Noy & McGuinness, _Ontology Development 101_). * **One note per thing, other names as aliases** is the standard answer to duplicates (the W3C’s SKOS vocabulary uses the same idea). * **Whether named relationships improve AI answers in a personal brain has not been measured.** On general benchmarks, graph-style retrieval helps most with questions that chain two or more facts (“who at our clients reports to our main contact?”) and can do worse on simple look-ups. Treat named relationships as a way to filter and count reliably, and check on your own questions whether they help your assistant. **Ontology builder** stays in your browser: nothing you enter is stored or sent ### Your types and relationships Your questions, one per line. They arrive from the question builder on page 3; you can also paste or edit them here. suggest types and relationships Or pick a use case on [page 14](#page-14) to start from an example. #### Types #### Relationships Add your own - only if one of your questions needs it type relationship add make my files ### Prompts for this step **Derive your ontology from your questions** ``` Here are the questions I want my brain to answer: [paste your questions]. Propose the smallest set of note types and named relationships that would let you answer all of them. Start from this starter set and only add to it if a question needs it: types person, organisation, project, meeting, decision, topic, source, note; relationships works_at, attendees, part_of, owner, supersedes, from. For each type and relationship, say which of my questions it serves. List anything in the starter set that none of my questions needs. Don't create any files yet. ``` **Write the vocabulary note and templates** ``` Using the types and relationships we agreed, create: 1. how-we-work/vocabulary.md - one short entry per type and relationship: what it means, the question it serves, its template and its view. 2. A template in templates/ for each type, with its properties at the top. Links in properties must be quoted, and plural relationships must be lists. 3. A Bases view for each type. Don't add inverse relationships. Show me the files before saving them. ``` **Add properties to notes you already have** ``` Go through the notes in [folder]. For each one, propose the type and any named relationships it should have, using only our vocabulary in how-we-work/vocabulary.md. Don't change any note. Write your proposals as a table in inbox/ontology-proposals.md with the note, the proposed properties, and how sure you are. ``` **Propose links** ``` Read [note or folder]. Suggest links that are missing: plain [[links]] where the text mentions a person, organisation, project or decision we have a note for, and named relationships from how-we-work/vocabulary.md where a property is clearly implied. Match names against aliases too. Never invent a target: if no note exists, list it as a "wanted note" instead. Write your suggestions to inbox/link-proposals.md and change nothing else. ``` **Quarterly check** ``` List every property used across the brain, how many notes use it, and any values that look like typos or near-duplicates. Compare it with how-we-work/vocabulary.md and tell me: properties in use but not in the vocabulary, vocabulary entries nobody uses, and fields whose values have drifted. Change nothing - just report. ``` ### Sources * Noy & McGuinness, _Ontology Development 101_ \- * Grüninger & Fox, enterprise modelling method (competency questions) - * W3C, SKOS Primer - * schema.org, Person - * Obsidian help: Properties - · Bases - · Graph view - * Steph Ango, “How I use Obsidian” - * GraphRAG-Bench, “When to use graphs in RAG” - * “Stop calling it memory” (the contact written three ways) - [contents ↑](#contents) [05 The shape →](#page-5) --- § 05 The shape day-one decisions, folders and the rules file ## The shape: day-one decisions, folders and the rules file **In two lines:** make four decisions before you build anything, then set up a plain folder structure, a home page and a short rules file. The folders tell you and your assistant what each note is for; the rules file tells the assistant how to behave. ### Four decisions to make on day one These are cheap to make now and expensive to change later. #### 1\. Where it lives and how it syncs Choose **one** of these and stick with it: * **A synced folder** (OneDrive, Google Drive, iCloud, Dropbox). Simplest. Automations run on your laptop, or in the cloud through a connector that can usually only _create_ files. * **A private GitHub repository.** A full history of every change, and cloud jobs can read and write it. Keep the laptop copy in a plain folder, **not** inside a synced one. * **On one laptop only.** Fine to start; you’ll move it the day you want a second device or a cloud job. > **Warning. Never put a git repository inside a OneDrive, Google Drive or iCloud folder.** The two sync systems fight over the same files and can damage the repository. Page 11 explains, with a case where it happened. #### 2\. What never goes in Write the list before you add anything. Pay, health, HR matters, live deal terms, anything about a person’s conduct, passwords and card numbers, client material you have no permission to keep. Keep it out **by where it lives** \- a separate folder or vault the assistant can’t reach - not by asking the AI nicely. → [Page 7](#page-7) #### 3\. Who writes Just you? Then you’re the reviewer. More than one person? Decide who accepts what the assistant drafts, and agree that **only one person or job writes to any one file**. #### 4\. Which assistant, first Pick the one you already use. The method is the same for all of them, and a single `AGENTS.md` rules file works across most. → [Page 9](#page-9) ### The starter folder ``` brain/ ├── AGENTS.md ← the rules file (read by most assistants) ├── CLAUDE.md ← one line: @AGENTS.md ├── home.md ← the front door: what's where, links to the views ├── log.md ← one line per change worth knowing about │ ├── inbox/ ← everything new lands here first ├── sources/ ← documents, transcripts, exports - as they arrived, never edited │ (plus a short type: source note describing each one you cite) │ ├── people/ ┐ ├── organisations/ │ ├── projects/ │ notes - one per thing, each with a type ├── meetings/ │ ├── decisions/ │ ├── topics/ ┘ │ ├── how-we-work/ ← vocabulary, test questions, never-goes-in list, procedures ├── templates/ ← one blank note per type ├── views/ ← Bases tables: all people, open projects, recent decisions │ ├── briefs/ ┐ machine-made: written by automations, ├── snapshots/ ┘ never hand-edited └── archive/ ← finished projects and replaced notes, kept for history ``` A few things to notice: * **Folders and types agree.** A note in `people/` has `type: person`. The folder is a quick visual cue; the property is what the assistant and your views rely on. Keep both. * **Raw and distilled are apart.** `sources/` is never edited; notes cite it. * **Machine-made files are fenced off.** Anything an automation writes goes in `briefs/` or `snapshots/`, so you never mistake it for something a person wrote - and never hand-edit something the next run will overwrite. * **Start with fewer folders if you like.** If you won’t have meetings or decisions yet, leave those folders out. Add them when the first note needs a home. > **Seen in practice.** Builders who started with elaborate folder schemes report rebuilding them - one engineer rebuilt from scratch twice. Others say a plain, numbered scheme was what made their assistant find things reliably. Start plain. ### The home page `home.md` is the front door for you and the assistant. Keep it short: * one paragraph on what this brain is for; * links to each folder’s view (`views/people.base`, `views/open-projects.base`…); * links to the rules file, the vocabulary and the test questions; * the date the brain was last reviewed. It is **not** a summary of what the brain knows. Summaries go out of date; links don’t. ### The rules file The rules file is the first thing most assistants read when they open your folder. Make it count by keeping it short. * **Rules, not knowledge.** How the brain is laid out, the note types, how to name files, what never to do. Not “this client is our biggest” - that belongs in a note. * **Short.** Anthropic recommends keeping these files under about two hundred lines; longer ones are followed less reliably. A study of rules files for coding assistants found they don’t generally improve results and add cost - and that overviews of the contents were no help. Put in only what the assistant couldn’t work out for itself. * **One file, linked from everywhere.** `AGENTS.md` is now a shared standard read by ChatGPT/Codex, Gemini’s command-line tool and GitHub Copilot. Claude reads `CLAUDE.md` first, so make that file a single line - `@AGENTS.md` \- which pulls in the master. On Windows use that line rather than a shortcut or link to the file. > **Seen in practice.** In one vault a rules document was copied into an assistant’s instructions and the copy had already drifted. In another, the rules file, the home page and a folder’s own notes disagreed about whether personal data was allowed. One home for every rule; everything else points to it. #### Starter rules file Copy, then edit the parts in square brackets. ``` # Rules for this brain This folder is [my / our] working knowledge about [what you do]. Start at home.md. ## How it is laid out - inbox/ - new material. Draft here; never treat it as settled. - sources/ - originals as they arrived. Never edit, rename or delete them. Short notes describing them (type: source) live here too. - people/, organisations/, projects/, meetings/, decisions/, topics/ - one note per thing. - how-we-work/ - the vocabulary, test questions, never-goes-in list and procedures. - briefs/, snapshots/ - written by automations. Never hand-edit; never edit a human note from a routine. - archive/ - replaced or finished notes, kept for history. ## Notes - Every note has properties at the top: type, title, summary, updated, and the relationships in how-we-work/vocabulary.md. Use only those types and relationships. - Filenames are lowercase-with-hyphens. One note per thing; other names go in aliases. - Links in properties are quoted: works_at: "[[client]]". - When something changes, don't overwrite it: create the new note, add supersedes, and set the old note's status to superseded. ## How to behave - Answer from the notes and say which note each fact came from. If the notes don't say, say so - don't guess. - Check the notes rather than relying on anything you remember from earlier. - Counts and lists come from the views or the source system, not from reading notes. - Draft new or changed notes in inbox/ and wait for [me / the owner] to accept them. - Never delete anything. - Never store what's on how-we-work/never-goes-in.md. If you meet it, stop and tell me. ## Live data - [Clients and deals live in [CRM]. Tasks live in [task tool]. Don't copy them in - ask the system, or use the latest file in snapshots/.] ``` ### Set up your window before you start If you use Obsidian, set three things in its settings on day one, before the defaults scatter files around: * **Default location for new notes:** `inbox/`. * **Attachment folder:** `sources/attachments/`. * **Daily notes folder** (if you use daily notes): `inbox/daily/`. > **Seen in practice.** In one large vault, an unset daily-notes folder left empty dated notes at the top level, alongside empty untitled canvases and files with mangled names from a script. Nothing broke - but it all had to be cleaned up by hand. **Starter folder** stays in your browser: nothing you enter is stored or sent ### Build my starter folder 1\. Where it lives and how it syncs A synced folder A private GitHub repository On one laptop only 3\. Who writes Just me Me and one or two others 4\. Which assistant, first Claude ChatGPT Gemini Microsoft Copilot A local model What the brain is about, in a few words (fills "\[what you do\]" in the rules file) Where clients and deals live (optional) Where tasks live (optional) Decision 2, what never goes in, comes from the questionnaire on [page 7](#page-7). download my starter folder A zip, made in your browser. ### Prompt for this step **Scaffold the brain** ``` Create a new brain in this folder. Make these folders: inbox, sources, people, organisations, projects, meetings, decisions, topics, how-we-work, templates, views, briefs, snapshots, archive. Create AGENTS.md from the rules I paste below, a CLAUDE.md containing only the line @AGENTS.md, a short home.md linking to each folder and to how-we-work/, and an empty log.md. Don't create any notes yet. Show me the list of files before you create them. [paste your edited rules file] ``` ### Sources * Anthropic, Claude Code memory and rules files - * AGENTS.md - * Linux Foundation, Agentic AI Foundation announcement (December 2025) - * ETH Zurich study of rules files for coding agents - arXiv 2602.11988 * Obsidian help: syncing notes - [contents ↑](#contents) [06 Anatomy of a good note →](#page-6) --- § 06 Anatomy of a good note ## Anatomy of a good note **In two lines:** a good note says what it is in its title, sums itself up in two lines, carries a few properties at the top, and links to everything it depends on. Here’s one, taken apart. ### The worked example: a decision Decisions are the most valuable notes most people keep - and the most often missing. This one records a (fictional) change to how a consultancy prices its work for one of its clients. ``` --- type: decision title: Fixed-fee pricing for the client review summary: We'll price the client review as a fixed fee in three stages, not hourly, because the client needs a firm budget before its board meets in April. status: accepted date: 2026-03-10 owner: "[[colleague]]" part_of: "[[client-review]]" supersedes: "[[client-hourly-rates-2025]]" from: ["[[2026-03-03-client-kick-off]]", "[[client-budget-email-2026-03-06]]"] updated: 2026-03-10 checked: 2026-10-15 --- # Fixed-fee pricing for the client review ## Context At the kick-off on 3 March, [[main-contact]] said the client's board needs a fixed budget for the review by its April meeting. Our 2025 work for them was billed hourly. ## Decision A fixed fee in three stages: discovery, findings, final report. Changes to scope are priced separately and agreed in writing. ## Alternatives we rejected - **Hourly with a cap** - Our contact said a cap still reads as "open-ended" to their board. - **A single fixed fee** - too much risk for us before discovery shows the real scope. ## Consequences - The proposal template for this client changes; see [[proposal-template]]. - Stage payments are invoiced at the end of each stage. ## Still open - Whether to offer the same structure to other clients - not decided. ``` ### Part by part, and why each is there | Part | What it does | Why it matters | | ----------------------------------------------- | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | | **Filename** fixed-fee-pricing-client-review.md | A stable, readable ID | Links point at it; lowercase-with-hyphens never breaks | | **type** | Says what kind of note this is | Views and the assistant filter by it ([page 4](#page-4)) | | **title** | Says what the decision is, not just “Pricing” | The title is the first thing searched and shown | | **summary** | The decision and its reason in two lines | Assistants pick the right note more often when each note sums itself up near the top | | **status** | proposed · accepted · superseded | Tells the reader whether to rely on it | | **date** | When it was decided | Time is data - “as of when?” is always the next question | | **owner** | Who’s accountable | “Who decided this?” has an answer | | **part\_of** | The project it belongs to | It appears in the project’s view automatically | | **supersedes** | The note this one replaces | The single most important line in a decision. The old note stays, marked superseded, so history is kept and nobody acts on it by mistake | | **from** | The sources it rests on | You - and the assistant - can check it | | **updated / checked** | Last changed / last confirmed still true | A note can be old and still right; checked says someone looked | | **Context** | What prompted it | Without it, the decision looks arbitrary in a year | | **Alternatives we rejected** | What you decided against, and why | Stops the assistant cheerfully re-suggesting them | | **Consequences** | What changes because of it | Links it to the work it affects | | **Still open** | What isn’t settled | Stops the note being read as more final than it is | > **Seen in practice.** In one small business brain, the most-linked notes were its canonical documents - brand rules, guidelines - and every one of them carried a version, who ratified it, and what it replaced. When everything points at a note, it had better say clearly whether it’s current. ### When the decision changes Don’t edit the old decision to say something new. Instead: 1. Write a new decision note, with `supersedes: "[[the-old-one]]"`. 2. Change the old note’s `status` to `superseded` and add one line at the top: _“Replaced by \[\[the-new-one\]\] on \[date\].”_ 3. Leave everything else in the old note alone. That pointer matters more than the status word. Anyone - or any assistant - who lands on the old note is sent straight to the current one. ### Smaller notes need less Not every note needs every part. A person note can be this short: ``` --- type: person title: Main contact at the client summary: Head of operations at the client; our main contact for the review. aliases: ["Main contact"] works_at: "[[client]]" updated: 2026-10-15 --- Prefers a short written summary after every call. Joined the client in 2024 from a logistics firm. See [[2026-03-03-client-kick-off]]. ``` The rule of thumb: **always** a title, summary, type and date; the relationships that answer your questions; and a body only as long as it needs to be. ### One thing per note, and not too long * **One subject per note.** A meeting note records the meeting; the decisions made in it get their own notes, linked from it. * **Split notes that keep growing.** A project log that runs to thousands of lines is hard for you to read and hard for an assistant to find the right part of. Split by year, by stage, or one note per decision. > **Seen in practice.** In one small vault the typical note was about 650 words - but one project note had grown to about 42,000 words, and a decisions log to more than 900 lines. Notes that size are hard for a person to read and hard for an assistant to find the right part of. **Annotated note** stays in your browser: nothing you enter is stored or sent ### Take the note apart Choose a note, then a highlighted part of it. the decision a person a meeting decisions/fixed-fee-pricing-client-review.md --- type: decision title: Fixed-fee pricing for the client review summary: We'll price the client review as a fixed fee in three stages, not hourly, because the client needs a firm budget before its board meets in April. status: accepted date: 2026-03-10 owner: "[[colleague]]" part_of: "[[client-review]]" supersedes: "[[client-hourly-rates-2025]]" from: ["[[2026-03-03-client-kick-off]]", "[[client-budget-email-2026-03-06]]"] updated: 2026-03-10 checked: 2026-10-15 --- # Fixed-fee pricing for the client review ## Context At the kick-off on 3 March, [[main-contact]] said the client's board needs a fixed budget for the review by its April meeting. Our 2025 work for them was billed hourly. ## DecisionA fixed fee in three stages: discovery, findings, final report. Changes to scope arepriced separately and agreed in writing. ## Alternatives we rejected - **Hourly with a cap** - Our contact said a cap still reads as "open-ended" to their board. - **A single fixed fee** - too much risk for us before discovery shows the real scope. ## Consequences - The proposal template for this client changes; see [[proposal-template]]. - Stage payments are invoiced at the end of each stage. ## Still open - Whether to offer the same structure to other clients - not decided. people/main-contact.md --- type: person title: Main contact at the client summary: Head of operations at the client; our main contact for the review. aliases: ["Main contact"]works_at: "[[client]]" updated: 2026-10-15 --- Prefers a short written summary after every call. Joined the client in 2024 from alogistics firm. See [[2026-03-03-client-kick-off]]. meetings/2026-03-03-client-kick-off.md --- type: meeting title: Client review kick-off date: 2026-03-03 attendees: ["[[main-contact]]", "[[colleague]]"] part_of: "[[client-review]]" --- Choose a highlighted part. ### Prompts for this step **Draft a decision note from a meeting** ``` Read meetings/[file]. For each decision made in it, draft a decision note in inbox/ using templates/decision.md: title, a two-line summary with the reason, status proposed, date, owner, part_of, from (the meeting), and sections for context, decision, alternatives rejected, consequences and still open. If it replaces an earlier decision, find that note and add supersedes. Quote nothing you can't find in the meeting note. Don't change any existing note. ``` **Check a note against the anatomy** ``` Check [note] against our note anatomy: does it have a type, a title that says what it is, a two-line summary, a date, the relationships our vocabulary expects for its type, and sources for its facts? Is it one subject, and short enough? List what's missing or wrong. Don't change it. ``` ### Sources * Michael Nygard, “Documenting Architecture Decisions” (the decision-record pattern) - * Studies on note summaries and metadata improving retrieval are listed on the [references page](#references). [contents ↑](#contents) [07 Getting things in →](#page-7) --- § 07 Getting things in ## Getting things in **In two lines:** start with twenty notes written by hand, then add sources one at a time through an inbox, with the assistant drafting and you deciding. Decide first what never goes in - and keep it out by where it lives. ### Start with twenty notes, by hand Your first notes should answer your first questions ([page 3](#page-3)). For most people that means: * **Who we are and how we work** \- one or two notes: what you do, for whom, your rules of thumb. * **What’s active** \- a note per live project or client. * **What’s been decided** \- a note per decision that someone will one day ask “why?” about. * **The people you deal with most** \- a short note each. Write them yourself, or dictate them to the assistant and correct the drafts. Twenty good notes will answer more of your questions than four hundred imported files. > **Seen in practice.** One person gave their assistant about four hundred files - notes, PDFs, chat exports, old email - and its answers got worse, including bringing back a constraint they’d dropped eighteen months before. They cut it to about thirty files and three core documents - who we are, active projects, decisions - and the answers recovered. ### Decide what never goes in Do this before you add anything else. Some material doesn’t belong in a brain that an assistant reads, however useful it would be: * pay, salaries and personal finances - balances, statements, account numbers (renewal dates and who your suppliers are are fine); * health information about anyone; * HR matters - performance, grievances, disciplinary; * anything about a person’s conduct or character; * live deal terms and anything under negotiation; * passwords, keys, card and bank numbers - write down _where_ a secret is kept, never the secret; * client material you don’t have permission to keep; * anything you’d be uncomfortable seeing quoted back in an answer to someone else. **Keep it out by where it lives, not by instruction.** Telling an assistant “don’t look at the HR folder” is a request, not a lock. Put sensitive material in a separate folder or vault that the assistant isn’t given access to. If you keep personal data about customers, confine it to one or two known folders, so that if someone asks you to delete their data, you know exactly where to look. > **Seen in practice.** People who keep health notes and journals tend to give them their own vault that their assistant can’t reach - some run a local model for that vault only. In one small business brain, the rules allowed customer personal data in two named folders only, so a deletion request could be handled completely. **Questionnaire** stays in your browser: nothing you enter is stored or sent ### What never goes in For each kind of material: do you have it, and if so, where does it live instead? Everything on this list stays out of the brain whatever you answer - the questions are about where it goes. Pay, salaries and personal finances - balances, statements, account numbers Do you have this kind of material? yes no not sure Would anyone be harmed or embarrassed if it appeared in an answer? yes no Are you allowed to keep it? yes no not sure Where it lives instead choose a separate folder or vault the assistant is not givenits own system (HR, payroll, the CRM)a password managernowhere: don't keep itsomewhere else Health information about anyone Do you have this kind of material? yes no not sure Would anyone be harmed or embarrassed if it appeared in an answer? yes no Are you allowed to keep it? yes no not sure Where it lives instead choose a separate folder or vault the assistant is not givenits own system (HR, payroll, the CRM)a password managernowhere: don't keep itsomewhere else HR matters - performance, grievances, disciplinary Do you have this kind of material? yes no not sure Would anyone be harmed or embarrassed if it appeared in an answer? yes no Are you allowed to keep it? yes no not sure Where it lives instead choose a separate folder or vault the assistant is not givenits own system (HR, payroll, the CRM)a password managernowhere: don't keep itsomewhere else Anything about a person's conduct or character Do you have this kind of material? yes no not sure Would anyone be harmed or embarrassed if it appeared in an answer? yes no Are you allowed to keep it? yes no not sure Where it lives instead choose a separate folder or vault the assistant is not givenits own system (HR, payroll, the CRM)a password managernowhere: don't keep itsomewhere else Live deal terms and anything under negotiation Do you have this kind of material? yes no not sure Would anyone be harmed or embarrassed if it appeared in an answer? yes no Are you allowed to keep it? yes no not sure Where it lives instead choose a separate folder or vault the assistant is not givenits own system (HR, payroll, the CRM)a password managernowhere: don't keep itsomewhere else Passwords, keys, card and bank numbers Do you have this kind of material? yes no not sure Would anyone be harmed or embarrassed if it appeared in an answer? yes no Are you allowed to keep it? yes no not sure Where it lives instead choose a separate folder or vault the assistant is not givenits own system (HR, payroll, the CRM)a password managernowhere: don't keep itsomewhere else Client material you don't have permission to keep Do you have this kind of material? yes no not sure Would anyone be harmed or embarrassed if it appeared in an answer? yes no Are you allowed to keep it? yes no not sure Where it lives instead choose a separate folder or vault the assistant is not givenits own system (HR, payroll, the CRM)a password managernowhere: don't keep itsomewhere else Anything you'd be uncomfortable seeing quoted back in an answer to someone else Do you have this kind of material? yes no not sure Would anyone be harmed or embarrassed if it appeared in an answer? yes no Are you allowed to keep it? yes no not sure Where it lives instead choose a separate folder or vault the assistant is not givenits own system (HR, payroll, the CRM)a password managernowhere: don't keep itsomewhere else Do any client contracts restrict what you can store? yes no not sure download never-goes-in.md It also goes into the starter folder on [page 5](#page-5). ### The inbox rule Everything new lands in `inbox/` first. That includes everything the assistant writes. 1. **A source arrives** \- a document, a transcript, an email you want to keep. It goes into `sources/` exactly as it is. 2. **The assistant drafts** \- new notes, or changes to existing ones - into `inbox/`, citing the source. 3. **You decide** \- accept (move the draft into place), edit, or bin it. Only then is it “what the brain believes”. This is the point practitioners agree on most: **the AI proposes; a person accepts.** It’s realistic at thirty drafts a week. If you find yourself facing three hundred, you’re taking in too much. **One source at a time.** Add a document, read what the assistant drafts from it, accept or fix, then add the next. Batch imports feel efficient and fill the brain with things nobody checked. ### Meetings Meetings are where most decisions and actions are born, and where most of the risk is. * **Choose which meetings go in.** Not every call needs capturing. Team meetings and client working sessions, yes; a quick catch-up, probably not. * **Some meetings should never be recorded** \- HR conversations, board meetings, legally privileged discussions, and meetings with clients in regulated industries. A law firm’s 2026 guidance lists exactly these, and adds that a person should check any AI summary before anyone relies on it. * **Keep the transcript as a source; distil the rest.** The transcript goes in `sources/`. The assistant drafts the decisions and actions into `inbox/`. You accept them. * **Transcripts carry personal asides.** People talk about their families, their health, their colleagues. When distilling, keep the work and leave the rest out entirely - don’t keep a whole transcript just because most of it was useful. * **Deleting a recording in your note-taker doesn’t delete copies** you’ve already exported into your brain. Delete those too. > **Seen in practice.** One brain’s summariser first refused to file whole transcripts because a single aside touched something off-limits. The fix was to keep the work content and leave the excluded topic out completely - not to throw away the meeting. ### Imports and generated notes Sometimes you’ll want to build notes from a big source - years of email, a contacts export. If you do: * **Set a threshold.** Create a person note only for someone you’ve exchanged several emails with, an organisation note only past a size you choose. Otherwise every newsletter sender gets a note. * **Mark machine-made notes.** Add a property such as `source: email-import` to every note the import creates, and make the import skip any note without it. That’s what lets you re-run the import safely without overwriting notes you’ve edited by hand. * **Watch it after the first run.** An import that ran once and never again goes stale without anyone noticing. > **Seen in practice.** One personal brain was built from years of email: a person note only after three exchanges, an organisation only past a size threshold, and every generated note marked so the import never overwrote a hand edit. It still produced about 4,600 person notes, and nearly half had nothing linking to them. Then the import stopped, and nothing flagged it for about eleven weeks. ### When a second person joins A personal brain can be shared by a few people - up to about three who work closely together and can all see everything in it. If a fourth person is coming, or the brain is meant for a whole team, read [page 15](#page-15) first: that’s the point where a personal brain stops being the right option. * **Decide where the shared copy lives** \- a shared drive folder or a private GitHub repository - and don’t mix the two ([page 5](#page-5)). * **Each person captures their own meetings** rather than everyone feeding one shared inbox. Teams that tried a single shared inbox reported friction over who processes what. * **Agree who accepts drafts** for each area, and that only one person or job writes to any one file. * **Keep a shared memory folder, if you use one, curated**: one fact per note, with the date it was learned, linked to the note it’s about. > **Seen in practice.** A two-person business brain keeps a folder of one-fact notes the assistant has learned - each with a `learned` date - so both people can see and correct what the assistant “remembers”. About a third of them had nothing linking to them. Link each one to the note it qualifies, so it turns up where it matters. ### Prompts for this step **Ingest one source** ``` I've added sources/[file]. Read it and draft into inbox/: new notes for any people, organisations, projects or decisions it introduces that we don't already have, and suggested changes to existing notes as separate drafts. Use templates/ and our vocabulary. Every fact must cite the source. Skip anything on how-we-work/never-goes-in.md and tell me you skipped it. Change nothing outside inbox/. ``` **Distil a meeting** ``` The transcript of [meeting] is in sources/. Draft into inbox/: a meeting note (date, attendees, part_of, a five-line summary), a decision note for each decision, and a list of actions with owners and dates. Keep work content only - leave out personal asides entirely, and anything on how-we-work/never-goes-in.md. Cite the transcript for every item. ``` **Review the inbox** ``` List everything in inbox/ with a one-line description, what it would change, and anything that looks wrong or unsupported by its source. Group by: ready to accept, needs my judgement, probably bin. Don't move or change anything. ``` ### Sources * Mayer Brown, guidance on AI note-takers in meetings (June 2026) - see the [references page](#references). * Runroom, on running a team brain from the decisions a team must make - see the [references page](#references). [contents ↑](#contents) [08 Connecting structured data →](#page-8) --- § 08 Connecting structured data ## Connecting structured data **In two lines:** your CRM, task tool, spreadsheets and accounts already hold their records - don’t copy them into your brain. Point to them, connect to them, or take a dated snapshot; and answer every “how many?” from a table. ### Why not just copy it in? Because a copy starts going stale the moment you make it. The deal value you pasted into a client note last month is now wrong, and your assistant will quote it with total confidence. The system that holds the record is always more current than your copy of it. There’s a second reason. Assistants are good at reading and summarising notes, but **poor at counting and listing across many of them**. In published tests, even the strongest models got fewer than half of “how many…” and “list every…” questions right when they had to work across a large set of documents. A table gives the exact answer. ### The rule of thumb | What it is | Where it belongs | | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | Prose, reasoning, decisions, how you work | **Notes** in your brain | | Records that change constantly and that another system owns - deals, tasks, invoices, stock | **That system** \- with a pointer note, and a live connection if you ask about it often | | Many similar rows you count or list - clients, proposals sent, applications made | **A table** \- a Bases view over notes, a CSV file, or a small database | | Numbers you want to compare over time | **Dated snapshots**, one new file each time | ### Pattern 1 - the pointer note The simplest pattern, and the one people most often skip. A pointer note says where something lives and who owns it. It holds no figures. ``` --- type: topic title: Where our sales figures live summary: Deals and pipeline live in [CRM]; monthly totals in the finance spreadsheet. Don't copy figures into notes. owner: "[[colleague]]" checked: 2026-10-15 --- - **Deals, stages, values:** [CRM] → Pipeline view. Owner: a colleague. - **Invoiced revenue by month:** the "Revenue 2026" spreadsheet in the finance folder. - **Ask the system, not this note.** If the assistant has a live connection to the CRM, use it; otherwise use the latest file in snapshots/pipeline/. ``` Your rules file then says: _“For anything about deals, read `how-we-work/where-sales-figures-live.md` first.”_ ### Pattern 2 - the live connection Most assistants can now connect directly to other systems through **connectors** \- the common standard for these is called MCP (Model Context Protocol). With one in place, your assistant can ask the CRM “which deals are in proposal stage?” and get the live answer. As of October 2026, official connectors exist for many popular systems - for example HubSpot, Attio and Pipedrive among CRMs - alongside Google Drive, Microsoft 365, Asana, Notion and others. A few cautions: * **Use the official one.** For popular systems there are often several community-made look-alikes. Check the publisher. * **Connect only what you ask about.** Every connector adds to what the assistant has to read before it starts. Anthropic’s engineers note that loading many tools up front wastes a lot of the assistant’s working space. One or two live systems is plenty to start. * **Check what it can do.** Some connectors only read; some can create or change records, sometimes without asking. Turn off what you don’t need. ### Pattern 3 - the snapshot When a live connection is too costly, too flaky, or not available, an automation can copy today’s numbers or list into a **new, dated file**: ``` snapshots/pipeline/2026-10-15.md ← written by the weekly pipeline job snapshots/pipeline/2026-10-08.md snapshots/pipeline/2026-10-01.md ``` Three rules: * **A new file each time, never an edit.** History is kept; trends stay visible. * **Marked as machine-made** \- `source: pipeline-snapshot` in its properties - and never edited by hand. * **Dated in the filename and the properties**, so “as of when?” is always answerable. > **Seen in practice.** A small business brain keeps its weekly figures as dated snapshots that are only ever added to, never changed, and rolls them up into one dashboard note. Nothing is overwritten, so any past week can be checked. ### Counting and listing from tables When a question starts “how many…” or “list all…”, answer it from a table: * **Bases views over your notes.** If every client has a note with `type: organisation` and `status: active`, a Bases view lists them and counts them exactly. Obsidian’s command-line tool (from 2026) can return a view’s results or a count directly, so an assistant can use it too. * **A CSV file for many small records.** Bases means one note per row - fine for clients, awkward for four hundred job applications or a year of invoices. Keep those as a spreadsheet-style CSV file and let the assistant read it. * **The source system’s own reports.** Often the best table is the one the CRM already has. > **Seen in practice.** One person’s job-hunting brain kept its judgement in notes - the scoring rubric, the master CV, a daily digest - and its rows in CSV files: every role evaluated, every application, every outreach. The CSVs were what stopped the same job being assessed twice. ### When your brain feeds other systems Sometimes the traffic runs the other way: a price list or a set of rules kept in your notes is read by another system. Treat that link like software, with its own check. > **Seen in practice.** In one small business brain, product notes feed a price list to a live checking system automatically. A gap in what triggered the update left a fix undeployed for a day - while everything looked done. The sync from notes to system needs its own check, just like any other automation. **Pattern chooser** stays in your browser: nothing you enter is stored or sent ### Pointer, live connection, snapshot or table? A system that holds records What it holds How often do you ask about it? most weeks now and then Does someone else own the records - another system, or another person? yes no, they're mine to keep Do you need history over time? yes no recommend ### Prompts for this step **Write a pointer note** ``` Create how-we-work/where-[thing]-lives.md as a pointer note: which system holds [thing], which view or report to use, who owns it, and an instruction to ask the system rather than this note. Include no figures. Then add one line to AGENTS.md telling the assistant to read this note before answering questions about [thing]. ``` **Set up a snapshot** ``` Write a prompt for a weekly job that reads [system] and writes a new file snapshots/[name]/YYYY-MM-DD.md with: [the fields you want]. It must never edit an existing file, must mark the new file with source: [name]-snapshot, and must add a line to log.md with the date and the number of rows. Save the prompt as prompts/[name]-snapshot.md. ``` **Answer a count properly** ``` How many [clients / proposals / applications] [condition]? Answer from [views/… / the CSV / the source system], not by reading notes. Say which table you used and list the items you counted. ``` ### Sources * Anthropic engineering, “Code execution with MCP” (November 2025) - * Florian Bruniaux, Claude Code Ultimate Guide: team knowledge base (September 2026) - * Obsidian command-line interface - * Scotty Peterson, a job-hunt system built with Claude Code (July 2026) - * Counting and aggregation studies (GlobalQA, OOLONG) - see the [references page](#references). [contents ↑](#contents) [09 Connecting your assistant →](#page-9) --- § 09 Connecting your assistant ## Connecting your assistant **In two lines:** the best connection is the simplest one that lets your assistant read the folder directly - and, ideally, write drafts into your inbox. Every major assistant can now do some version of this; here’s how, as of October 2026, with the trade-offs. ### Three ways an assistant can reach your brain | Way | How it works | Good for | Watch for | | ------------------------ | --------------------------------------------------------------------------------------------- | -------------------------------------------------------------- | ----------------------------------------------------------- | | **It opens the folder** | A desktop or command-line assistant is given your brain’s folder and reads the files directly | Most people - it sees everything current, and can write drafts | Desktop app must be open; check what it’s allowed to change | | **Through a connector** | The assistant reaches the files in Google Drive, OneDrive or GitHub | Using the brain from the web or a phone; cloud automations | Some connectors only read; some can only create new files | | **You upload key notes** | You add notes to a “project” or “notebook” in the assistant | A quick start; a read-only reference | A copy, not your brain - it goes stale unless it syncs | ### However you connect, ask well * **Start from the home page.** “Read home.md first” gives the assistant your map. * **Ask for the source.** “Say which note each fact came from.” It makes wrong answers easy to spot. * **Tell it to check, not remember.** Assistants trust whatever summary they were given over the notes themselves. In one small test, models given an out-of-date summary in their rules file answered from it without opening the notes that had the current facts; a one-line instruction to check the notes fixed most of them. The starter rules file on [page 5](#page-5) includes that line. * **Few notes, whole folder; many notes, let it search.** Under a few hundred short notes, an assistant can read the relevant folder in full. Beyond that, let it search - plain word search works well at this size. **Your assistant** stays in your browser: nothing you enter is stored or sent ### How to connect yours Claude ChatGPT and Codex Google Gemini Microsoft Copilot Local models #### Claude **Simplest path** (paid plan - Pro or above): 1. Install the Claude desktop app. 2. Give Claude access to your brain’s folder. It then appears under **Trusted folders** in settings, and Claude can read and write files there. 3. Put your house rules in `AGENTS.md` (with a one-line `CLAUDE.md` that says `@AGENTS.md`), or in the folder instructions Claude offers when you choose a folder. 4. Approve file changes as they come up. By default it asks before deleting anything. **Other options:** * **Claude Code** \- in the desktop app’s **Code** tab, choose the **Local** environment, then **Open folder…** and pick your brain’s folder. No extra installs needed. Better for setting up automations and bulk tidy-ups. Claude Code also reads `AGENTS.md` on its own when there’s no `CLAUDE.md`. * **Projects** \- upload key notes as project knowledge, or sync from GitHub (a manual “sync now”, read-only). A copy, not your brain. Sharing projects needs a Team or Enterprise plan. * **Desktop extensions and the filesystem connector** \- older ways to give Claude a folder; folder access in the app now covers most needs. * **Custom connectors** \- for reaching a brain hosted somewhere online. Available on all plans; the server has to be reachable from the internet. **Privacy:** on Free, Pro and Max plans, the **Model Improvement** setting (in Privacy Settings) decides whether your chats can be used for training. With it on, they can be kept, de-identified, for up to five years. Chats you delete are removed from Anthropic’s systems within thirty days. Team and Enterprise plans don’t train on your data by default. **Note:** as of October 2026 Anthropic is gradually merging Claude’s chat and Cowork modes into one app; screen names may differ from these. #### ChatGPT and Codex **Simplest path** (paid plan): 1. Install the ChatGPT desktop app. 2. Choose **Work** (or Codex) and open your brain’s folder. It can use local files with your permission, where your plan or workspace allows. 3. Put your rules in `AGENTS.md` \- Codex reads it automatically. **Other options:** * **Codex** (desktop app, command line or code editor) - opens the folder and can write to it. Included across ChatGPT plans; check which sandbox setting it uses and choose “write in the folder” rather than full access. * **Projects** \- upload notes (up to 25 files per project on Plus, 40 on Pro and business plans), or add Google Drive folder links as sources. Projects can be shared on every plan. * **GitHub connector** \- read-only; OpenAI points you to Codex for writing. * **Custom connectors (MCP)** \- documented for Business, Enterprise and Edu plans on the web. Don’t count on them on Plus or Pro. **Privacy:** business plans aren’t used for training by default. On personal plans, check the data controls in settings. #### Google Gemini **Simplest path** (works on the free tier): 1. Keep your brain in Google Drive. 2. Create a notebook in **Gemini Notebook** (formerly NotebookLM) and add your key `.md` notes, uploaded or picked from Google Drive. Drive sources re-sync every few minutes. 3. Ask questions there; edit in Obsidian. It reads but doesn’t write. The free tier allows 50 sources per notebook. **Other options:** * **Antigravity CLI** (`agy`) - Google’s command-line assistant, which replaced Gemini CLI for free and Google One users from June 2026\. It opens your folder, reads `AGENTS.md` and `GEMINI.md`, and can write. * **Gems** with Drive files - being replaced by “skills” through late 2026 into 2027. **Privacy:** on personal accounts with activity saving on, your chats and uploads can be used for training and seen by human reviewers. Workspace accounts aren’t, by default. #### Microsoft Copilot **Simplest path** (Microsoft 365 Personal, Family or a work plan with Copilot): 1. Keep your brain in OneDrive. 2. Create a **Copilot Notebook** and add your brain’s OneDrive folder as a reference. References stay current as files change. 3. **Test it first.** Ask three questions whose answers are only in your notes. When we checked (October 2026), Microsoft’s list of supported files for Notebooks covered Word, PDF, PowerPoint, Excel, Loop, text and OneNote files - **not** `.md`. If it can’t read your notes, Copilot isn’t the right assistant for this brain yet. **Other options:** * **Agent Builder** (with a Microsoft Copilot licence, formerly Microsoft 365 Copilot) - an agent grounded on a OneDrive folder link, up to 50 OneDrive files. Read-only. Same `.md` caveat. * **GitHub Copilot** \- reads a brain kept in a repository; in VS Code it reads `AGENTS.md` but not `CLAUDE.md`. **Privacy:** with Microsoft 365’s enterprise data protection, prompts and responses aren’t used to train the underlying models. #### Local models (on your own computer) **Simplest path** (a computer with 16 GB of memory or more): 1. Install **LM Studio** and download a model it recommends for your machine. 2. In Obsidian, install the **Copilot for Obsidian** plugin and add LM Studio (or Ollama, another local runner) as a provider in its settings. 3. Use its chat to ask questions about your notes. Searching by meaning across a large vault now needs a separate companion app from the same developer. Nothing leaves your computer. Expect answers to be weaker than the big cloud assistants - fine for a private vault, less so for heavy work. The plugin can create notes with your permission, and LM Studio can also run a filesystem connector so a local model can read and write a folder. ### Obsidian’s own bridges (optional) Obsidian has no built-in AI (as of October 2026). If your assistant opens the folder directly, you don’t need a bridge. Two exist if you want them: * The **Local REST API** community plugin lets an assistant work through a running Obsidian - including a built-in connector endpoint - useful if you want it to use Obsidian’s search or edit by heading. * Obsidian’s own **command-line tool** (from February 2026) can read, search, create and count, and can return a Bases view’s results. ### Notion If your notes live in Notion, its hosted connector lets Claude, ChatGPT and others read and update pages. But Notion isn’t a folder of files: your brain lives inside Notion, which is the lock-in this guide tries to avoid. See [page 10](#page-10). ### At a glance | Assistant | Reaches the folder by | Reads / writes | Shared with a team via | Cost | | -------------------- | --------------------------- | ---------------------------- | ---------------------------------- | ------------------------------ | | Claude desktop | Opening it (trusted folder) | Both, with approval | The shared folder or repo | Pro and above | | Claude Code | Opening it | Both | The shared folder or repo | Pro and above | | ChatGPT Work / Codex | Opening it | Both | The shared folder; shared projects | Paid plans; Codex on all plans | | ChatGPT Projects | Uploads, Drive links | Reads | Shared projects (all plans) | All plans | | Antigravity CLI | Opening it | Both | The shared folder or repo | Free tier available | | Gemini Notebook | Drive, auto-sync | Reads | Notebook sharing | Free (50 sources) | | Copilot Notebooks | OneDrive folder | Reads (.md unconfirmed) | Notebook sharing | Microsoft 365 plans | | Local model | Index or connector | Reads (writes via connector) | \- | Free; needs a capable computer | ### Prompts for this step **First conversation with a connected brain** ``` Read AGENTS.md and home.md. Then tell me, in a short list: what this brain is for, how it's laid out, which note types it uses, and anything in the rules you'd find ambiguous. Don't change anything. ``` **Ask with citations** ``` [Your question.] Answer only from the notes in this folder, checking them rather than relying on memory. After each fact, give the note it came from. If the notes don't answer it, say so and tell me which note would need to exist. ``` ### Sources (checked October 2026 - re-check before relying on them) * Claude: Cowork - · chat and Cowork as one app - · Claude Code desktop - · Projects - · data use - * OpenAI: ChatGPT Work and Codex - · Projects - · custom MCP - · AGENTS.md in Codex - * Google: Antigravity CLI migration - · Gemini Notebook sources - · Gemini privacy - * Microsoft: Copilot Notebooks references - see the [references page](#references) · Agent Builder knowledge - · GitHub Copilot instructions - * Local: LM Studio - · Copilot for Obsidian - * Obsidian: Local REST API - · CLI - * Notion connector - [contents ↑](#contents) [10 Windows →](#page-10) --- § 10 Windows seeing and editing your brain ## Windows: seeing and editing your brain **In two lines:** your brain is the folder of files; a window is how you look at it. Obsidian is the window we recommend - free, fast, and built around exactly this kind of folder - but the files work in anything, which is the point. ### What a window needs to do * **Edit** notes comfortably, including the properties at the top. * **Follow links** \- click `[[main-contact]]` and land on their note. * **Show what links here** \- every note that points at the one you’re reading. * **Query** \- tables of notes by type, status or relationship. * **Leave the files alone** \- no hidden database you’d lose by switching. ### Obsidian (recommended) Obsidian is a free desktop and mobile app that opens a folder of markdown files and treats it as a linked set of notes. It doesn’t change your files’ format or lock them away. **What you’ll use:** * **Properties panel** \- the fields at the top of each note shown as a neat form, with autocomplete for property names so you don’t create `org` when you meant `works_at`. * **Backlinks** \- everything that links to the current note, including links held in properties. * **Bases** \- built-in tables, lists and cards over your notes’ properties. This is where named relationships pay off: a table on the client’s note listing everyone whose `works_at` is the client keeps itself up to date ([page 4](#page-4)). * **Graph view and local graph** \- a picture of how notes connect. The full graph gets busy fast; the **local graph** on one note is more useful, and good for spotting notes nothing links to. Every line looks the same, so the graph shows _that_ things connect, not _how_. * **Templates** \- one blank note per type. * **Command-line tool** (from 2026) - lets an assistant search, count and query views through Obsidian. **Set up on day one** (Settings): * Default location for new notes → `inbox/`. * Attachments folder → `sources/attachments/`. * Daily notes folder → `inbox/daily/` (if you use them). * Links → use `[[wikilinks]]` and update links automatically when a file is renamed. **Plugins: few, and optional.** Obsidian’s community plugins are tempting. Most brains need none. Ones worth knowing about: | Plugin | What for | Note | | ----------------------------- | ------------------------------------------------------ | ----------------------------------- | | Obsidian Git | Syncing a brain kept in a GitHub repository | Only if you chose GitHub on day one | | Base Graph / Graph Link Types | Colouring or labelling graph lines by relationship | Young (2026); nice to have | | Copilot for Obsidian | Chatting with your notes, including with a local model | See [page 9](#page-9) | | Dataview | Older query plugin, before Bases | Prefer Bases for new brains | > **Seen in practice.** One vault had query blocks written for a plugin that had never been installed - so they showed as raw code. Another found empty notes and canvases piling up at the top level because default settings hadn’t been changed. Set locations up front, and only write for plugins you actually run. **Obsidian Sync and Publish** are optional paid services. If you use Sync, don’t also run another sync service on the same folder - Obsidian itself warns against it. Publish (for a public website of your notes) reportedly doesn’t show links held in properties in its graph. **Obsidian is a window, not an engine.** It makes your brain pleasant to read, edit and see. It doesn’t make your assistant’s answers better - the method does. ### Notion Many people already live in Notion, and its AI and connectors are good. But Notion isn’t a folder of files: pages live in Notion’s database, and exporting gives you files that lose some of their structure. That’s the lock-in this guide is designed to avoid. If you’re committed to Notion, you have two honest options: * **Notion as the brain.** Apply the method - questions first, one page per thing, decisions with what they replaced, a monthly test - inside Notion, and accept that your structure lives there. Its hosted connector lets Claude, ChatGPT and others read and update pages. * **Files as the brain, Notion for some views.** Keep the folder as the source of truth, and pull specific pages into it when needed. One practitioner syncs Notion pages into their folder only after confirming each one - workable, but it’s a second system to keep in step. Don’t try to keep both fully in sync. Two sources of truth is no source of truth. ### Logseq Logseq is an outliner - everything is a bullet - that has worked on folders of markdown files with `key:: value` properties. Its newer “database” version (in public beta during 2026) stores your notes in a database instead of plain files. If you use Logseq, stay on the file-based version for a brain built this way. ### VS Code and other editors A code editor such as VS Code opens the folder and edits markdown well, and the **Foam** extension adds wikilinks and backlinks. Good if you’re already comfortable there, and it’s where command-line assistants live. Avoid Dendron - its developers have stopped active work on it. ### A plain file manager Finder, File Explorer, or the Files app on a phone will open every note in your brain. You lose links, properties and views - but nothing is lost from the brain itself. That’s the test of a good setup: if every app disappeared tomorrow, you’d still have your notes. ### At a glance | Window | Files stay plain? | Properties | Tables / queries | Graph | Cost | | --------------------- | --------------------- | ---------------- | ---------------- | ------------------------ | --------------------------- | | **Obsidian** | Yes | Yes, with a form | Bases (built in) | Yes; labels need plugins | Free; Sync and Publish paid | | Notion | No - its own database | Yes | Databases | No | Free tier; paid plans | | Logseq (file version) | Yes | key:: value | Queries | Yes | Free | | VS Code + Foam | Yes | As text | Limited | Yes | Free | | File manager | Yes | As text | No | No | Free | **Window chooser** stays in your browser: nothing you enter is stored or sent ### Which window? Do you already use Notion heavily? yes no Do you want to see a graph of how your notes connect? yes not really Will you use it on a phone? yes no ### Sources (checked October 2026) * Obsidian help: Properties - · Bases - · Graph view - · Sync - · CLI - * Obsidian Git - · Base Graph - · Graph Link Types - * Notion connector - * Dendron (maintenance only) - * Steve Phelps, syncing Notion into a Claude Code brain - [contents ↑](#contents) [11 Automations →](#page-11) --- § 11 Automations on your laptop and in the cloud ## Automations: on your laptop and in the cloud **In two lines:** a few small jobs - a morning brief, filing new meeting notes, a weekly tidy-up report - keep a brain alive without you remembering to do them. You can run them on your laptop, or in the cloud so they run with the lid shut; which one you can use depends on a decision you make on day one: where your brain lives. Automate later rather than sooner. Run each job by hand for a week or two first, until you know what good output looks like. Then schedule it. ### First, the day-one decision: where does your brain live? A job running in the cloud **cannot see a folder on your laptop**. It can only reach files kept somewhere online that it has been given access to - a GitHub repository, or a Google Drive, OneDrive or SharePoint folder through a connector. So before you set up a single automation, decide where the brain lives and how it syncs. Changing your mind later means moving everything. There are three sensible answers: | Where it lives | Good for | Automations | Watch out for | | ---------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | **A synced folder** \- OneDrive, Google Drive, iCloud or Dropbox | Most people. Nothing new to learn; works across your devices | On your laptop: anything. In the cloud: through a Drive or OneDrive connector, usually limited to **creating new files** | Two people editing the same note at once leaves “conflicted copy” files | | **A git repository** on GitHub (private) | People happy to learn a little git, and small teams who want a full history of every change | On your laptop: anything. In the cloud: full read and write - the cloud job takes a fresh copy, works, and sends its changes back | Keep the laptop copy **outside** any synced folder | | **Both** | Rarely worth it | \- | See the warning below | > **Warning. Don’t put a git repository inside a OneDrive, Google Drive or iCloud folder.** The two sync systems fight over the same files. People widely report damaged repositories - stray system files inside git’s own folder, broken history, duplicate “conflicted” copies. Obsidian itself advises against running two sync services on one vault. Pick one to be in charge. If you need git, keep the repository in a plain folder (for example `Documents/brain`) and let GitHub be the sync. > **Seen in practice.** A team brain was set up as a git repository on a shared drive, because the shared drive was where everyone already kept their documents. One day the drive’s sync was caught having damaged git’s own files: pieces of the history vanished, and duplicate “(1)” copies appeared inside git’s folder. The fix was to move git’s data to a plain local folder on each computer, leave a one-line pointer to it in the shared drive, and add a daily check that fails on any computer still keeping it on the drive. It has run cleanly since. It works, but it is a repair - deciding the arrangement on day one is far cheaper. **Chooser** stays in your browser: nothing you enter is stored or sent ### Where should your brain live? 1\. Is your laptop usually off or asleep overnight and at weekends? yes no 2\. Does anyone else need to read or write the brain? just me one or two others more 3\. Which does your organisation already use? Microsoft 365 Google Workspace neither 4\. Would you be willing to learn three git commands - or have your assistant run them for you? yes no not sure ### What to automate - and what never to Good first automations all **create a new file** and **leave your notes alone**: | Job | What it does | How often | | ---------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- | --------------- | | **Morning brief** | Reads today’s calendar, open actions and recent notes; writes briefs/2026-10-15.md | Weekdays | | **New meeting notes** | Takes new transcripts or summaries from your note-taker; files each as a source and drafts the decisions and actions into the inbox for you to accept | Daily | | **Snapshot** | Copies today’s numbers or task list from the system that holds them (CRM, task tool) into a dated file marked as machine-made | Daily or weekly | | **Tidy-up report** | Lists orphan notes, notes with no summary, duplicates and anything not updated in six months - as a report, not as changes | Weekly | | **Self-test** | Asks your twenty test questions and records which it got right (see [page 12](#page-12)) | Monthly | | **“Gone quiet” alarm** | Warns you if nothing new has been filed for a week | Daily | Never automate: * **Editing notes a person wrote.** A job may suggest a change; a person makes it. * **Deciding what’s true.** A job may draft a decision; nothing becomes “what we believe” until someone accepts it. * **Deleting anything.** > **Seen in practice.** A personal brain was filled by a one-off import from years of email - and then nothing. Its sync log stopped eleven weeks before anyone looked, and nothing had flagged it. A daily “gone quiet” check is the cheapest automation you’ll ever set up. ### The same job, two ways Here is the morning brief, side by side. | | On your laptop | In the cloud | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------- | | **Runs when** | The laptop is on and awake (most tools catch up once when it wakes) | On schedule, laptop or not | | **Reads your brain from** | The folder on your disk | A GitHub copy, or Drive / OneDrive through a connector | | **Writes the brief to** | The folder on your disk | A new file in GitHub (then synced down) or in Drive / OneDrive | | **Reaches your calendar and email** | Through the assistant’s connectors | Through the assistant’s connectors | | **Set up with** | Claude desktop scheduled task · ChatGPT desktop app scheduled task · Windows Task Scheduler or macOS launchd | Claude cloud scheduled task · GitHub Actions · Power Automate · n8n or Make | | **Costs** | Your assistant subscription | Your assistant subscription; some services add their own charges | | **Best for** | Laptop-only setups; anything touching files that only exist locally | Jobs that must run at 7am whether you’re up or not | ### How-to: on your laptop #### Claude desktop app - scheduled task The simplest local option if you use Claude. It runs on your machine, with your folder. 1. Open the Claude desktop app and go to the **Code** tab. Choose **Local** and select your brain’s folder. 2. Ask: _“Create a scheduled task that runs every weekday at 7am and writes my morning brief”_ \- then paste the brief prompt from the end of this page. 3. Check the permission mode it will run in. If it is set to ask before acting, an unattended run will sit waiting for an answer. 4. Turn on keep-awake in the app’s settings if you want early-morning runs to happen. It only runs while the app is open and the computer is awake. If it misses a run, it does one catch-up run when the computer wakes (for the most recent miss in the last seven days). #### ChatGPT desktop app - scheduled task (formerly Codex automations) Scheduled tasks tied to a local project run on your machine: the computer must be on, the ChatGPT desktop app running, and the folder on disk. Ask it to schedule the job, and check which sandbox setting it will run with, since tasks use your default - read-only, allowed to write in the folder, or full access. Choose “write in the folder”; OpenAI itself flags full access as risky. #### Windows Task Scheduler or macOS launchd - for the comfortable Your computer’s own scheduler can start an assistant from the command line on a timetable. You don’t need to write this yourself - ask your assistant: **Set up a local scheduled job** ``` Set up a Windows Task Scheduler task (or macOS launchd job) that runs every weekday at 7am, opens my brain folder at [path], and runs Claude Code in headless mode with the prompt in prompts/morning-brief.md. It must not be allowed to ask for permission mid-run, must have a spending cap, and must append a line to log.md saying what it wrote. If the computer was asleep, it should run when it wakes. Show me everything before you create it. ``` Worth knowing: on Windows, the task can be set to wake the computer from sleep, and to run as soon as possible after a missed time; on a Mac, a job missed during sleep runs on wake, but one missed while the Mac was off waits for the next time. ### How-to: in the cloud #### Claude scheduled tasks in the cloud (formerly routines) A cloud scheduled task is a saved prompt plus your brain’s GitHub repository, run on Anthropic’s servers on a schedule - “when your laptop is closed”. 1. Your brain must be in a GitHub repository (see the day-one decision). 2. Create the task at claude.ai/code/routines (the address still carries the old name), from the desktop app’s **Code** tab (**Scheduled**, then **New task**), or with `/schedule` in Claude Code. Give it the repository, the prompt and a schedule - hourly at most, daily or weekly are typical. 3. **Remove every connector it doesn’t need.** A cloud task can use all your connected apps - including sending and editing - without asking. 4. Decide where it pushes. By default it writes to a separate branch starting `claude/`; you then accept its changes, or a small rule merges them for you. Each run starts from a fresh copy of the repository, so nothing it does depends on your laptop. Runs use your subscription allowance. If the connection to GitHub lapses, runs are skipped and, after three days, the task switches itself off. As of October 2026 cloud scheduled tasks are a research preview - expect changes. #### Claude Cowork scheduled tasks Cowork can now run scheduled tasks remotely, even with your computer asleep - unless the task needs local files, in which case it runs on your computer. This changed days before this page was written; check the current behaviour before relying on it. #### GitHub Actions GitHub can run a job on a timetable (every five minutes at the most) inside your repository, and Anthropic and OpenAI both publish ready-made steps that run their assistant inside it. It’s more set-up than a cloud scheduled task, but it’s the most transparent: every run is logged, and you can make a run **fail** when it didn’t produce what it should. Ask your assistant to write it: **Write a GitHub Actions workflow** ``` Write a GitHub Actions workflow for this repository that runs every weekday at 06:30 UK time, runs the prompt in prompts/morning-brief.md with the Claude Code action, commits the new brief to briefs/, and FAILS if no new file was created. Use a repository secret for the key - never put a key in the file. Add a timeout and a turn limit. ``` GitHub may delay scheduled jobs at busy times, occasionally drops them, and switches schedules off in public repositories after sixty days without activity. Keep the brain’s repository private. #### Microsoft 365: Power Automate, and Copilot’s scheduled prompts * **Power Automate** watches a OneDrive or SharePoint folder (“when a file is created”) and can run steps when something new lands - useful for filing new meeting notes. It can miss changes when many arrive at once. * **Copilot scheduled prompts** (up to ten, with a Microsoft Copilot licence, from the Work IQ tab) are good for a read-only brief delivered to chat or email. They don’t write files. * When we checked (October 2026), Microsoft’s lists of supported files didn’t include `.md` \- **test that Copilot reads your notes before relying on it**. #### Google Workspace: Gemini scheduled actions, and Drive connectors * **Gemini scheduled actions** (up to ten) deliver a brief as a notification or chat. They don’t write files. * To write into a Drive folder from the cloud, use an assistant’s Drive connector (Claude’s can create new files) or an automation service such as n8n or Make. #### ChatGPT Tasks Scheduled Tasks (between three and fifteen active, depending on plan) are good for reminders and read-only briefs. They can now act through connected apps such as GitHub, but anything that changes data may wait for your approval. Test one before trusting it to file into your brain. #### n8n, Make and Zapier General automation services with schedules and AI steps. They can reach Drive, OneDrive and GitHub. Useful for “when X arrives, do Y” jobs, at the cost of another account and another bill. ### Four starting setups | You are… | Start with | | ----------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Laptop only** \- one person, laptop often off | Claude desktop scheduled tasks (or ChatGPT desktop app scheduled tasks) on your synced folder. Accept that jobs run when the laptop wakes. If you need jobs to run with the lid shut, that’s the moment to move to GitHub. | | **Happy with GitHub** | A private repository kept outside any synced folder; Obsidian Git to pull and push automatically; Claude cloud scheduled tasks for scheduled jobs, writing new files; a GitHub Action that fails when nothing landed. | | **A Microsoft 365 shop** | The brain in OneDrive or SharePoint. Power Automate for “new file” jobs; Copilot scheduled prompts for read-only briefs; Claude’s Microsoft 365 connector where your admin allows it to write. Local jobs with Task Scheduler. Never git inside OneDrive. | | **A Google Workspace shop** | The brain in a Drive folder. A cloud assistant’s Drive connector to create new files; Gemini scheduled actions for read-only briefs; n8n or Make for “new file” jobs. Local jobs on the Drive for desktop folder. | ### Seven rules for automations you can trust 1. **“It ran” is not “it worked.”** A green tick usually means only that nothing crashed. Anthropic’s own documentation for scheduled tasks says so: read what the run actually did. 2. **Every run writes a log line with counts** \- “filed 3 meeting notes, wrote 1 brief” - or says plainly that it did nothing. 3. **A separate check confirms the output exists**, and fails loudly when it doesn’t. 4. **Make every check fail once on purpose.** A check that has never failed hasn’t been tested. 5. **Jobs create new files; they never edit what a person wrote.** Mark machine-made files (`source: morning-brief`) and never hand-edit them - the next run will overwrite your changes. 6. **Give each job only what it needs.** Remove unused connectors; cap spending and the number of steps; keep keys in the service’s secrets store, never in a file. 7. **One writer per file, and pull before you write.** Two writers on one file is how conflicts start. > **Seen in practice.** In one brain, a daily import ran every morning for a week, looked healthy and filed nothing. In another, a privacy scan reported “all clear” for days because its pattern was broken. Both were caught by checking what landed rather than whether the job ran - which is now rules 1 to 4 above. ### Prompts for this page **The morning brief** \- save as `prompts/morning-brief.md` and use it locally or in the cloud: ``` Write today's brief to briefs/YYYY-MM-DD.md (create a new file; never edit an existing one). Include: today's meetings with a line on each person from their note; actions due today or overdue from projects/; decisions waiting on me; anything filed in the last 24 hours. Cite the note for every item. If a source is unavailable, say so in the brief rather than leaving it out. Then add one line to log.md: the date, the file written, and counts of meetings, actions and new items. ``` **Turn a local job into a cloud one** ``` I run [job] as a scheduled task on my laptop. My brain is now in the GitHub repository [name]. Help me set the same job up as a cloud scheduled task: list the connectors it needs and the ones to remove, where it should write, how its changes come back to my laptop, and the check that will tell me when it didn't produce anything. ``` **The “gone quiet” alarm** ``` Check when the newest file in inbox/, meetings/ and briefs/ was created. If nothing is newer than 7 days, write alerts/YYYY-MM-DD-gone-quiet.md naming which folders are quiet and since when. If everything is fresh, write nothing except a line in log.md. ``` ### Sources (checked October 2026 - re-check before relying on them) * Claude scheduled tasks (formerly routines) - * Claude desktop scheduled tasks - * Claude Code headless mode - * Claude Code GitHub Actions - * Claude Cowork scheduled tasks - * ChatGPT desktop app scheduled tasks - * ChatGPT Tasks - * Gemini scheduled actions - * Microsoft 365 Copilot scheduled prompts - * Power Automate OneDrive connector - * GitHub Actions schedules - * n8n Schedule Trigger - * Obsidian, syncing notes (one sync service per vault) - * Obsidian Git plugin - * Git repositories damaged inside OneDrive - * Windows Task Scheduler settings - * macOS scheduled jobs (launchd) - [contents ↑](#contents) [12 Keeping it true →](#page-12) --- § 12 Keeping it true ## Keeping it true **In two lines:** a brain is right on the day you build it and drifts from then on. Fifteen minutes a week, an hour a month and a short check each quarter keep it honest - and a monthly test tells you whether it’s working. ### Why brains rot * **Things change and the notes don’t.** The client changed contacts; the decision was reversed; the project finished. An out-of-date note doesn’t make the assistant hesitate - it makes it confidently wrong. * **Two versions sit side by side.** Research on AI answers finds that old information drags results down even when the current version is also present. * **It grows without limit.** Assistants are happy to keep writing. Without pruning, the useful notes get buried. * **It goes quiet and nobody notices.** An import stops; an automation fails; the inbox fills and nobody empties it. ### Every week: fifteen minutes 1. **Empty the inbox.** Accept, fix or bin each draft. If there are more than you can review in ten minutes, you’re taking in too much. 2. **Mark what’s changed.** Anything replaced this week gets a new note with `supersedes`, and the old one is marked `superseded` ([page 6](#page-6)). 3. **Read the tidy-up report** (if you’ve automated one - [page 11](#page-11)): new notes nothing links to, notes without a summary, likely duplicates. 4. **Glance at the log.** Did every automation write what it should have? ### Every month: the test Take your test questions from [page 3](#page-3) and ask them in a fresh conversation. For each question, record two things separately: * **Did it find the right note?** Compare with the “should come from” column. * **Was the answer right?** Compare with the expected answer. Then read the failures - every one. They fall into two kinds: | Failure | What it usually means | Fix | | ---------------------------- | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | | **Wrong note found** | The right note is missing, badly titled, has no summary, or is buried under near-duplicates | Fix the note first: title, summary, properties; merge duplicates | | **Right note, wrong answer** | The note is out of date, ambiguous, or contradicts another note | Update or supersede the note; clarify the wording | Fix the “wrong note” failures first - they’re usually the cause of the others. **A perfect score means your test is too easy.** Add a harder question each month - one that needs two notes, one that should be refused, one about something that changed recently. Update the expected answers when the truth changes. A test with stale answers is as misleading as a stale note. ### Every quarter: check the shape * **Vocabulary against reality.** Ask the assistant to list every property in use and how often ([page 4](#page-4) has the prompt). Look for near-duplicates, typos, and fields whose values have wandered. * **Prune.** Archive finished projects. Retire types and relationships nobody used. Split notes that have grown too long. * **Re-read the rules file.** Is it still short? Does anything in it contradict another file? > **Seen in practice.** In one large vault, a “needs review” flag had been switched on by default and was set on 74% of notes - at which point it told nobody anything. A flag needs a way to be cleared, or it shouldn’t be set by default. ### Signs it’s rotting * The assistant suggests something you decided against months ago. * It quotes a figure you know is out of date. * Two notes about the same person or company. * The inbox has drafts more than two weeks old. * Nothing new has been filed for a week, and you didn’t notice. * The rules file has doubled in length. * You’ve stopped asking it things because you don’t trust the answers. > **Seen in practice.** A personal brain was filled by an import from years of email, almost all of it in a single month. Then the import stopped. About eleven weeks later, nothing had flagged it - no alarm, no report. A “last filed” date on the home page and a daily “gone quiet” check would have flagged it within days. ### Trust the checks only after you’ve seen them fail Any check you rely on - the monthly test, the tidy-up report, the “gone quiet” alarm - should be made to fail once, on purpose, before you trust its “all clear”. * Ask the test a question you know the brain gets wrong. Does it show as a failure? * Leave the inbox untouched for a week. Does the alarm fire? > **Seen in practice.** A privacy check in one brain reported “all clear” for days. Its search pattern was broken, so it couldn’t have found anything. Nobody had ever seen it fail. **Brain health check** stays in your browser: nothing you enter is stored or sent ### How is your brain doing? Twelve questions. Answer "no automations yet" where it applies. Intake Is anything in your inbox more than two weeks old? yes no Has anything new been filed in the last week? yes no Could you review this week's new drafts in ten minutes? yes no Accuracy Did you run your test questions in the last month? yes no Has the assistant lately suggested something you decided against, or quoted a figure you know is out of date? yes no Are the expected answers in your test file still true today? yes no Shape Is there more than one note about the same person or company? yes no Is your rules file still short, with nothing in it that contradicts another file? yes no Have you compared the properties in use with your vocabulary this quarter? yes no Automations Did every automation write its expected line in the log this week? yes no no automations yet Has a check you rely on ever failed - on purpose or not? yes no no automations yet Do your automations only create new files, never editing a note a person wrote? yes no no automations yet show the result ### Prompts for this step **Weekly review** ``` Help me with my weekly review. List: everything in inbox/ grouped as ready to accept, needs my judgement, or probably bin; notes changed this week that might replace an older note (suggest supersedes links); notes created this week that nothing links to; and any automation that didn't write its expected line in log.md. Change nothing. ``` **Monthly test** ``` Run the questions in how-we-work/test-questions.md. Treat each as a fresh question: check the notes, don't rely on memory. For each, record: the note you used, whether it matches the "should come from" column, your answer, and whether it matches the expected answer. Write the results to how-we-work/test-results/YYYY-MM.md as a table, then list the failures, split into "wrong note found" and "right note, wrong answer". Don't fix anything. ``` **Tidy-up report** ``` Write a tidy-up report to briefs/tidy-up-YYYY-MM-DD.md: notes with nothing linking to them, notes missing a summary or type, likely duplicates (similar titles or shared aliases), notes not updated in six months that are still marked active, and notes over 3,000 words. Report only; change nothing. ``` ### Sources * HoH benchmark on outdated information in AI answers (2025) - see the [references page](#references). * Hamel Husain on reading failures and separating retrieval from answers - see the [references page](#references). * Anthropic on starting with twenty to fifty real test tasks (January 2026) - see the [references page](#references). [contents ↑](#contents) [13 Prompt library →](#page-13) --- § 13 Prompt library ## Prompt library **In two lines:** every prompt in this guide, in one place, grouped by what you’re doing. They work with any assistant that can read your folder - paste, fill in the square brackets, and read what it proposes before you accept anything. ### How the prompts are written They follow the same few habits, and you’ll get better results if your own prompts do too: * **Say where to write.** Drafts go to `inbox/`, automation output to `briefs/` or `snapshots/`. Never “update my notes”. * **Say what not to touch.** “Change nothing outside inbox/.” “Don’t change any existing note.” * **Ask for sources.** “Cite the note for every item.” * **Ask it to check, not remember.** “Check the notes rather than relying on memory.” * **Ask for a report before an action.** “Show me the files before you create them.” * **Make it say when it can’t.** “If the notes don’t answer it, say so.” **Prompt library** stays in your browser: nothing you enter is stored or sent ### Every prompt, in one place all plan design build fill connect use automate keep true any assistant mine can only read (a project or notebook) 26 prompts plan · [page 3](#page-3) #### Find my questions Pulls recurring questions out of your existing notes or meetings Read . List the questions that came up more than once, or that took real effort to answer - things people asked me, things I had to look up, decisions someone may later ask "why" about. Group them as look-up, relationship, why-and-when, status, and count-or-list. Don't answer them. copy prompt plan · [page 3](#page-3) · needs an assistant that opens your folder #### Turn them into a test file Builds \`test-questions.md\` with expected answers and source notes Here are my twenty questions: . Create how-we-work/test-questions.md as a table with columns: number, question, kind (look-up, relationship, why and when, status, or count and list), expected answer (leave blank where I haven't given one), the date the answer was true, and the note it should come from (suggest a filename using our folders if the note doesn't exist yet). Add two questions the brain should refuse to answer because the material is on my "never goes in" list. copy prompt design · [page 4](#page-4) · needs an assistant that opens your folder #### Derive your ontology from your questions Proposes the smallest set of types and relationships your questions need Here are the questions I want my brain to answer: . Propose the smallest set of note types and named relationships that would let you answer all of them. Start from this starter set and only add to it if a question needs it: types person, organisation, project, meeting, decision, topic, source, note; relationships works_at, attendees, part_of, owner, supersedes, from. For each type and relationship, say which of my questions it serves. List anything in the starter set that none of my questions needs. Don't create any files yet. copy prompt design · [page 4](#page-4) · needs an assistant that opens your folder #### Write the vocabulary note and templates Creates the vocabulary, a template and a view per type Using the types and relationships we agreed, create: 1. how-we-work/vocabulary.md - one short entry per type and relationship: what it means, the question it serves, its template and its view. 2. A template in templates/ for each type, with its properties at the top. Links in properties must be quoted, and plural relationships must be lists. 3. A Bases view for each type. Don't add inverse relationships. Show me the files before saving them. copy prompt build · [page 5](#page-5) · needs an assistant that opens your folder #### Scaffold the brain Creates the starter folders, rules file, home page and log Create a new brain in this folder. Make these folders: inbox, sources, people, organisations, projects, meetings, decisions, topics, how-we-work, templates, views, briefs, snapshots, archive. Create AGENTS.md from the rules I paste below, a CLAUDE.md containing only the line @AGENTS.md, a short home.md linking to each folder and to how-we-work/, and an empty log.md. Don't create any notes yet. Show me the list of files before you create them. copy prompt build · [page 4](#page-4) · needs an assistant that opens your folder #### Add properties to notes you already have Proposes types and relationships for existing notes, changing nothing Go through the notes in . For each one, propose the type and any named relationships it should have, using only our vocabulary in how-we-work/vocabulary.md. Don't change any note. Write your proposals as a table in inbox/ontology-proposals.md with the note, the proposed properties, and how sure you are. copy prompt fill · [page 7](#page-7) · needs an assistant that opens your folder #### Ingest one source Drafts new notes and changes from a single source into the inbox I've added sources/. Read it and draft into inbox/: new notes for any people, organisations, projects or decisions it introduces that we don't already have, and suggested changes to existing notes as separate drafts. Use templates/ and our vocabulary. Every fact must cite the source. Skip anything on how-we-work/never-goes-in.md and tell me you skipped it. Change nothing outside inbox/. copy prompt fill · [page 7](#page-7) · needs an assistant that opens your folder #### Distil a meeting Drafts the meeting note, decisions and actions from a transcript The transcript of is in sources/. Draft into inbox/: a meeting note (date, attendees, part_of, a five-line summary), a decision note for each decision, and a list of actions with owners and dates. Keep work content only - leave out personal asides entirely, and anything on how-we-work/never-goes-in.md. Cite the transcript for every item. copy prompt fill · [page 6](#page-6) · needs an assistant that opens your folder #### Draft a decision note from a meeting Writes full decision notes, with what they replace Read meetings/. For each decision made in it, draft a decision note in inbox/ using templates/decision.md: title, a two-line summary with the reason, status proposed, date, owner, part_of, from (the meeting), and sections for context, decision, alternatives rejected, consequences and still open. If it replaces an earlier decision, find that note and add supersedes. Quote nothing you can't find in the meeting note. Don't change any existing note. copy prompt fill · [page 4](#page-4) · needs an assistant that opens your folder #### Propose links Suggests missing links and relationships; lists "wanted notes" Read . Suggest links that are missing: plain ] where the text mentions a person, organisation, project or decision we have a note for, and named relationships from how-we-work/vocabulary.md where a property is clearly implied. Match names against aliases too. Never invent a target: if no note exists, list it as a "wanted note" instead. Write your suggestions to inbox/link-proposals.md and change nothing else. copy prompt connect · [page 8](#page-8) · needs an assistant that opens your folder #### Write a pointer note Records where live data lives, with no figures Create how-we-work/where--lives.md as a pointer note: which system holds , which view or report to use, who owns it, and an instruction to ask the system rather than this note. Include no figures. Then add one line to AGENTS.md telling the assistant to read this note before answering questions about . copy prompt connect · [page 8](#page-8) · needs an assistant that opens your folder #### Set up a snapshot Writes the prompt for a dated, machine-made snapshot job Write a prompt for a weekly job that reads and writes a new file snapshots//YYYY-MM-DD.md with: . It must never edit an existing file, must mark the new file with source: -snapshot, and must add a line to log.md with the date and the number of rows. Save the prompt as prompts/-snapshot.md. copy prompt connect · [page 9](#page-9) #### First conversation with a connected brain Checks the assistant has understood your layout and rules Read AGENTS.md and home.md. Then tell me, in a short list: what this brain is for, how it's laid out, which note types it uses, and anything in the rules you'd find ambiguous. Don't change anything. copy prompt use · [page 9](#page-9) #### Ask with citations Answers only from the notes, citing each fact Answer only from the notes in this folder, checking them rather than relying on memory. After each fact, give the note it came from. If the notes don't answer it, say so and tell me which note would need to exist. copy prompt use · [page 8](#page-8) #### Answer a count properly Answers "how many" from a table, listing what it counted How many ? Answer from , not by reading notes. Say which table you used and list the items you counted. copy prompt automate · [page 11](#page-11) · needs an assistant that opens your folder #### The morning brief Writes a dated brief and a log line Write today's brief to briefs/YYYY-MM-DD.md (create a new file; never edit an existing one). Include: today's meetings with a line on each person from their note; actions due today or overdue from projects/; decisions waiting on me; anything filed in the last 24 hours. Cite the note for every item. If a source is unavailable, say so in the brief rather than leaving it out. Then add one line to log.md: the date, the file written, and counts of meetings, actions and new items. copy prompt automate · [page 11](#page-11) · needs an assistant that opens your folder #### The "gone quiet" alarm Warns when nothing new has been filed for a week Check when the newest file in inbox/, meetings/ and briefs/ was created. If nothing is newer than 7 days, write alerts/YYYY-MM-DD-gone-quiet.md naming which folders are quiet and since when. If everything is fresh, write nothing except a line in log.md. copy prompt automate · [page 11](#page-11) · needs an assistant that opens your folder #### Set up a local scheduled job Has the assistant create a Task Scheduler or launchd job, with limits Set up a Windows Task Scheduler task (or macOS launchd job) that runs every weekday at 7am, opens my brain folder at , and runs Claude Code in headless mode with the prompt in prompts/morning-brief.md. It must not be allowed to ask for permission mid-run, must have a spending cap, and must append a line to log.md saying what it wrote. If the computer was asleep, it should run when it wakes. Show me everything before you create it. copy prompt automate · [page 11](#page-11) · needs an assistant that opens your folder #### Write a GitHub Actions workflow A scheduled cloud job that fails when nothing landed Write a GitHub Actions workflow for this repository that runs every weekday at 06:30 UK time, runs the prompt in prompts/morning-brief.md with the Claude Code action, commits the new brief to briefs/, and FAILS if no new file was created. Use a repository secret for the key - never put a key in the file. Add a timeout and a turn limit. copy prompt automate · [page 11](#page-11) · needs an assistant that opens your folder #### Turn a local job into a cloud one Moves a laptop job to a cloud routine, safely I run as a scheduled task on my laptop. My brain is now in the GitHub repository . Help me set the same job up as a cloud scheduled task: list the connectors it needs and the ones to remove, where it should write, how its changes come back to my laptop, and the check that will tell me when it didn't produce anything. copy prompt keep true · [page 7](#page-7) #### Review the inbox Sorts drafts into accept, judge, or bin List everything in inbox/ with a one-line description, what it would change, and anything that looks wrong or unsupported by its source. Group by: ready to accept, needs my judgement, probably bin. Don't move or change anything. copy prompt keep true · [page 12](#page-12) · needs an assistant that opens your folder #### Weekly review Inbox, likely supersessions, new orphans, missing log lines Help me with my weekly review. List: everything in inbox/ grouped as ready to accept, needs my judgement, or probably bin; notes changed this week that might replace an older note (suggest supersedes links); notes created this week that nothing links to; and any automation that didn't write its expected line in log.md. Change nothing. copy prompt keep true · [page 12](#page-12) · needs an assistant that opens your folder #### Monthly test Runs your test questions and separates the two kinds of failure Run the questions in how-we-work/test-questions.md. Treat each as a fresh question: check the notes, don't rely on memory. For each, record: the note you used, whether it matches the "should come from" column, your answer, and whether it matches the expected answer. Write the results to how-we-work/test-results/YYYY-MM.md as a table, then list the failures, split into "wrong note found" and "right note, wrong answer". Don't fix anything. copy prompt keep true · [page 12](#page-12) · needs an assistant that opens your folder #### Tidy-up report Orphans, missing summaries, duplicates, stale and over-long notes Write a tidy-up report to briefs/tidy-up-YYYY-MM-DD.md: notes with nothing linking to them, notes missing a summary or type, likely duplicates (similar titles or shared aliases), notes not updated in six months that are still marked active, and notes over 3,000 words. Report only; change nothing. copy prompt keep true · [page 6](#page-6) #### Check a note against the anatomy Lists what a single note is missing Check against our note anatomy: does it have a type, a title that says what it is, a two-line summary, a date, the relationships our vocabulary expects for its type, and sources for its facts? Is it one subject, and short enough? List what's missing or wrong. Don't change it. copy prompt keep true · [page 4](#page-4) #### Quarterly check Compares the properties in use with your vocabulary List every property used across the brain, how many notes use it, and any values that look like typos or near-duplicates. Compare it with how-we-work/vocabulary.md and tell me: properties in use but not in the vocabulary, vocabulary entries nobody uses, and fields whose values have drifted. Change nothing - just report. copy prompt ### Writing your own When a task recurs, save its prompt as a file in `prompts/` and refer to it by name - “run `prompts/morning-brief.md`”. It’s then one copy, versioned with your brain, usable by any assistant and by any automation. If you find yourself editing the same prompt in two places, you have two prompts; delete one. [contents ↑](#contents) [14 Use cases →](#page-14) --- § 14 Use cases ## Use cases **In two lines:** five worked examples of a personal brain - a solo consultant, a founder, a team of three, a personal life-admin brain, and a researcher or writer. Each shows the questions, the shape, the assistant, the automations and what tends to go wrong. The examples are composites; the lessons come from real builds. **Use cases** stays in your browser: nothing you enter is stored or sent ### Pick yours, and start from it the solo consultantthe founderthe team of threepersonal life adminthe researcher or writer ### 1\. The solo consultant _Someone running a one-person consultancy, with five or six clients at a time._ **Questions they ask most:** Who’s my contact at each client, and what do they care about? What did we agree at the last meeting? What did I propose to them, and at what price? Have I solved this problem for another client before? **Shape:** * Types: `person`, `organisation`, `project`, `meeting`, `decision`, `source`, `topic` (for reusable approaches). * Relationships: `works_at`, `attendees`, `part_of`, `supersedes`, `from`. * The most valuable notes: one per client engagement, decision notes on scope and price, and topic notes on approaches that worked - linked from every project that used them. **Assistant:** Claude or ChatGPT desktop with the folder open, on a synced folder. **Automations:** a morning brief from the calendar (laptop, scheduled task); meeting transcripts filed and distilled into the inbox. **What tends to go wrong:** proposals and contracts copied into notes in full (keep them as sources, distil the terms); old prices quoted back (decision notes with `supersedes`). > **What people report.** A solo operator with about 2,000 files keeps every transcript untouched and has the assistant maintain a smaller set of curated notes, with one fact per note in its memory folder so corrections are surgical. ### 2\. The founder _The founder of a company of eight, and the person everyone asks “why did we…?”_ **Questions:** Why did we choose this supplier? What did we tell investors last quarter? Who owns hiring for the next role? What have we already tried on pricing? **Shape:** * Types: `decision` at the centre; `person`, `organisation`, `project`, `meeting`, `topic`. * Relationships: `owner`, `supersedes`, `part_of`, `from`. * Decision notes always include **alternatives rejected** \- it stops the assistant cheerfully re-proposing what was ruled out. * Pointer notes for live data: the cap table, the accounts, the CRM. Never copied in. **Assistant:** Claude Code or Codex for building; whichever chat assistant the founder uses day to day for questions. **Automations:** a weekly snapshot of key figures (cloud, from the finance tool); a monthly self-test. **What tends to go wrong:** board and HR material creeping in (on the never-goes-in list, kept elsewhere); a rules file that grows into a company handbook. > **What people report.** A founder-operator’s lessons after a year: too many clever folders, letting the AI rewrite raw notes, and rules too long for the assistant to follow. What worked was keeping raw input separate from the AI’s synthesis and treating the rules file as the “operating system”. ### 3\. The team of three _A small studio - two partners and a producer - sharing one brain. Three is about the limit for a personal brain: if they hire a fourth person who’ll rely on it, it’s time to read [page 15](#page-15)._ **Questions:** What’s the status of each job? Who’s talking to which client? What’s our standard way of doing a kick-off? What did the client sign off, and when? **Shape:** * Types: `project`, `organisation`, `person`, `meeting`, `decision`, and `procedure` (how-we-work notes). * Relationships: `owner`, `attendees`, `part_of`, `works_at`, `supersedes`. * A clear owner per area who accepts drafts for it; one writer per file. **Day-one decision:** a private GitHub repository (with Obsidian Git on each laptop), or a shared drive folder - not both. **Assistant:** each person’s own. One `AGENTS.md` covers them all. **Automations:** each person captures their own meetings; a weekly cloud job writes a status digest from the task tool; a tidy-up report on Fridays. **What tends to go wrong:** a shared inbox nobody owns; two people editing the same note; “Obsidian doesn’t do team” - it doesn’t, so the sharing has to come from the folder or repository underneath. > **What people report.** We found no detailed first-hand account of a small team running a brain like this - only templates. The closest evidence is a two-person business brain: hand-written notes linked through a home page, git syncing automatically, a decisions log, and dated snapshots for figures. Its strain was a handful of notes that grew enormous. ### 4\. Personal life admin _Someone using a brain to run the household: insurance, the car, the boiler, school dates, warranties._ **Questions:** When does the car insurance renew, and who with? What’s the boiler’s model number and who serviced it last? Where’s the warranty for the fridge? What did the school say about the trip? **Shape:** * Types: `thing` (an appliance, a vehicle, a policy), `organisation` (suppliers, the school), `person`, `event`, `source` (scanned letters, receipts). * Relationships: `supplier`, `renews_on` (a date, not a link), `part_of` (the house, the car), `from`. * A CSV for anything you’ll count or list - policies and renewal dates. **Privacy first:** health records, finances and anything about the children’s wellbeing go in a **separate vault the assistant isn’t given**, or nowhere. Account numbers and passwords never go in - note where they’re kept instead. **Assistant:** a desktop assistant on the household folder; or a local model, so nothing leaves the computer. **Automations:** a monthly “renewing in the next 60 days” brief. > **What people report.** People who keep health notes and journals tend to give them their own vault the assistant can’t reach; some run a local model for that vault only. Others keep reference data - policy numbers, product serial numbers - specifically so an assistant can look it up. ### 5\. The researcher or writer _Someone writing a book, with years of reading notes._ **Questions:** Where did I read the argument about X? Which sources disagree with each other on Y? What have I already written about Z? **Shape:** * Types: `source` (every book, paper, article), `topic` (concepts and arguments), `person` (authors), `draft` (chapters). * Relationships: `from`, `part_of`, plus `supports` and `contradicts` between topics and sources - added only once a question needs them. * Raw highlights stay in `sources/`; topic notes say what the writer thinks, citing them. **Assistant:** any that opens the folder; plain word search works well for “where did I read…”. **Automations:** few. A monthly tidy-up report for orphaned reading notes. **What tends to go wrong:** importing everything ever highlighted, then never re-reading it - the collector’s trap. > **What people report.** A writer with a vault of about twelve million words found an assistant good at finding notes she only half-remembered and at bulk fixes, but still trusted Obsidian’s own search more for exact look-ups. A design engineer with over 6,000 notes, mostly unsorted, found that adding a simple folder structure made the assistant much better at finding things. ### Two shapes your brain might take Real brains tend to lean one of two ways. Knowing which yours is helps you decide where to put the effort. | | Relationship index | Operating manual | | -------------------- | --------------------------------------------------------- | ----------------------------------------------------- | | **Built for** | “Who do I know, and when did we last speak?” | “What’s current, and what’s correct?” | | **Notes** | Many, short, often generated | Fewer, longer, hand-written | | **Links** | Mostly named relationships in properties | Mostly plain links in the text, around a home page | | **Effort goes into** | Thresholds, aliases, the import | Supersession, review, keeping canonical notes current | | **Risk** | Thousands of unlinked notes; going stale after one import | A few notes growing enormous; rules files disagreeing | > **Seen in practice.** A personal brain of about 5,800 notes, built from years of email, was a relationship index: 95% of its links in named properties, a median note of under sixty words. A two-person business brain of about 160 notes was an operating manual: every link in the text, around twelve links per note, canonical documents with version and supersession fields. Same method; different weights. ### Sources (first-hand accounts) * Cyril Simonnet (solo operator, July 2026) - * Dan Okhlopkov (founder/operator) - * Irtiza Hafiz (separate private vault) - * XDA, a local model with filesystem access (July 2026) - * Eleanor Konik (writer, July 2025) - * Stefan Imhoff (design engineer, March 2026) - * Hacker News discussion on team brains - [contents ↑](#contents) [15 Tools, honestly →](#page-15) --- § 15 Tools, honestly and when you've outgrown it ## Tools, honestly - and when you've outgrown it **In two lines:** what we’d use today, what we’d be careful with, and the signs that your brain needs more than this guide offers. Everything here is as of **October 2026** \- this is the part of the guide that will date fastest. ### Files and windows * **A plain folder of markdown files** \- the one choice we’d defend most firmly. It outlives every app on this page. * **Obsidian** \- the best window for this kind of brain right now: free, fast, built around plain files, with properties, Bases and a graph. Use few plugins. ([Page 10](#page-10)) * **GitHub** \- if you’re willing to learn a little, it gives you full history and lets cloud jobs read and write your brain. Keep the working copy out of synced folders. * **OneDrive, Google Drive, iCloud, Dropbox** \- fine as the home for a simpler brain. Just don’t combine them with git. ### Assistants * **Assistants that open your folder** \- Claude (desktop app and Claude Code), ChatGPT’s Work mode and Codex, Google’s Antigravity CLI - are the strongest option: they see your current files and can draft into your inbox. ([Page 9](#page-9)) * **Projects, notebooks and built-in memory** (Claude Projects and memory, ChatGPT Projects and memory, Gemini Notebook, Copilot Notebooks) are fine to start with and easy to set up. But they’re copies or summaries held by the vendor: hard to see exactly what’s in them, and hard to take with you. One practitioner who tested seven memory products in July 2026 found none whose memory you could move elsewhere. Use them alongside your files, not instead. * **Team visibility differs.** In a shared ChatGPT project, everyone can read everyone’s chats; in a Claude Team project, they can’t. Neither assistant has memory shared across a team - the shared layer has to be your files. * **Microsoft Copilot** \- test that it reads your `.md` notes before relying on it. * **Local models** \- the right answer for a private vault; expect weaker answers than the big cloud assistants. ### Capturing meetings AI note-takers are where most brains get their raw material - and their biggest privacy risk. * Choose which meetings get recorded; never HR, board, privileged or regulated-client meetings. * Check the note-taker’s retention settings, and remember that deleting a recording there doesn’t delete copies you’ve exported. * Keep the transcript as a source; distil the work content; leave personal asides out. ([Page 7](#page-7)) ### Memory products and AI-built knowledge graphs A wave of products promises to give your assistant a memory - some by building a knowledge graph automatically from everything you feed them. Be careful: * **Their benchmarks are contested.** A published audit of the most-quoted memory benchmark found errors in its answer key and a scoring method that accepted many deliberately wrong answers; vendors have disputed and revised each other’s scores. (Most of what’s published in this area comes from companies with products in it.) And in some of the published comparisons, simply giving the assistant the full text, or a plain file plus ordinary search, did about as well as the specialised products. * **Automatically built graphs are expensive and opaque at this scale.** On general benchmarks they help most with questions that chain several facts, and can do worse on simple look-ups. Your hand-written links cost nothing and say what you meant. * **The honest test is your own.** If a product tempts you, run your twenty test questions through it and through your plain brain, and compare. ([Page 12](#page-12)) ### What we’d skip for now * Complex plugin stacks and dashboards before you have twenty good notes. * Bulk imports of everything you’ve ever written. * Building an elaborate set of types and relationships before a question needs them. * Any setup where you can’t see, in plain files, what the assistant “knows”. ### Signs you’ve outgrown a personal brain A personal brain is for one person, or a few - up to about three people who work closely together and can all see everything in it. Beyond that it isn’t the right option, however well it’s kept. You’ve reached its edge when **any one** of these is true: * **More than a few people - four or more - write in it or rely on it.** Review becomes a job rather than a habit, and “one writer per file” stops being something you can agree over coffee. * **It’s meant to serve a team, a department or the whole organisation**, rather than a person or a small working group. * **Different people must see different things** \- by client, by department, by clearance - and “a separate folder” no longer covers it. * **Regulated or contractually restricted data has to be in the brain**, and you need to show who saw what, and when. (Material you keep out of the brain, in its own system, doesn’t count.) * **You need a deletion to be provably complete** across every copy and every automation. * **Plain search keeps missing things** your monthly test should be finding, even after you’ve fixed the notes. * **The automations have become a system** \- many jobs, depending on each other, that someone has to look after. ### What comes next At that point you need a company brain: a store that holds your notes and their links, enforces who can see what, records where every answer came from, and runs your tests for you - while keeping plain files as the source of truth. * **The technical guide** \- our companion guide walks through building one, step by step, for people who want to build it themselves. \[Link to the build guide.\] * **somai** \- the studio that publishes this guide designs and builds company brains for organisations with exactly this need, either handed over for you to run or run for you, and owned by you either way. If you’d like to talk it through, email **[hello@somai.studio](mailto:hello@somai.studio)**. The first step is a conversation; the first paid step is usually a question audit - your real questions, answered in writing. The test questions you wrote on page 3 are a good thing to bring. Either way, everything you’ve built with this guide carries over. The questions, the ontology, the notes and the habits are the hard part - and you’ll already have them. ### Sources * Assistant memory portability test (July 2026), memory benchmark audits, and the GraphRAG and memory-benchmark studies are listed on the [references page](#references). * Meeting note-taker guidance - Mayer Brown (June 2026), see the [references page](#references). [contents ↑](#contents) [references →](#references) --- References The sources behind each page. ## References **How to read these.** Each source is marked with the kind of evidence it is: **measured** (a study or benchmark with numbers), **practitioner** (someone’s first-hand report) or **vendor** (a company’s own documentation, claim or survey). Most of this field is practitioner and vendor material, and no controlled study yet exists at the scale of a personal brain - so treat the measured findings as strong hints borrowed from nearby settings, not proof. Links were checked in **October 2026**. ### The essentials The handful we’d read first: 1. **Andrej Karpathy, “LLM Wiki”** (April 2026) - the pattern most personal brains now follow. _Practitioner._ 2. **Hong, Troynikov & Huber, “Context Rot: How Increasing Input Tokens Impacts LLM Performance”** (Chroma, July 2025) - assistants get worse as they’re given more to read. _Measured, by a search vendor._ 3. **Anthropic, “Effective context engineering for AI agents”** (September 2025) - keep what the assistant reads small and relevant. _Vendor._ 4. **Gloaguen et al., “Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?”** (ETH Zurich, 2026) - rules files don’t generally help, and overviews of the contents don’t help at all. _Measured, on coding tasks._ 5. **Ouyang et al., “HoH: A Dynamic Benchmark for Evaluating the Impact of Outdated Information on Retrieval-Augmented Generation”** (ACL 2025) - out-of-date information harms answers even when the current version is present. _Measured._ 6. **Bertsch et al., “Oolong”** (November 2025) and **Luo et al., “Towards Global Retrieval Augmented Generation” (GlobalQA)** (October 2025) - assistants struggle to count and list across many documents. _Measured._ · 7. **Noy & McGuinness, _Ontology Development 101_** \- the plain-English method behind page 4\. 8. **Hamel Husain, “Your AI Product Needs Evals”** (March 2024) - read the failures; test the parts separately. _Practitioner._ ### By topic #### How much to give an assistant (pages 1, 7, 9) * Chroma, “Context Rot” (July 2025). _Measured._ * Liu et al., “Lost in the Middle: How Language Models Use Long Contexts” (2023; TACL 2024). _Measured._ * Modarressi et al., “NoLiMa: Long-Context Evaluation Beyond Literal Matching” (Adobe Research, ICML 2025). _Measured._ * Anthropic, “Effective context engineering for AI agents” (September 2025). _Vendor._ #### Search and retrieval (pages 1, 9) * Thakur et al., “BEIR” (2021) - plain keyword search (BM25) as a strong baseline. _Measured._ * Sen et al., “Is Grep All You Need? How Agent Harnesses Reshape Agentic Search” (May 2026) - plain search generally beat vector search, but the agent setup mattered as much. _Measured, small (116 questions)._ * Anthropic, “Introducing Contextual Retrieval” (September 2024). _Vendor-measured._ * Chen et al., “Dense X Retrieval: What Retrieval Granularity Should We Use?” (2023) - smaller, single-idea units retrieve better. _Measured._ #### Time and staleness (pages 6, 12) * Ouyang et al., “HoH” (2025). _Measured._ * Wu et al., “LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory” (ICLR 2025) - keeping up with changed facts is hard for assistants with memory. _Measured._ * Slite, “The Hidden Dangers of Stale Documentation in 2026” (June 2026) - a survey of 143 people on AI tools answering from stale documents. _Vendor survey._ * Michael Nygard, “Documenting Architecture Decisions” (2011) - the decision-record pattern. _Practitioner._ #### Ontology and the knowledge graph (page 4) * Noy & McGuinness, _Ontology Development 101_. * Grüninger & Fox, enterprise modelling and competency questions. * W3C, SKOS Primer. * schema.org, Person. * Steph Ango, “How I use Obsidian”. _Practitioner._ * Nick Milo, ACE folder framework. _Practitioner._ * Johnny.Decimal. _Practitioner._ * Tiago Forte, “The PARA Method”. _Practitioner._ * Basic Memory. _Vendor._ * gbrain and its evaluations. _Vendor._ · * “When to use Graphs in RAG” (GraphRAG-Bench, rev. February 2026). _Measured._ * Jonathan Edwards, “Stop calling it memory” (March 2026). _Practitioner._ #### Rules files (page 5) * Anthropic, Claude Code memory and rules files. _Vendor._ * AGENTS.md. * Linux Foundation, Agentic AI Foundation (December 2025). * Gloaguen et al., “Evaluating AGENTS.md” (2026). _Measured, coding tasks._ * Lulla et al., “On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents” (2026). _Measured, coding tasks._ #### Getting things in, meetings and privacy (page 7) * Mayer Brown, “AI Notetakers: Productivity Tool or Emerging Legal Risk?” (June 2026). _Legal guidance._ * Runroom, “The Knowledge Brain: How to Turn Your Team’s Dispersed Information into a Living Asset” (October 2026). _Practitioner (agency)._ * Irtiza Hafiz, a separate vault for private notes. _Practitioner._ #### Structured data (page 8) * Anthropic engineering, “Code execution with MCP” (November 2025). _Vendor._ * Florian Bruniaux, team knowledge base guide (September 2026). _Practitioner._ * Scotty Peterson, job-hunt system (July 2026). _Practitioner._ * Obsidian command-line interface. _Vendor._ * Bertsch et al., “Oolong” (2025) and Luo et al., GlobalQA (2025). _Measured._ · #### Connecting assistants (page 9) and automations (page 11) The tool documentation for each assistant and automation service is listed at the foot of pages 9 and 11, dated October 2026. #### Testing (pages 3, 12) * Anthropic, “Demystifying evals for AI agents” (January 2026) - “20-50 simple tasks drawn from real failures is a great start”. _Vendor._ * Hamel Husain, “Your AI Product Needs Evals” (2024). _Practitioner._ #### Memory products and the tools landscape (page 15) * Stan Tyan, “I Tested 7 AI Memory Products for Portability - All 7 Lock You In” (July 2026). _Practitioner._ * Penfield Labs, audit of the LoCoMo memory benchmark (2026). _Audit by a company that sells a memory system._ * Letta, “Benchmarking AI Agent Memory: Is a Filesystem All You Need?” (August 2025). _Vendor._ * Simon Willison, “I really don’t like ChatGPT’s new memory dossier” (May 2025). _Practitioner._ * JA Westenberg, “I Deleted My Second Brain” (June 2025). _Practitioner._ #### First-hand builds (page 14) * Cyril Simonnet - * Dan Okhlopkov - * Kenneth Reitz - * Eleanor Konik - * Stefan Imhoff - * Eric Roby - * Steve Phelps - * XDA (local model with file access) - * Hacker News threads - · · ### About the “Seen in practice” boxes These come from brains we’ve built or studied directly - a personal brain, a small-business brain and a company brain - read for their structure and their failures, never their content. They’re unnamed by design.