A small brain that works.

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.

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.

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.

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.

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: 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. The skills send nothing anywhere, and the disclaimer above applies to them too.

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.

How to read this guide

The pages build on each other, but each stands on its own:

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 applies throughout.

contents ↑ 01 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

The twelve principles

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) - https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• Chroma, “Context Rot” (July 2025) - https://www.trychroma.com/research/context-rot
• Liu et al., “Lost in the Middle” (TACL 2024) - https://arxiv.org/abs/2307.03172
• JA Westenberg, “I Deleted My Second Brain” (June 2025) - https://westenberg.beehiiv.com/p/i-deleted-my-second-brain
• Slite, survey on stale documentation (June 2026) - https://slite.com/learn/dangers-of-stale-documentation
• The remaining studies are listed on the references page.

contents ↑ 02 The design →

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 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 6: anatomy of a good note

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

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

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 9: connecting your assistant

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 11 · 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

How this differs from what’s out there

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” - https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• Basic Memory - https://github.com/basicmachines-co/basic-memory
• Obsidian help: Bases - https://obsidian.md/help/bases
• See also the references page.

contents ↑ 03 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).
3. Test - with their answers written down, they become a monthly check (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:

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:

On top of your twenty, add two questions the brain should refuse to answer - something on your “never goes in” list (page 7). A good brain says “I don’t have that”, not a guess. That makes twenty-two in all.

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.
• Hamel Husain, on separating retrieval failures from answer failures, and why a perfect score means the test is too easy - see the references page.

contents ↑ 04 Your ontology →

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. 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).

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.

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:

Six relationships - written as properties that hold links:

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 - 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.

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 - https://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html
• Grüninger & Fox, enterprise modelling method (competency questions) - https://eil.mie.utoronto.ca/theory/enterprise-modelling/entmethod
• W3C, SKOS Primer - https://www.w3.org/TR/skos-primer/
• schema.org, Person - https://schema.org/Person
• Obsidian help: Properties - https://obsidian.md/help/properties · Bases - https://obsidian.md/help/bases · Graph view - https://obsidian.md/help/plugins/graph
• Steph Ango, “How I use Obsidian” - https://stephango.com/vault
• GraphRAG-Bench, “When to use graphs in RAG” - https://arxiv.org/abs/2506.05690
• “Stop calling it memory” (the contact written three ways) - https://limitededitionjonathan.substack.com/p/stop-calling-it-memory-the-problem

contents ↑ 05 The shape →

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

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

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.

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 - https://code.claude.com/docs/en/memory
• AGENTS.md - https://agents.md/
• Linux Foundation, Agentic AI Foundation announcement (December 2025) - https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
• ETH Zurich study of rules files for coding agents - arXiv 2602.11988
• Obsidian help: syncing notes - https://obsidian.md/help/sync-notes

contents ↑ 06 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

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.

          
                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]]"
              ---
        

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) - https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions
• Studies on note summaries and metadata improving retrieval are listed on the references page.

contents ↑ 07 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). 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.

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 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).
• 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.
• Runroom, on running a team brain from the decisions a team must make - see the references page.

contents ↑ 08 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

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.

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) - https://www.anthropic.com/engineering/code-execution-with-mcp
• Florian Bruniaux, Claude Code Ultimate Guide: team knowledge base (September 2026) - https://cc.bruniaux.com/guide/team-knowledge-base/
• Obsidian command-line interface - https://obsidian.md/help/cli
• Scotty Peterson, a job-hunt system built with Claude Code (July 2026) - https://www.scottypeterson.net/blog/how-to-build-a-job-hunt-system-with-claude-code
• Counting and aggregation studies (GlobalQA, OOLONG) - see the references page.

contents ↑ 09 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

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 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.

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.

