Why I built a personal operating system

If you've read the About page, you'll have seen the line about building "a personal operating system, to find out" what AI changes for products, teams and the way we work. This is the longer version of that sentence.

I call it RafeOS. The name is a bit grand for what it is, but it makes people smile. Underneath, it's one platform, best described as agentic-first, that reads and (carefully) acts on my own data: tasks, calendar and email, health, messages, reading, the flat (home), and various information statuses (transport, weather). I tend to think in layers, so the whole thing is RafeOS but it divides cleanly into parts of an ecosystem, the modules sitting behind one API, one set of small tools, one command-line dispatcher, and so on. I can reach the same system from my laptop, my phone, a chat window, or an agent running on a server.

The shape of it: how I reach it, the platform, the data it draws on, and the borrowed foundations underneath. Fuller tour in What RafeOS is.

Two reasons I keep building it

The first is that I wanted to understand the agentic edge from the inside, not from the demos. Much of what's written about agents right now is either breathless (we're deep within the hype cycle) or dismissive. I'm more interested in the lived version: when you point capable agents at your own data and workflows, with real stakes (my actual calendar, my actual health), what genuinely changes about how you work, live and think? What's useful, what's theatre, and what quietly becomes a habit you'd miss? Living with a second brain and a deliberate agentic layer has really brought home the potential... it's a little unnerving what is and will possible... and I think I'm only scraping the surface,

The second is more about the how, or the next version of it. I've spent years doing and leading transformation, innovation, product and engineering (teams) in various guises, and I know collaborative and coexistent AI is already reshaping how software and services get built. It's not just the coding, but the whole lifecycle, from discovery (why) and requirements + use cases (what) through to the design and build, testing, and deployment (how). I wanted somewhere I could run that end-to-end myself, experimenting and trying different things, with fewer constraints. RafeOS, and its connected pieces, is that somewhere. It lets me get a different hands-on perspective on what the future of product, design, and engineering might look like.

And honestly, it's only practical now. Agentic-led or assisted work is what makes it sensible to build something for an audience of one; RafeOS wouldn't exist a couple of years ago, if I had to design and write every line myself. The what and the why are still mine. The how is increasingly the agent's, and the division across all of these is turning out to be most of the point. Critically, it also highlights the current limits and the new failure modes (and some not so new ones).

So RafeOS is two things at once: a system I genuinely use, and a lab. Most of what follows is the system. The lab is where the next few posts go.

What's actually different about it

It would be easy to call RafeOS a second brain: context and memory, a knowledge wiki, session logs, a collection of skills, all compounding as you feed them. That part is real and useful. But this is almost a commodity layer now; anyone who's used Claude Cowork, spent a fortnight with an agentic harness, or set up something like OpenClaw or Hermes, has felt it. This is still an important layer and is a huge productivity boost in itself, but I think there are two things that matter more.

The first is a consistent set of custom tools that work across every surface. Some interrogate Gmail and Google Workspace, a bit like the off-the-shelf connectors but customised. Some hook into health: Oura, Withings, Apple Health. Some I wrote from scratch, like the ones for reading and tasks. The point is they're the same tools whether I'm in a chat window, on the command line, or letting an agent loose on a job, so the data and the context follow me around instead of being trapped in whichever app I happened to open.

The second is handing classification and the small decisions to the reasoning itself. A lot of what RafeOS does is let a model do the filtering: these are the messages worth a reply, these the tasks to pay attention to, this the status that matters today. The benefit is that it decides what's worth my attention, so my attention goes to the work that actually needs me.

None of this is exotic engineering. When I say I'm building RafeOS, what I'm mostly doing is connecting things together: gluing my data and context to a model's reasoning, then choosing how it surfaces, whether that's a chat, a briefing in my inbox, or a sensible call about what to float to the top of a dashboard. I don't self-host or rebuild everything either; the dashboard deep-links straight out to existing apps I use that already do a given job well; I'll use existing services, connectors, or MCPs where it makes sense to do so; and I'm standing on the shoulders of a lot of prior art and open source software. Partly this is a reflection of the jagged frontier, but it's also that I just want something that works.

Is this all just agents? It's the obvious question, and the answer is no, which is the point. Some of what gets called an "agent" now is a markdown file that springs to life when you ask it something in Claude or ChatGPT, or when a scheduled job pokes it. RafeOS has some of that. But it's one band on a wider spectrum: from a plain passthrough (just showing the data), through automation (deterministic rules, no model), through fixed workflows (a model running a set of known steps), to genuine agents (handed a goal, working out the steps themselves). Which band a job sits in matters less than the fact they all draw on the same platform underneath: the shared tools, the memory, the audit trail. The agents are the visible bit; the platform is the personalisation and the multiplier.

