A personal AI computer
A personal assistant that runs continuously on my Mac. It handles incoming work, talks to me through Telegram, and can rewrite its own tools and code. I designed the system and directed its implementation using orchestrated coding agents, then operated the live tests myself.
- Role
- Designed the system and directed the build using coding agents
- Timeline
- September 2026 — ongoing; live since September 25
- Stack
- Rust, TypeScript, exo, Codex app-server, Claude Code, Apple containers, Telegram
- Status
- Running daily on a dedicated macOS account
The problem
I wanted to try an assistant that changes through use, rather than one whose tools I have to keep writing for it. The difficult part is letting it change itself while keeping the things I care about under my control: what it sends to people, what it can change, and how I stop or recover it.
What I built
The system is a fork of exo, with a small Rust kernel for approvals, usage limits and an append-only decision ledger. The agent can change its prompts, tools and learning machinery, but normal self-deploys are refused if they change kernel files. Messages to other people are held for approval unless I've explicitly delegated them in its charter; each approval is bound to the recipient and exact message.
A supervisor validates each proposed commit, deploys it, and watches a ten-minute probation window. If two turns fail, it rolls back. A separate reviewer predicts my reaction to drafts, and the system records my approvals, edits and reactions. It can also fork a past conversation and replay it under a different version to compare behavior.
I wrote the vision, briefing and design spec, made the governance decisions, and drove the implementation plan. The code was written by coding agents, with adversarial review and fix rounds. I brought it up on a dedicated account and ran the proofs through Telegram.
Results
All five live proofs passed on September 26. The agent added its own version-diagnostic tool, fixed a failed validation, deployed, and reported the new version in the same conversation. A deliberately broken update triggered automatic rollback. The other tests covered single-use approvals, refusal of a kernel change, and a fork-and-replay comparison.
From September 25 to October 1, it ran 225 governed turns. Of nine deployment attempts, four succeeded, four failed validation, and one kernel edit was refused; there was one automatic rollback. It also built read-only Gmail and Calendar adapters for itself.
Daily use has found failures the proofs didn't cover. A browser dependency install wedged a container and blocked the conversation for about fifteen hours. I added a turn deadline and fixed a leak where reviewer conversations kept their own running containers.
What I'd do differently
Using it every day has been the most useful test. It's already built tools I didn't give it, and a failed update can recover without losing the conversation. What I'd measure next is whether repeated work needs less correction from me. I'd also strengthen the isolation as I give it more responsibility; the current version is a personal experiment with a deliberate trust ceiling.