The organ as the unit of a personal AI system

Anyone building a personal system on a language model hits the same question within a week. The model knows nothing about you when a session starts, so what do you give it? The usual answers are a file of notes, a vector database, a folder of markdown, a set of tools. They all have one shape: the system is a pile of material and the model is the thing that acts.

Motivation

Two years of answering it that way, and every version failed identically, which is what told me the question was wrong rather than my answers.

The failure is freshness. Assemble the material, the model reads it, the answers are good. Three weeks later the answers are subtly worse and the model has not changed. 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 absent a component doing that job, it is you. The system is then exactly as fresh as your attention has been lately, and attention is the resource it was supposed to conserve.

The question assumes the material is inert, so every answer in its shape inherits the assumption. The better question is what could keep itself true without you, which is about components rather than about context.

First instance: the wiki

A wiki maintained by a small fleet of agents was the first thing I built that had the property. The part that mattered was not the writing. Every agent built afterwards could use it, because it was not a document I read but a component other systems could be pointed at, and pointing them at it made them better at their own jobs.

The generalisation is that the unit is not a wiki but an organ, carrying a coherent and densely connected view of one domain. The first version of that generalisation was wrong in a way worth keeping, because it described the organ as context for the model to load.

Organ as context. A folder the model reads. You keep it true.
Organ as component. A folder the model reads, plus its own maintenance and its own processing scripts. It does work when nobody is asking it anything.

Identical from the outside, and the difference is the whole design: who does the work of keeping the folder true. If it is you, you have written yourself into the runtime. An organ hands over context when something asks for it, which is a different thing from the organ itself.

Adjacent work: MCP

The obvious way to hand organs to a model is a tool protocol. MCP lets 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.

Follow a real request through it. Average strain from my last thirty workouts, compared against the weeks I actually meditated. Two lookups and a join.

The model calls the first tool. Thirty workouts of numbers land in the conversation.
It calls the second. A list of dates lands in the conversation.
It does the comparison in its head, from numbers it has just read.

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

Type the same request at a shell and neither problem exists, because a shell has two things this protocol does not:

a pipe, written |, which hands one program's output straight to the next without you ever seeing it
a variable, which parks a result under a name so you can use it again later

Both are ordinary enough that nobody lists them as features, and both are exactly what was missing. A hundred tools is a menu, ordered from one item at a time. A system is the 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 is work spent arriving where you already are.

Functions, organs, and systems

The shell answers where intermediate results go and leaves the harder half open: what a program is here, how big one should be, and what it is allowed to touch. Three questions, three levels, borrowed from unix on one side and anatomy on the other because both had already been made to answer them.

A function is one operation that does one thing. Check a habit. Read today's strain. Append a line to the log. Small, stateless, reads or writes one piece of data. Useful alone, not intelligent.

An organ is a group of functions serving one domain. The load-bearing property is that it owns its own state and reaches into nobody else's, so 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:

Organ	Domain	State
`habits`	behaviour tracking	SQLite
`health`	body data	a third-party API
`finance`	money	a banking API
`korean`	learning	markdown lesson files
`write`	prose quality	stateless, it only lints and analyses
`memory`	world model	a hosted temporal knowledge graph
`social`	relationships	SQLite plus markdown files per person
`macrostates`	goals	markdown in folders that encode status

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 stateless one proves the pattern is not 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. Four questions to four storage systems that know nothing about each other:

health, how well I recovered overnight
habits, what I have and have not done this week
finance, what has left the account
macrostates, what I said I was trying to achieve

Together they say something none of them can say alone: a poor recovery score is a number; the same score on the fourth missed workout of a week I said I would train hard is the week coming apart.

Organs are separate so each can be correct on its own, which means every interesting reading exists only across them. What makes reading across cheap is that it is a prompt rather than a program. Adding a system costs a paragraph of instructions and a handful of organ calls, which is short enough that I will write it on a morning when I would not have opened an editor.

The omission is the model, which is not an organ, because it owns no state and 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.

Biology	Unix	ai-organs
Cell function	a command like grep or awk	a function like habits check
Organ	a program like git or curl	an organ like organs habits
Organ system	a pipeline of programs	a system like the morning briefing
Organism	a shell session	an agent session
Nervous system	the shell itself	the AI agent

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. Worse in every mechanical respect, better in the one that matters, because it can decide.

The table names the levels and says nothing about what they should be built out of. That is the question I had been getting wrong for two years, by answering it with a kernel.

Composing on Unix

The line that licensed the rebuild 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.

Claude Code is the shell.
The organs CLI is the system calls.
iCloud is the filesystem.

A system call here is one organ's command surface, small enough to show whole:

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, small enough that the agent composing it never has to be told how it works.

Nothing in the substrate was written for this purpose. Claude Code is a coding tool, iCloud is consumer file sync, SQLite ships inside everything. The whole system is markdown, SQLite, command line tools and an agent, none of which I had to design.

The two years before it went into designing kernels. My architecture document for a personal operating system specified four things:

a kernel context
a user context
a process message interface
scoped databases per process

Those are services an operating system already provides, specified by someone typing on a machine that was providing them. Specifying them is how I found out which ones I needed; building them would have rebuilt the substrate underneath the one I was working on, the same composition error as replacing the shell with a tool protocol.

The daily protocol

A personal system does not usually fail by being wrong. It fails by not running, and the mechanism is not laziness.

Every organ has some part only a person can supply. Nobody but me knows I trained today, or what I ate, or that the thing I called the goal last week has quietly stopped being it. When those inputs arrive irregularly the organs are not merely missing data, they are confidently wrong:

a habit with no check mark and a habit that was genuinely skipped look identical from the inside
so do 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 make that number small enough that I hit it on a bad day. Two: morning and evening, with everything between them scripted or running on its own.

Two is not chosen because two is enough information. It is the largest number I will 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

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

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 did not have to change to accommodate any of it. Being right about how a system composes says nothing about where a person is supposed to look at it.