There are places where I'm less advanced. I lean lighter on elaborate multi-step workflows than some do. And there are people running far more sophisticated memory than I am (proper vector databases over thousands of their own documents).

One substrate, many surfaces

The design decision I'd defend hardest is that as much as possible runs on a single substrate, reachable from wherever I happen to be thinking:

• The Cockpit, a web app for the at-a-glance view and a traditional front end for some modules.
• The command line, via terminal, for the fast, no-ceremony stuff. rafeos tasks add "call HMRC" and it's captured.
• Claude Code and other agentic harnesses, via direct API and skills, calling the same tools while doing technical work, including work on the system itself.
• Claude Cowork, via an MCP connector, when I'm working with files or knowledge projects.
• A normal chat window, same connector, for when I just want to ask
• Telegram, Signal or WhatsApp, so I can reach the system, and it can reach me on the go.

The point isn't the list. It's that these are all front doors onto the same context, data, and capabilities, with one way to authenticate and one record of who did what. That's a systems-thinking habit more than a technical one: build the shared thing once, then let the surfaces be cheap. Adding a new way in shouldn't mean rebuilding the engine.

Living with all those doors, I've found they do three different jobs. The app is for the glance (is everything roughly fine?) and quick human actions. The chat/agentic harness is for the deeper work (help me think this through, help me create this). The briefing and the alerts are the push, the thing that comes to me unasked, because waiting to be asked is its own kind of friction. More often than I expected, the best version of RafeOS is the one that asks the least of me. It's at its best when it's close to invisible.

This is also part of a very deliberate composable approach here: breaking the system into independent, reusable, and modular components. Things, including the foundational models, can be swapped out, but it also applies to the surfaces.

Automate, then show or alert on the exception

One habit runs through the whole system: do as much as possible automatically, and only interrupt me when something is out of the ordinary. These are a kind of loops, though perhaps not the buzzworthy kind.

I learned it most clearly from the part of my setup that predates RafeOS, the smart home. Home Assistant has run for years (lights, presence, security) and I rarely open it. Where it earns its keep is the exception: during a heatwave it nudges me to draw the curtains to keep the heat out; electricity usage is time-shifted to the cheapest rates automatically; and it reminds me if I have left the window open. The normal stays silent; the unusual surfaces. That's the same shape as the messaging triage telling me which five emails actually need me, or the briefing floating a Tube delay because it knows I'm about to head out. The goal was never more dashboards to check. It's less checking.

The jagged edge

The gap between the demo and the lived version is where the useful learning is. RafeOS is alpha. It's brilliant in places, flaky in others, and the line between the two isn't always where you'd expect. Some of that is the technology still maturing. A lot of it is me: handing an agent something you've done by hand for years is a behaviour change, and behaviour change runs on trust. You have to learn when to hand over and when to check, and the system earns that by being coherent often enough that you stop double-checking.

It gets things confidently wrong, too. Early on the briefing welded a health reading to an unrelated calendar entry and delivered the nonsense with the same calm assurance as everything useful it says. The fix wasn't a cleverer model; it was a firm rule about what it's allowed to connect and taking into account confidence levels when presenting information. Most of the engineering, it turns out, is fences.

What it deliberately doesn't do

A word on restraint, because it's so easy to skip. RafeOS has an explicit list of things it will not do: no sending messages on my behalf, no sub-task hierarchies, no multi-user anything. Every "no" has a reason written next to it. That discipline matters more as a system grows, not less. The temptation with a project like this is to make it do everything; the skill is deciding what it shouldn't touch and holding the line. Knowing what to leave out, what to remove after experimentation, is the part of this that most resembles my day-to-day job decision making.

Owning it

There's a quieter reason, too, and it's grown on me. The more of your life runs through a system like this, the more it matters who holds the data. Building my own tools, on my own infrastructure, keeps my messages, my health, my reading mine: queryable by an agent that works for me, not sitting in someone else's product to be mined, priced or discontinued. I don't self-host everything. But for the personal, sensitive core, ownership is an attractor, and that pull towards self-hosting is as much about privacy and control as anything technical.

What comes next

Building a personal project, from the ground up, has given me a real point of view on the two questions I actually care about: what the agentic edge does to the way we work, and what AI-native product building looks like across the whole lifecycle.

The next few posts go deeper: the platform decisions, the messaging layer, the self-running tasks, the health view, the Cockpit, how it decides what's worth reading, the memory it all runs on, and the two bigger arguments about agents and engineering.

And of course there's a backlog too and more experiments to run!

On how this was made: RafeOS is built collaboratively with AI, and so was this post. That feels like the honest thing to say, given the subject. Every post here carries a label for exactly this reason.