The first second brain I built properly took about a month. It has since seeded three or four more, and the one behind this website reached a working state in three days. So when someone asks me whether they should fund one, I say yes, and then I ask who is going to own it.
A second brain is a shared store of facts that your AI assistants read before they answer. It holds how your business actually works, in your language, with your exceptions written down. Claude, Codex, GitHub Copilot and Microsoft 365 Copilot can all work from one, and the tooling gets better every month.
It also needs an owner.
The first week belongs
to the person who knows the work.
Onboarding a second brain takes at least a week of a skilled subject matter expert or product manager, whoever holds the vision for the work. That person writes down how the job is really done: the exceptions, the judgment calls, the decisions that were made in a meeting and never written up anywhere.
I keep one order strictly. People discuss and decide, and only then does the decision get distilled into the brain. An assumption that goes in early causes drift, and everything built on top of it gets more complicated.
In my larger build, phase-based commands walk the operator through setting up a new brain one phase at a time, using a standard protocol.
Once it's running, the brain learns from the work itself. Every time an agent runs, it logs what worked and what failed. The skill that tells the agent how to do the job gets corrected first, and the next run is better for it. Distillation can fire when new material lands in Teams or on disk, when an operator runs it by hand, on a schedule, or through automation. With that loop in place and an operator steering it, the brain gets smarter as it is used, and scheduled maintenance keeps it that way.
The outputs are extraordinary. A team stops re-explaining itself, and a new person asks the brain first and gets the answer a senior colleague would have given.
Decisions get corrected
where they sit.
Assistants document decisions as they go, and left to themselves they stack them. They record decision A. Later they record decision C, which reverses A. Then decision T changes C. All three stay in the file, nothing says which one is current, and the next agent to read it has to guess.
I call this strata and layering. It is the most common way I've seen a fact base get confusing.
The rule I use is to correct in place. A new decision replaces the old one where the old one sits, and version control keeps the history. A hook, a small check that runs automatically, reviews each write before it lands and flags one that adds a layer where it should have corrected one. Hooks also keep the model's own commentary out of the record, such as its notes to itself about what it tried and why.
"Second brains are for fact not commentary."
The same thing happens to skills. On this site, the skill that guides how agents write these Journal entries picked up nine separate corrections about tone in one afternoon. Each one was reasonable, none replaced the one before it, and the writing got worse with every addition. I rolled it back to the last version that worked, and now a change to it replaces a line rather than adding one.
A guardian decides
what gets in.
I've rebuilt a brain from scratch a few times, each time because assumptions got in. I could see it right after the distillation run: a lot of wiki pages had been updated with logic nobody had decided on.
Pulling that back out is hard when other agents and loops are running at the same time. By the time the bad fact is found, concurrent work has already built on it, so the error snowballs and removing it collides with work in progress. It's easier to rebuild the brain from the facts in the original than to chase a contradiction through everything that has copied it.
People trust a second brain's answers, whether it serves one team or a whole enterprise. That trust has to hold every time, which is why I rebuild a contaminated brain from its facts, and why the operator has to be someone who knows the work.
"This is why skilled subject matter experts are required to be operators and guardians of the truth. This is human judgement not mechanical operations."
A guardian decides what the brain is allowed to hold. When a distillation run hands them a page of changes, they can tell a decision from an assumption at a glance. The models are very capable, and the operator adds what they can't see: the big picture of the business.
Facts live in the wiki,
behavior in the skills.
When I started working this way about a year and a half ago, skills didn't really exist. We used slash commands, and GitHub Copilot called them instructions. I understood quickly that documentation mattered. It took longer to see where each thing belonged.
The split I use now is simple. The wiki holds facts. The agentic layer holds behavior: agents, skills, commands, workflows and hooks. Behavior needs facts to operate against, and it needs a place to persist the new facts it learns. When Andrej Karpathy shared his idea of a wiki maintained by an LLM, it fit what I was already doing and gave everyone common language for it. That common language also makes the pattern easier to explain to clients.
Every repo I build also gets a north star, a short statement of its purpose, and the agents are told to focus on work that moves it. In my experience that keeps them off tangents.
Page size matters as well. Most of my repos have rules on wiki page length, because an agent loads the wiki a page at a time, and an overlong page crowds out the work. I let the content come first. Once there is enough of it, the pages get split, broken into folders and given frontmatter, based on what is actually there.
Skills cost context. Early on I loaded so many into GitHub Copilot that I went over its tool limit, and I had to disable tools to get back under it. Now I keep only the skills a build actually uses.
I don't import third-party skills. I read them for ideas, then have the model build a better one for my repo, dialed in to the sliver of the work that matters to my build. Most third-party skills are shaped around their creator's workflow.
I also believe the labs track the most popular open-source skills and add them to training runs. If a skill was popular before a model's training cutoff, the model probably knows it natively already. The skills worth writing are about your own organization's procedures, which no training run has seen.
Copilot works best
anchored to the brain.
Microsoft 365 clients often ask me whether Copilot can just read their SharePoint. It can, and it will surface everything in there faithfully, mess included.
What works is anchoring. Point the session at an authoritative index in the second brain, tell Copilot that index is authoritative, and it will set aside the noise around it. I used an old-school version of this with a Word guardrail document: reference it in a chat and the right context loads.
The bigger change is in how documents get made. When the brain's skills run standard workflows, one-off document creation turns into an interview. The AI asks, a person answers, and the output is standardized context that a human reviews and approves. I think that means organizations will produce fewer documents, and the ones they do produce will follow a repeatable procedure.
This entry was made the same way. I answered interview questions over several rounds, the draft was written from my answers, and I review it before it goes anywhere.
Copilot's limit today is depth. It can't iterate the way a working session in Claude Code or Codex can. I think Microsoft will close part of that gap. They've made Markdown a first-class format and already have SharePoint skills, and middleware connecting traditional systems can fill in what's left. If that's the environment you're working in, here is how I set up a second brain on Microsoft 365 and beyond.
Shared context is
a new kind of infrastructure.
Replit put it well on August 3: when truth is shared, AI becomes infrastructure. They were describing their own internal truth layer. I agree, and I use second brains as a single source of truth every day.
It is infrastructure of a kind that doesn't have a settled name yet. Your Azure bill covers servers and storage. This is the maintained layer of facts, skills and hooks that every agent in an organization reads from before it acts, and the people who keep it true. I've been calling it Agentic Context Infrastructure.
How much of it an organization needs depends on scale. A small team can run on one brain. An enterprise could have dozens: a central brain for enterprise-wide policy and procedure, and project brains with their own permissions, whose results get distilled back into the center when the project is done. At that point you want brain templates, commands that spin up a new brain from one, and governance around all of it.
Scope grows with identity and data connections, the number of systems of record, the volume of content to distill, the number of operators, and the training and change management the people using it will need.
What stays out depends on the brain. Client data lives in dedicated client repos, and security keys and anything privacy-related are always protected. A legal second brain, though, is almost entirely sensitive data. In an enterprise, what each brain may hold gets enforced with hooks and scheduled maintenance.
Every one of those brains has an operator. A project or product operator may own several brains at once and use them for almost all their work, codifying each repeatable pattern into skill craft as they go.
I'm excited to see where this goes next. The industry is starting to give these brains arms and legs in Teams, Slack and Discord, and we're heading toward second brains that prompt us.
So if you're weighing whether to fund one, start with the person. Who in your organization knows the work well enough to decide what's true, and can you give them the first week?
Stop layering
before it lands.
This is a smaller version of the hook that guards the wiki behind this website. Save the script as .claude/hooks/check-layering.mjs and register it in .claude/settings.json. From then on Claude Code refuses any write to your wiki/ folder that stacks a new layer on an old fact instead of correcting it, and tells the agent why.
{
"hooks": {
"PreToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{ "type": "command", "command": "node \"$CLAUDE_PROJECT_DIR/.claude/hooks/check-layering.mjs\"" }
]
}
]
}
}#!/usr/bin/env node
// Refuses a write to the wiki that stacks a new layer on an old fact instead of correcting it.
// Claude Code runs it before every Write or Edit. Exit 0 allows the write; exit 2 blocks it and
// sends the reason back to the agent. Git keeps the history, so the page only has to be true now.
import { readFileSync, existsSync } from 'node:fs';
import path from 'node:path';
const WATCHED = ['wiki/']; // folders that hold facts
const LAYERS = [
{ name: 'note to a future reader', re: /\b(?:note to (?:the )?next agent|for the next (?:agent|session)|future readers? should)\b/i },
{ name: 'self-described staleness', re: /\b(?:this (?:page|section) is (?:out of date|stale)|no longer (?:accurate|true|current)|superseded by|kept for reference)\b/i },
{ name: 'stacked decision', re: /\b(?:update:|previously we|was later changed|this reverses|instead of the earlier)\b/i },
{ name: 'provisional state', re: /\b(?:for now|temporarily|until we decide|as a stopgap)\b/i },
{ name: 'deferred work', re: /\b(?:TODO|FIXME|TBD)\b/ },
{ name: 'model commentary', re: /\b(?:I (?:tried|think|noticed|will now)|let me|as an AI)\b/i },
];
const payload = JSON.parse(readFileSync(0, 'utf8'));
const input = payload.tool_input ?? {};
const file = path.relative(payload.cwd ?? process.cwd(), input.file_path ?? '').split(path.sep).join('/');
const added = input.content ?? input.new_string ?? '';
if (!WATCHED.some((dir) => file.startsWith(dir)) || !added) process.exit(0);
// Only a kind of layer the page does not already carry is refused, so a page with old
// problems can still be edited while you clean it up.
const prior = existsSync(input.file_path) ? readFileSync(input.file_path, 'utf8') : '';
const found = (text) => LAYERS.filter((l) => l.re.test(text)).map((l) => l.name);
const introduced = found(added).filter((name) => !found(prior).includes(name));
if (introduced.length) {
console.error(`Refused: this write adds ${introduced.join(', ')} to ${file}.\n`
+ 'Correct the fact where it sits instead of adding a layer. Git keeps the history.');
process.exit(2);
}It only refuses a kind of layer the page does not already carry, so an old page can still be edited while you clean it up. Tune the patterns to the way your own team writes.