case study · check-in 01in progress

I stopped re-explaining myself

Every session starts from nothing. PersonalOS is a vault built so an agent reads my decisions before it acts, and I never explain them twice.

obsidianpythonsqliteautomation
project
PersonalOS
published
2026-07-27
updated
2026-07-31

Every AI session starts from nothing, so I re-explain the project, the constraints, and the decision I made three weeks ago along with the reason behind it, and then the session ends and all of it evaporates. PersonalOS is my answer to that: an Obsidian vault that is also a git repository, where the decisions live in files an agent reads before it touches anything. It runs to 196 commits, 8 architecture decision records, 150 notes, and six scheduled jobs, and somewhere in there it stopped being a filing cabinet I re-read and became a co-brain that does the recall for me.

The model is not the bottleneck

The thing that costs me is not the model's reasoning, it is that the model arrives ignorant of everything specific to me, every single time. It does not know that a wrongly-filed note is worse than an unfiled one in my system, and it does not know I never use an em dash. It does not know which of two folders is canonical and which is a mirror, or why that distinction got made in the first place. So it re-derives, which means it crawls, it infers, and when inference fails it guesses, and I pay for that in tokens, in latency, and in the errors I have to catch.

The usual answer to this is retrieval, meaning better search, bigger context windows, and embeddings over everything, and I think that is the wrong shape of answer entirely. Retrieval returns documents, whereas what an agent needs is decisions and the reasons behind them, and almost nobody writes those down.

The pattern I borrowed

I did not invent any of this. Andrej Karpathy published an LLM wiki gist in April 2026 describing a compounding knowledge artifact, with raw sources at the bottom, markdown pages in the middle, and a schema file defining the structure. His line for it is that Obsidian is the IDE, the LLM is the programmer, and the wiki is the codebase. My first vault commit is 15 July 2026, three months later, so the pattern is his.

The mapping to what I actually run is close enough to be uncomfortable. Raw sources are Drive and my captures, the wiki is 150 markdown notes, and the schema is AI-CONTEXT.md plus three standards files defining required metadata, filenames, and how a task is written. His third operation is lint, a health check for contradictions, orphans, and stale claims, and mine is a shell script called validate.sh that has to print PASSED before anything gets committed, alongside a graph pipeline that counts orphaned notes on every commit.

Teach it once

The clearest proof of this is also the smallest one. I write in a particular way, using numbers instead of adjectives and never an em dash, and for months I explained that at the start of sessions, badly and inconsistently, and got back prose that was almost right. So I wrote it down once, as a file, with the measured evidence sitting behind each rule.

The session that built the site you are reading loaded that file, then went and found every em dash in my own site copy and removed them, which I never asked it to do. A file asked for it. That is the entire argument in one anecdote: the correction happened because the understanding was written where the agent would read it, rather than because I remembered to say it again.

Where I break from the pattern

Karpathy's version has the LLM writing and maintaining the wiki, and mine does not, which is the one place I deliberately disagree with him. The rule at the top of my vault is "AI proposes, humans decide," meaning nothing gets reorganized, renamed, reclassified, or rewritten without my approval, per change. The reason is narrow and I believe it: a wrongly-filed note is worse than an unfiled one because I will never find it again, since an unfiled note is visible mess and a confidently misfiled note is invisible loss. So the agent drafts, suggests, and validates, and it does not quietly reshape my thinking while I sleep. I took the architecture and left the autonomy.

The architecture in one breath

  • The vault is the git repository. Same directory, no sync plugin, no proprietary format.
  • CLAUDE.md is a pointer, not a copy. It links to the governing files rather than restating them, so the rules cannot drift from what the agent believes they are.
  • Decision records carry the reasoning, not just the outcome. An agent reading them inherits the why.
  • .aiignore marks protected original thinking as off limits, by path, without being asked.
  • Data lives in local SQLite stores outside git and outside every cloud-sync folder. The setup script refuses to create one under a synced path.
  • Six scheduled jobs run the boring parts: hourly snapshots, a morning journal, weekly backups.

What it actually costs

This works because I write the decision down at the moment I make it, and most people are not going to do that. Eight decision records exist because I stopped and wrote them, not because a tool generated them afterward.

The system also argues with me, which is the part I did not expect. One decision record is entirely a refusal. I asked for a large journal-automation build, and the answer, after it inspected the repo, was that the infrastructure I had assumed existed did not, so I should ship the smallest piece and gate the rest on evidence of real friction. The written rule ends with a line I have come to like, which is that if none of these bite after a few weeks, build nothing.

Where it is weak

The context layer works and the plumbing feeding it does not, at least not yet. Getting new material into the vault is still mostly a manual act, and hardening those ingest pipelines is the next real piece of work. The serving layer is missing too, since an MCP server that would let an agent read this from my phone is a planned project rather than a built one, which leaves the understanding written down, versioned, and stuck on one machine.

← all PersonalOS check-ins

more in this series