At a glance

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 - https://support.claude.com/en/articles/13345190-get-started-with-claude-cowork · chat and Cowork as one app - https://support.claude.com/en/articles/16761823-claude-cowork-and-chat-are-one-claude · Claude Code desktop - https://code.claude.com/docs/en/desktop-quickstart · Projects - https://support.claude.com/en/articles/9517075-what-are-projects · data use - https://privacy.claude.com/en/articles/10023580-is-my-data-used-for-model-training
• OpenAI: ChatGPT Work and Codex - https://help.openai.com/en/articles/20001275-chatgpt-work-and-codex · Projects - https://help.openai.com/en/articles/10169521-projects-in-chatgpt · custom MCP - https://help.openai.com/en/articles/12584461-connecting-custom-mcp-servers-in-chatgpt · AGENTS.md in Codex - https://learn.chatgpt.com/docs/agent-configuration/agents-md
• Google: Antigravity CLI migration - https://antigravity.google/docs/cli/gcli-migration/ · Gemini Notebook sources - https://support.google.com/notebooklm/answer/16215270 · Gemini privacy - https://support.google.com/gemini/answer/13594961
• Microsoft: Copilot Notebooks references - see the references page · Agent Builder knowledge - https://learn.microsoft.com/en-us/microsoft-365/copilot/extensibility/agent-builder-add-knowledge · GitHub Copilot instructions - https://docs.github.com/en/copilot/reference/custom-instructions-support
• Local: LM Studio - https://lmstudio.ai/docs/app/mcp · Copilot for Obsidian - https://github.com/logancyang/obsidian-copilot
• Obsidian: Local REST API - https://github.com/coddingtonbear/obsidian-local-rest-api · CLI - https://obsidian.md/help/cli
• Notion connector - https://developers.notion.com/docs/get-started-with-mcp

contents ↑ 10 Windows →

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).
• 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:

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

Sources (checked October 2026)

• Obsidian help: Properties - https://obsidian.md/help/properties · Bases - https://obsidian.md/help/bases · Graph view - https://obsidian.md/help/plugins/graph · Sync - https://obsidian.md/help/sync-notes · CLI - https://obsidian.md/help/cli
• Obsidian Git - https://community.obsidian.md/plugins/obsidian-git · Base Graph - https://community.obsidian.md/plugins/base-graph · Graph Link Types - https://community.obsidian.md/plugins/graph-link-types
• Notion connector - https://developers.notion.com/docs/get-started-with-mcp
• Dendron (maintenance only) - https://github.com/dendronhq/dendron
• Steve Phelps, syncing Notion into a Claude Code brain - https://sphelps.substack.com/p/a-shared-memory-for-claude-code

contents ↑ 11 Automations →

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:

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.

What to automate - and what never to

Good first automations all create a new file and leave your notes alone:

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.

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

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) - https://code.claude.com/docs/en/routines
• Claude desktop scheduled tasks - https://code.claude.com/docs/en/desktop-scheduled-tasks
• Claude Code headless mode - https://code.claude.com/docs/en/headless
• Claude Code GitHub Actions - https://code.claude.com/docs/en/github-actions
• Claude Cowork scheduled tasks - https://support.claude.com/en/articles/13854387
• ChatGPT desktop app scheduled tasks - https://learn.chatgpt.com/docs/automations
• ChatGPT Tasks - https://help.openai.com/en/articles/10291617
• Gemini scheduled actions - https://support.google.com/gemini/answer/16316416
• Microsoft 365 Copilot scheduled prompts - https://learn.microsoft.com/microsoft-365/copilot/scheduled-prompts
• Power Automate OneDrive connector - https://learn.microsoft.com/en-us/connectors/onedriveforbusiness/
• GitHub Actions schedules - https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows
• n8n Schedule Trigger - https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.scheduletrigger/
• Obsidian, syncing notes (one sync service per vault) - https://obsidian.md/help/sync-notes
• Obsidian Git plugin - https://community.obsidian.md/plugins/obsidian-git
• Git repositories damaged inside OneDrive - https://techcommunity.microsoft.com/t5/onedrive/onedrive-is-corrupting-my-git-repositories/td-p/3898283
• Windows Task Scheduler settings - https://learn.microsoft.com/en-us/powershell/module/scheduledtasks/new-scheduledtasksettingsset
• macOS scheduled jobs (launchd) - https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/ScheduledJobs.html

contents ↑ 12 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).
3. Read the tidy-up report (if you’ve automated one - 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 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:

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 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.

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.
• Hamel Husain on reading failures and separating retrieval from answers - see the references page.
• Anthropic on starting with twenty to fifty real test tasks (January 2026) - see the references page.

contents ↑ 13 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.”

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.

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.

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.

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.

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.

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.

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/.

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.

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.

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.

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 .

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.

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.

 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.

How many  ? Answer from
, not by reading notes. Say which table you
used and list the items you counted.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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 ↑ 14 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.

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.

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.

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) - https://cyrilsimonnet.substack.com/p/i-built-a-second-brain-with-claude
• Dan Okhlopkov (founder/operator) - https://okhlopkov.com/second-brain-obsidian-claude-code/
• Irtiza Hafiz (separate private vault) - https://irtizahafiz.com/blog/how-i-use-obsidian-with-claude
• XDA, a local model with filesystem access (July 2026) - https://www.xda-developers.com/ditched-claude-code-after-giving-local-llm-filesystem-access/
• Eleanor Konik (writer, July 2025) - https://www.eleanorkonik.com/p/how-claude-obsidian-mcp-solved-my
• Stefan Imhoff (design engineer, March 2026) - https://stefanimhoff.de/agentic-note-taking-obsidian-claude-code
• Hacker News discussion on team brains - https://news.ycombinator.com/item?id=49394827

