A few people asked me to explain how I manage my notes. There’s nothing complicated or secret going on, so I figured I’d write a short article.
I increasingly think of personal wikis not as notes, but as infrastructure for AI-native work. And the main conclusion I’ve reached is simple: an AI doesn’t need «memory» in the sense of some magical long-term context buried inside the model. It needs a proper external environment - a wiki, rules for working with it, and a layer that can read, write, and act.
Compressed into one line:
Chat is the interface. Wiki is memory. Agents are operators.
The idea is close to what Karpathy described in the LLM-wiki: instead of re-running search over a raw corpus every time, you can compile knowledge into a coherent wiki. This principle isn’t just for research. It maps neatly onto any personal work, learning, hobbies, and even everyday processes.
Roughly, I see three layers:
Knowledge - markdown, notes, sources, reports, presentations
↓
Protocols - AGENTS.md, CLAUDE.md, schemas, skills, conventions
↓
Execution - Claude Code, Hermes, Codex, cron jobs, scriptsKnowledge - the knowledge layer
The base layer is the knowledge itself: markdown files, notes on articles, reports, presentations, summaries, raw sources. Everything that should outlive a single chat session.
The key point is that this is not «the model’s memory». It’s external memory: editable, portable, human-readable. A human can open it in Obsidian or VS Code. An agent can read it. You can version it in git and improve it gradually.
There’s a subtle but fundamental difference here. One thing is «memory inside a product», where the model has remembered something somewhere and you control neither the format nor the lifespan of that data. Another thing entirely is your own knowledge layer, which doesn’t vanish when you switch model, provider, or interface. That’s owned infrastructure, not a feature of someone else’s service.
Protocols - the protocol layer
The second layer is protocols. Not the knowledge itself, but the rules for handling it: AGENTS.md, CLAUDE.md, schemas, skills, conventions. This layer tells the agent not just «read the files», but exactly how to manage the notes. In essence it’s the same mental model for working with context that usually lives in my head, only written out explicitly.
For example:
- where to put new sources;
- how to write a summary;
- when to create a new concept note;
- how to update indexes;
- how not to breed duplicates;
- which actions can be done automatically, and where to ask a human;
- how to route a request between different spaces.
This is an operating manual for working with context. And it’s not optional: without the protocol layer, a wiki quickly turns into a graveyard of markdown files. Knowledge piles up but never becomes a system.
Execution - the execution layer
The third layer is execution. Technically another human could do the executing, but in practice what I care about is AI agents: Claude Code, Hermes, Codex, cron jobs, custom scripts - any harness that can read, write, run tools, and act within the rules.
At this level the wiki stops being an archive and becomes a working system. The agent can read the relevant context, find related notes, propose a structure, add a new note, update an index, assemble a draft, check for contradictions, run a routine operation on a schedule.
And here’s the main thing. With notes there’s always an eternal tradeoff: either you spend a ton of time organizing, or you spend just as much later searching. The execution layer removes that choice. The agent takes on the painstaking work of indexing and linking, and you get fast access to information. It’s the agents that make knowledge alive.
But no illusions: the agent layer is only as good as the knowledge and protocols it’s given. Without the first two layers it’s just a chatty executor.
Spaces - separating contexts
For me this already lives as a set of separate spaces. There’s a shared brain for articles, ideas, and evergreen knowledge. There are separate contexts for language learning, home documentation, hobbies, pet projects, and work tasks. Each space has its own files, its own rules, and its own agent context.
I already have several dozen such spaces, and they split into groups: work, learning, everyday. Some of them are personal, with different access rights, because not everything should sit in one shared place. And this scales surprisingly well: different contexts, different rules, different agents - one shared principle.
The main effect is routing. If I ask about an article, the agent goes to one context. About language - to another. About clothes - to a third. About home documentation - to a fourth. Requests don’t fall into one endless chat where everything is mashed together.
What it looks like in practice
So as not to sound abstract, I’ll show it on the example of a work space. This isn’t a tutorial or a full dump of the structure, more an illustration of the principle.
My work brain is a separate vault with a couple dozen spaces: project, hiring, mentoring, R&D lab, community, certification, personal brand, project x, project y, and so on. Each space follows the same template:
- folder note - the space’s index, the entry point;
CLAUDE.md(or more generallyAGENTS.md) - the routing rules: which keywords land a request here and how things are done here;log/- an operations log for provenance: what the agent did and when.
Beyond that there’s no rigid structure - the set of folders forms around the specific project. In some places you need meetings/ for syncs, in others runbooks/ for working procedures, somewhere decisions/ for key decisions, wiki/ for synthesized knowledge, or raw/ for sources. A folder appears when there’s actually material to fill it, not the other way around.
If we go down to the files, it looks roughly like this:
worknote/
├── AGENTS.md # shared rules for the whole vault
├── wiki/ # knowledge shared across all spaces
└── spaces/
├── project-x/ # a work project
│ ├── project-x.md # folder note - the space's index
│ ├── CLAUDE.md # routing and working rules
│ ├── log/ # agent operations log
│ ├── meetings/ # meetings and syncs
│ ├── runbooks/ # working procedures
│ └── decisions/ # key decisions
└── language-learning/ # a personal context
├── language-learning.md
├── CLAUDE.md
└── wiki/And the rules the agent works by inside a space sit right next to it - in its CLAUDE.md:
# spaces/project-x/CLAUDE.md
Requests about project X land here: architecture, evals, releases.
- meetings and syncs → meetings/
- working procedures → runbooks/
- imported docs → raw/
- after any operation → write to log/When a new task or note arrives, the agent uses keywords to determine the right space and then acts by its rules, not the general ones. The structure is the same, the contents differ. Because of that it’s easy to add new spaces: the template is already known to both the agent and me.
Another example: reading articles
Inside the brain, one of the most frequent scenarios is reading articles. Not just any articles, but work and technical ones. I don’t want to merely save links to read-it-later. What matters more to me is that after reading there’s a reusable knowledge artifact left behind: a note, a summary, the key ideas, links to existing concept pages.
Over time this becomes not a «read it someday» list, but a map of ideas. And the agent can do more than just find an article - it can help assemble a synthesis: what I’ve already read on the topic, which ideas recur, where there are contradictions, what could turn into a post or a project.
This is exactly where a line runs that people often confuse:
RAG answers questions. A wiki accumulates understanding.
RAG pulls the relevant chunk for a query. A wiki gradually turns into a coherent picture that only gets better the more you put into it.
Raw and log: data lineage
Another habit that pays off: I try to keep full data lineage. Every reworked note keeps its raw original version, and the log/ records what the agent did with it and when.
Why. LLMs get better, and rules and protocols improve too. When that happens, it’s useful to be able to re-index your space from scratch: run a new model and new rules over the raw sources, rather than over summaries already «spoiled» by previous processing. The raw material plus the operations log are what make the whole system reversible and rebuildable.
Scaling
One person - a personal brain. A family - a shared vault. A team - a team wiki. A department - a network of wikis and procedures. A company - a corporate brain.
But the higher the level, the more problems appear that barely exist at the personal level. Even a family vault is already harder: multiple users, different expectations, different versions of the truth. In a company it’s harder still: access control, ownership, trust, freshness, conflicting knowledge, compliance, incentives, the political reality of the organization. And a separate pain is making sure data doesn’t get lost and no gaps appear in the information. At scale you can’t hold that by hand anymore - automation is clearly needed here.
That’s why I’m not betting on a top-down approach in the «let’s build a corporate brain right away» style. Too much complexity is taken on up front. Yes, we’ll get there, but we’re not there yet.
The realistic path right now is bottom-up: person → team → department → company. First the practices are tried out at the level of a single person, where the feedback loop is fast and the cost of a mistake is low. Then the patterns that work get carried over to the team, then to the department. And only out of that can something resembling a real company brain grow.