The organ as the unit of a personal AI system

Anyone who builds a personal system on top of a language model arrives at the same question within a week. The model knows nothing about you when a session starts, so what do you give it? People answer with a file of notes, a vector database, a folder of markdown, a set of tools. All of those answers have the same shape, which is that the system is a pile of material and the model is the thing that does the work.

Motivation

I spent two years answering the question that way, and every version failed in the same specific way, which is what eventually told me the question was wrong rather than my answers.

The failure is always freshness. You assemble the material, the model reads it, and the answers are good. Three weeks later the answers are subtly worse, and the reason is never that the model got worse. It is that a fact in the pile stopped being true and nothing noticed. A pile has no opinion about its own accuracy. Whatever keeps it current has to live outside it, and if you have not built that thing then it is you, which means the system is exactly as fresh as your attention has been lately, and attention is the resource the system was supposed to be conserving.

So the question "what do I give the model" quietly assumes the material is inert and the model is the only part that acts. Every answer in that shape inherits the assumption. Once you notice it, the interesting question is not what to hand over but what could keep itself true without you, and that is a question about components rather than about context.

First instance: the wiki

In November 2025 I built a wiki that a small fleet of agents maintains. It works, and the thing that struck me afterwards was not the writing. It was that every agent I built subsequently could use it. The wiki was not a document I read. It was a component that other systems could be pointed at, and pointing them at it made them better at their own jobs.

On the morning of 10 January 2026 I tried to say what it was an example of. It took about eight minutes. I started with the wiki, pushed past it to whatever the wiki was an instance of, and landed on a phrase: what I wanted was not more wikis but actor-interface organs, where the wiki is the organ carrying a coherent, densely connected view of how things work, and the question worth asking is what the other organs are.

Seventy-two seconds later I had to correct the answer I got back, which had described the organ as context for the model to load. That is not what an organ is. An organ has its own maintenance and its own processing scripts. It does work when nobody is asking it anything.

That distinction is the whole design and it is easy to miss because both versions look identical from the outside. Both are a folder the model can read. The difference is who does the work of keeping the folder true. If the answer is you, then you have written yourself into the runtime, and the system decays exactly as fast as your attention does. If the organ maintains itself, you have a component. Context is what an organ hands over when asked. It is not what the organ is.

Adjacent work: MCP

The obvious way to hand organs to a model is a tool protocol. The one everybody was using is called MCP, and what it does is let a model call functions you have written: you register a list of them, the model picks one, it runs, and the result comes back into the conversation.

Take a real request and follow it through. I want the average strain from my last thirty workouts compared against the weeks I actually meditated. That is two lookups and a join. With tools, the model calls the first one, and thirty workouts of numbers come back and land in the conversation. It calls the second, and a list of dates lands in the conversation. Then it does the comparison itself, in its head, from numbers it has just read.

Every intermediate result has to pass through the model's reading, because there is nowhere else to put it. Which means a big result costs you a big read, and a result you want twice costs you two.

Type the same request at a shell and neither problem exists, because a shell gives you two things this protocol does not. The first is a pipe, written |, which hands one program's output straight to the next program without you ever seeing it. The second is a variable, which parks a result under a name so you can use it again later. Both are so ordinary that nobody lists them as features, and both are exactly what was missing.

That is why a hundred tools feel like a menu rather than a system. A menu is a list of things you order one at a time. A system is a set of things you can wire to each other.

So the problem was never capability, where the fix is more tools. It was composition, where the fix is somewhere to put an intermediate result. Which is uncomfortable, because a thing with pipes and variables and a filesystem was already sitting on the laptop, and building a protocol to replace it would have been work spent arriving where I already was. It took me two more months to act on that.

Functions, organs, and systems

The taxonomy the repository runs on has three levels and one deliberate omission.

A function is one operation that does one thing. Check a habit. Read today's strain. Append a line to the log. Functions are small and stateless, they read or write one piece of data, and on their own they are useful but not intelligent.

An organ is a group of functions serving one domain, and the load-bearing property is that it owns its own state. No organ reaches into another organ's storage, which means each one can be repaired, replaced, or reasoned about without the others. A liver does not need a heart to filter blood, and the organism needs both.

The state column is where the design shows. Eight organs, and no two of them store anything the same way:

Nothing enforces that variety and nothing should. Each organ picked whatever fits its domain, and because none of them share a store, none of those choices constrains any other. The one that is stateless is the proof the pattern is not really about storage: write is an organ because it owns a domain and exposes an interface, not because it owns a database.