contents ↑ 15 Tools, honestly →

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)
• 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)
• 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)

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)

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. 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.
• Meeting note-taker guidance - Mayer Brown (June 2026), see the references page.

contents ↑ 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. https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
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. https://www.trychroma.com/research/context-rot
3. Anthropic, “Effective context engineering for AI agents” (September 2025) - keep what the assistant reads small and relevant. Vendor. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
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. https://arxiv.org/abs/2602.11988
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. https://arxiv.org/abs/2503.04800
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. https://arxiv.org/abs/2511.02817 · https://arxiv.org/abs/2510.26205
7. Noy & McGuinness, Ontology Development 101 - the plain-English method behind page 4. https://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html
8. Hamel Husain, “Your AI Product Needs Evals” (March 2024) - read the failures; test the parts separately. Practitioner. https://hamel.dev/blog/posts/evals/

By topic

How much to give an assistant (pages 1, 7, 9)

• Chroma, “Context Rot” (July 2025). Measured. https://www.trychroma.com/research/context-rot
• Liu et al., “Lost in the Middle: How Language Models Use Long Contexts” (2023; TACL 2024). Measured. https://arxiv.org/abs/2307.03172
• Modarressi et al., “NoLiMa: Long-Context Evaluation Beyond Literal Matching” (Adobe Research, ICML 2025). Measured. https://arxiv.org/abs/2502.05167
• Anthropic, “Effective context engineering for AI agents” (September 2025). Vendor. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents

Search and retrieval (pages 1, 9)

• Thakur et al., “BEIR” (2021) - plain keyword search (BM25) as a strong baseline. Measured. https://arxiv.org/abs/2104.08663
• 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). https://arxiv.org/abs/2605.15184
• Anthropic, “Introducing Contextual Retrieval” (September 2024). Vendor-measured. https://www.anthropic.com/engineering/contextual-retrieval
• Chen et al., “Dense X Retrieval: What Retrieval Granularity Should We Use?” (2023) - smaller, single-idea units retrieve better. Measured. https://arxiv.org/abs/2312.06648

Time and staleness (pages 6, 12)

• Ouyang et al., “HoH” (2025). Measured. https://arxiv.org/abs/2503.04800
• 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. https://arxiv.org/abs/2410.10813
• 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. https://slite.com/learn/dangers-of-stale-documentation
• Michael Nygard, “Documenting Architecture Decisions” (2011) - the decision-record pattern. Practitioner. https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions

Ontology and the knowledge graph (page 4)

• Noy & McGuinness, Ontology Development 101. https://protege.stanford.edu/publications/ontology_development/ontology101-noy-mcguinness.html
• Grüninger & Fox, enterprise modelling and competency questions. https://eil.mie.utoronto.ca/theory/enterprise-modelling/entmethod
• W3C, SKOS Primer. https://www.w3.org/TR/skos-primer/
• schema.org, Person. https://schema.org/Person
• Steph Ango, “How I use Obsidian”. Practitioner. https://stephango.com/vault
• Nick Milo, ACE folder framework. Practitioner. https://blog.linkingyourthinking.com/notes/ace-folder-framework
• Johnny.Decimal. Practitioner. https://johnnydecimal.com/10-19-concepts/11-core/11.01-introduction/
• Tiago Forte, “The PARA Method”. Practitioner. https://fortelabs.com/blog/para/
• Basic Memory. Vendor. https://github.com/basicmachines-co/basic-memory
• gbrain and its evaluations. Vendor. https://github.com/garrytan/gbrain · https://github.com/garrytan/gbrain-evals
• “When to use Graphs in RAG” (GraphRAG-Bench, rev. February 2026). Measured. https://arxiv.org/abs/2506.05690
• Jonathan Edwards, “Stop calling it memory” (March 2026). Practitioner. https://limitededitionjonathan.substack.com/p/stop-calling-it-memory-the-problem

