Theseus: a personal AI OS spread across a few machines
Since March 2026 I have been building an AI collaboration system for myself, alone. It is called Theseus. Lately the way I use it feels more and more like using a computer, except this computer is spread across several machines, and the processes running on it are agents from Claude Code, Codex, Kimi, and Hermes. This post writes the idea down as it is, which parts are already running and which are still just ideas. I also hope it helps me find people building similar things.
What is scarce is attention
A lot of my work now goes to agents, writing code, looking things up, running experiments, organizing documents, that kind of thing. Machines are not scarce, and neither are agents. What is scarce is my own attention (the first constraint in the Theseus vision document says exactly this, human attention is the scarcest resource in the system). So the way I want it to work is, I only say what needs to be done, and the system arranges which machine it runs on, what data to prepare, and how to hand the result back. Put simply, distributed computing, task dispatch, and data sync should be Theseus's own job.
Several machines as one
The current division of labor follows the memory hierarchy of a computer. The cloud server acts as RAM, fast but small, and it might go away someday, so a task loads what it needs and unloads when it is done. The home computer (Windows running WSL, with an RTX 3080) is the hard drive. Everything meant to be kept lives there, and the steps that need a GPU run there too. My laptop and the NAS sync both ways with one drive on the home computer over Syncthing, and finished pieces meant for me go into that drive, so I can open them on any device.
The machines reach each other over Tailscale (the detours along the way are in an earlier post, From self-hosted DERP to Peer Relay, in Chinese). Two rules are my own. Nothing unique may live only on the cloud server, and before anything there is unloaded, the home copy has to be checked complete. Bulk transfers only run from 1am to 7am (Beijing time), so they stay off the daytime bandwidth.
Next I want to bring the idle devices in. The Synology NAS at home runs nothing but Syncthing right now. I am considering flashing it to Linux and handing it to an agent to manage remotely, and there are a few old phones and old computers I am also trying to find work for.
Agents from a few vendors as processes
I run agents from several vendors at the same time, Claude Code, OpenAI's Codex, Kimi, and Hermes. They all read the same rules file (AGENTS.md), and each vendor's config entry is a symlink to that one file, so a rule change happens in one place. In daily use, one agent talks with me and does the design, and the time-consuming work (writing code, online research, long experiments) goes to other agents in the background. When a background job finishes it leaves a done marker, and the main agent checks the result after it sees the marker.
Subscription quota counts as compute here too (in the vision, the part in charge of compute is called drive, and cost is its job as well). On October 15 one subscription was about to reset, so I had an agent spin up 13 sub-agents in one go to work through the backlog, and they burned through the whole five-hour allowance in about twenty minutes.
Memory and gear
Every agent's conversation log goes into the same ledger (L1). A loop ingests new entries once a minute, and logs on other machines are pulled back over SSH and rsync. Original events are append-only, never edited. Conclusions worth keeping are written separately as long-term notes (L2), things like my user model, the system model, topic knowledge, and cross-project lessons. Every note has to cite raw events from the ledger, and without a citation the write is rejected. So if I switch agents, or switch to another vendor's model, it can still trace where each thing came from.
Capabilities live in a registry called armory, with skills, tools, MCP servers, and workflows all registered there. When one is needed, an enable command links it into the skill directories of the agent hosts, so Claude and Codex use the same copy. The system's own capabilities are CLI programs first, that is the authoritative copy, and a skill is a description generated from the CLI so the agent hosts can discover it. There is a diagram of the memory part on the Theseus project page.
Why it is called Theseus
The name comes from the Ship of Theseus. I think of one person solving problems with a group of agents as someone piloting a science-fiction Ship of Theseus through interstellar space, with parts being swapped all the time. Quite a few parts have been swapped in the past seven months or so. The agent framework changed (early this year it was OpenClaw, now it is the ones mentioned above), the code went through a round of refactoring, and in early October I archived everything not in use. Even the version of the interface I had built was pulled and sent back to the requirements stage to be thought through again.
What does not change is a few things I write myself, the vision document and a ledger of my own words. Only I can edit the vision document, and an agent that wants a change can only propose it. The ledger is append-only. The parts are named after a ship. The bridge is the human-machine interface, the drive handles compute and cost, comms handles talking to the outside, and the armory holds the gear.
I gave it a few rules. Before adding a new component, first answer what would happen without it. Components that fall out of use get archived, no dead code left behind. Whatever can live in one repository does not get scattered across the system, so it is easy to migrate and easy to understand.
What is not done yet
I call it an OS, but right now it is closer to a set of conventions plus a few programs. No program manages cross-machine dispatch yet, an agent just follows the rules and SSHes over itself. There is no device inventory in the system, nothing picks a machine based on GPU, network, or where the data is, and two machines editing the same thing are not coordinated either. The more established approach is a task queue with workers (Celery and the like), where the agent breaks my goal into tasks and judges whether the results are right, and queueing and moving are handed to deterministic programs. That path has not been started.
The other thing not done is the intent tree. When I work with agents, an intention is rarely a straight line. It forks as we go, jumps to something else, and comes back a while later. Right now this tree only lives in the conversation, and the small things that fork off often have nobody to close them out. I want the system to draw it, so I can always see which branch I am on, what the root is, and what is still unclosed. Beyond forking, switching, and merging, what other basic operations there should be, I have not figured out.
Looking for people to talk with
I wrote this mainly to find people building similar things. If you are also putting together a system like this for yourself, a few machines, a few agents, one shared memory, or if you are thinking about the questions below, you are welcome to email me. The address is on the about page.
- For task dispatch in a personal system, should it be rules, a queue, or agents negotiating among themselves?
- When several agents write into long-term memory together, how do you make sure the conclusions are trustworthy? Right now Theseus only checks whether a citation exists. It does not check whether the cited event is real, or whether it actually supports the conclusion.
- Has anyone built an intent tree, and what should the basic operations be?