A system is what you get when organs are read together, and it is where the useful part lives.

The morning briefing is the simplest one, so follow what it actually does. It asks health how well I recovered overnight, asks habits what I have and have not done this week, asks finance what has left the account, and asks macrostates what I said I was trying to achieve. Four answers, four different storage systems, none of which know about each other. Then it puts them in one paragraph, and the paragraph says something none of the four could say alone, because a bad recovery score is a number, and a bad recovery score on the fourth missed workout of a week I said I would train hard is a situation.

That is the whole trick and it is not a technical one. The organs are separate so each can be correct on its own, and the interesting readings only exist across them, so something has to do the reading across. What makes it cheap is that the something is a prompt rather than a program. A system here is a paragraph of instructions and a handful of organ calls, so adding one costs a paragraph, and a paragraph is short enough that I will write it on a morning when I would not have opened an editor.

The omission is the model. The AI is not an organ. It owns no state and it does not do one thing. It reads from every organ, composes them, and decides what to do next, which in a shell is the job of the shell. The parallel is exact enough to be worth writing out.

In unix the pipe is a character you type. Here the pipe is the model, which reads the output of one organ and decides what to feed the next. That is a worse pipe in every mechanical respect and a better one in the respect that matters, because it can decide.

Composing on Unix

The rebuild that produced all of this happened in one long session across 18 and 19 March 2026, and the line that licensed it was that Linux had already solved these problems. An operating system for a person is not something to build from scratch. It is something to compose on top of what exists.

So Claude Code became the shell, the organs CLI became the system calls, and iCloud became the filesystem. One organ's surface, in full, to show what a system call looks like here:

organs habits check "Meditate"                # check today
organs habits check "Exercise" -n "Ran 5km"   # check with a note
organs habits check "Exercise" -d 2026-03-17  # backfill a past day
organs habits uncheck "Exercise"              # undo

organs habits day                             # today's status
organs habits week                            # Mon to Sun grid
organs habits grid                            # six-month heatmap
organs habits stats                           # streaks, rates, day-of-week

organs habits add "New Habit" -d "description"
organs habits archive "Old Habit"

Two verbs to write, several to read at different resolutions, two to manage the set. That is the whole organ, and it is small enough that the agent composing it never has to be told how it works. Nothing in that list was written for the purpose. Claude Code is a coding tool, iCloud is consumer file sync, and SQLite is a database that ships inside everything. The proof that the composition was the right move is that the whole system came together in one session out of markdown, SQLite, command line tools, and an agent, none of which I had to design.

I had spent the previous two years designing kernels. In 2024 I wrote an architecture document for a personal operating system with a kernel context, a user context, a process message interface, and scoped databases per process. It was a good document. What it needed was a runtime, and the runtime turned out to be a laptop.

The daily protocol

A personal system does not usually fail by being wrong. It fails by not running, and the way that happens is worth being exact about, because it is not laziness.

Every organ here has some part only a person can supply. Nobody but me knows I trained today, or what I ate, or that the thing I said last week was the goal has quietly stopped being the goal. If those inputs arrive irregularly, the organs are not merely missing data. They are confidently wrong, because a habit with no check mark and a habit that was genuinely skipped look identical from the inside, and so does a goal I have abandoned and a goal I am behind on. A system built on irregular self-report degrades into one that reports on my logging rather than on my life.

The fix is not to log more. It is to fix how many times a day the system needs a person at all, and then make that number small enough that I will hit it on a bad day. I settled on two, morning and evening, and everything between those points is either scripted or runs on its own. Two is not chosen because two is enough information. It is chosen because two is the largest number I will actually clear in a week where everything goes wrong, and a system that runs on the bad weeks is worth more than one that is richer on the good ones.

The user interface

Three days after the architecture was written down I built a text interface for it, and the reason is worth admitting. Describing Claude Code as the shell is architecturally correct and useless as a place to look. You cannot glance at a shell. A person wants to see the day, the habits, the strain, the balance, and the log without composing a question first.

So there is a left rail of views, a main panel, an activity feed, glance metrics on the right, and a command bar at the bottom where typing plain text appends it to the day's log. That default is the part I like most, because the cheapest possible interaction with the system is also the one it most needs you to do.

The architecture was right. The surface was missing, and those are different problems.