Life OS is a personal operating system that runs on a Raspberry Pi, borrows a big model from my Mac, and doesn’t need a single cloud model call to do its job.
I hold three jobs’ worth of context in one head: a day job, a distillery, and a stack of software I build at night. Each comes with its own calendar, its own inbox, its own to-do list, and its own way of falling through the cracks.
The obvious fix is to hand all of it to a cloud assistant. I didn’t want to. Not because the cloud is evil, but because the most personal system I’ll ever build shouldn’t depend on someone else’s pricing page.
01 · The intent
One brain across my personal life and my build work, running on hardware I own. Personal and project work share the same loops, which is the whole point: it’s one system, not two apps pretending to talk to each other.
The build principles fit on an index card, and I wrote them down on day one:
- On-device, open-source first. If it can run on the Pi or the Mac, it does.
- Self-hosted on my own network when it can’t, reached privately and never exposed to the public internet.
- A free tier only if neither of those fits, with the trade-off called out.
- Paid or cloud as the last resort, and never picked silently.
The hardware split follows from one stubborn fact: the Pi is always awake and my Mac isn’t. So the Pi runs the orchestrator, the memory, and a small model for light work. Heavy reasoning goes to a 70B-class model on the Mac when it’s awake, and falls back to the Pi, with a note saying so, when it’s asleep.
One more rule, the one that matters most: the loops recommend; they never act. The morning briefing proposes a focus block and gives me a link to book it. Nothing lands on a calendar, goes out as an email, or gets published as knowledge until I say so.
editor: You built a personal assistant that refuses to do anything on its own.
author: I built one I’d trust with my calendar. Stet.
02 · The process
Life OS didn’t arrive as a steady trickle. It came in bursts, eight build days between July 6 and September 12, and each one added a layer.

July 6 and 7: the home base. The orchestrator, vector memory, and the daily loops landed on the Pi, with a deploy that pulls from git on a timer so I never have to log in to ship overnight. By the next day the dashboard was a phone-friendly web app, email replies could be edited and sent from it, and I could speak a note and have it transcribed, summarized, and filed in Notion with its action items as checkboxes.
July 25: my own work becomes a signal. Every Claude Code session I run leaves a memory behind. Life OS started reading those as ambient signal: what I keep asking for, what I keep deferring, what keeps breaking. It derives a backlog from them and proposes, once a week, what’s worth turning into knowledge.
August 9 and 14: the knowledge engine. This is the part I care about most, because it’s my day job paradigm pointed at my own life. Validated knowledge lives in a git repository, the system of record. The AI only ever sees a disposable copy of it in vector search. Between the two sits a human gate. Questions get answered with receipts from validated knowledge, or they get refused below a confidence floor, and every refusal becomes evidence of what to write next. Over those two days the capture side filled in: session memory distilled daily through the gate, merged pull requests as a capture trigger, and reject reason codes so a noisy trigger gets tuned instead of switched off.
The honest bits are in the commit log too. One fix is titled, in full, “Fix the session-end hook, which could never have worked.” Another discovered that the gap detector had been diligently finding gaps in the frozen demo corpus instead of my real one. Knowledge management has a phrase for that: measuring the wrong thing, very precisely.
September 2: the same loop, at work. I wrote a prompt kit that rebuilds the governed loop for Microsoft 365 Copilot, using the lists and libraries a Microsoft tenant actually has. So now I also have the same dashboard and capture structure running locally sandboxed on my work machine. The machinery changes; the rules carry over unchanged. AI proposes, a human disposes. Capture is ambient, curation is the job. Rejections are telemetry. Refusal over improvisation.
03 · The outcome
Here’s what a day with Life OS looks like. The morning briefing pulls three calendars (work, distillery, personal), the unread mail that needs a reply, and my open tasks, ranks the top three around the fixed blocks, names one thing to skip, and proposes a focus block. At midday it nudges me if I didn’t book it. On Sunday evening it sends a digest that opens with a momentum line, this week’s finished tasks against last week’s, and closes with the coming week’s actions, filed in Notion as checkboxes. In between, the dashboard on my phone is the home base, and the console at the bottom takes plain requests like “block 90 minutes for the distillery this evening.”
It also turned out to be the workbench for everything after it. The governed knowledge loop I proved here fed straight into a toolkit I’ve since packaged for other teams.
What I learned is mostly about restraint. The most useful thing a personal AI can do is read everything and change nothing until you ask. And a system you own outright, on hardware you own, earns a kind of trust a subscription never will: it can’t be repriced, retired, or quietly retrained out from under you.
So here’s the question I’d put to anyone eyeing an AI assistant for their life: which parts of it would you rent, and which parts would you rather own?
Transparency note: drafted with Claude from the LocalAgenticOS repository and its build principles, then read, cut, edited heavily, rewritten, and finally approved by me. As always: AI drafts, humans ship.
AI drafts, humans ship. This entry has been through the human.



You must be logged in to post a comment.