Rules files (page 5)

• Anthropic, Claude Code memory and rules files. Vendor. https://code.claude.com/docs/en/memory
• AGENTS.md. https://agents.md/
• Linux Foundation, Agentic AI Foundation (December 2025). https://www.linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
• Gloaguen et al., “Evaluating AGENTS.md” (2026). Measured, coding tasks. https://arxiv.org/abs/2602.11988
• Lulla et al., “On the Impact of AGENTS.md Files on the Efficiency of AI Coding Agents” (2026). Measured, coding tasks. https://arxiv.org/abs/2601.20404

Getting things in, meetings and privacy (page 7)

• Mayer Brown, “AI Notetakers: Productivity Tool or Emerging Legal Risk?” (June 2026). Legal guidance. https://www.mayerbrown.com/en/insights/publications/2026/06/ai-notetakers-productivity-tool-or-emerging-legal-risk
• Runroom, “The Knowledge Brain: How to Turn Your Team’s Dispersed Information into a Living Asset” (October 2026). Practitioner (agency). https://www.runroom.com/en/realworld/the-knowledge-brain-how-to-turn-your-team-s-dispersed-information-into-a-living-asset-lab
• Irtiza Hafiz, a separate vault for private notes. Practitioner. https://irtizahafiz.com/blog/how-i-use-obsidian-with-claude

Structured data (page 8)

• Anthropic engineering, “Code execution with MCP” (November 2025). Vendor. https://www.anthropic.com/engineering/code-execution-with-mcp
• Florian Bruniaux, team knowledge base guide (September 2026). Practitioner. https://cc.bruniaux.com/guide/team-knowledge-base/
• Scotty Peterson, job-hunt system (July 2026). Practitioner. https://www.scottypeterson.net/blog/how-to-build-a-job-hunt-system-with-claude-code
• Obsidian command-line interface. Vendor. https://obsidian.md/help/cli
• Bertsch et al., “Oolong” (2025) and Luo et al., GlobalQA (2025). Measured. https://arxiv.org/abs/2511.02817 · https://arxiv.org/abs/2510.26205

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. https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents
• Hamel Husain, “Your AI Product Needs Evals” (2024). Practitioner. https://hamel.dev/blog/posts/evals/

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. https://dev.to/stantyan/i-tested-7-ai-memory-products-for-portability-all-7-lock-you-in-31pm
• Penfield Labs, audit of the LoCoMo memory benchmark (2026). Audit by a company that sells a memory system. https://dev.to/penfieldlabs/we-audited-locomo-64-of-the-answer-key-is-wrong-and-the-judge-accepts-up-to-63-of-intentionally-33lg
• Letta, “Benchmarking AI Agent Memory: Is a Filesystem All You Need?” (August 2025). Vendor. https://www.letta.com/blog/benchmarking-ai-agent-memory
• Simon Willison, “I really don’t like ChatGPT’s new memory dossier” (May 2025). Practitioner. https://simonwillison.net/2025/May/21/chatgpt-new-memory/
• JA Westenberg, “I Deleted My Second Brain” (June 2025). Practitioner. https://westenberg.beehiiv.com/p/i-deleted-my-second-brain

First-hand builds (page 14)

• Cyril Simonnet - https://cyrilsimonnet.substack.com/p/i-built-a-second-brain-with-claude
• Dan Okhlopkov - https://okhlopkov.com/second-brain-obsidian-claude-code/
• Kenneth Reitz - https://kennethreitz.org/essays/2026-03-06-obsidian_vaults_and_claude_code
• Eleanor Konik - https://www.eleanorkonik.com/p/how-claude-obsidian-mcp-solved-my
• Stefan Imhoff - https://stefanimhoff.de/agentic-note-taking-obsidian-claude-code
• Eric Roby - https://codingwithroby.substack.com/p/how-i-built-a-second-brain-for-agents
• Steve Phelps - https://sphelps.substack.com/p/a-shared-memory-for-claude-code
• XDA (local model with file access) - https://www.xda-developers.com/ditched-claude-code-after-giving-local-llm-filesystem-access/
• Hacker News threads - https://news.ycombinator.com/item?id=47899844 · https://news.ycombinator.com/item?id=49394827 · https://news.ycombinator.com/item?id=46826277

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.