42,735
messages cleared from my own inbox, with a receipt for each batch
// engineering_case_study
An agentic AI operating system I designed, built and deployed on my own, in daily use since April 2026.
Counted from the repository on October 19, 2026. Lines and programs exclude 256 test files. Commits include notes as well as code.
// 01 the_problem
The demo is impressive, everyone agrees it's the future, and then nothing reaches anybody's Tuesday.
The hard part was never the model. It's the eighty percent that comes after. The data is scattered across a dozen services that don't talk. The useful action is the one nobody will let software take unsupervised. And the person who'd benefit most is the one least willing to learn a new tool.
MojoOS is my answer to that, built for the hardest possible user: me, with no patience for anything that doesn't earn its place by the end of the week. It is not a proof of concept. Every piece of it went into daily use or got deleted.
// 02 architecture
Sources sit behind one interface instead of being wired to each other, so adding a service is one server, not a new connection to every other one.
// 03 governance
The system can read a calendar, a mailbox and years of message history. So the interesting engineering question was what must it never be able to do, and how to enforce that in code rather than in a prompt.
Outbound channels are classified by how reversible they are. Email, the most permanent, can only produce a draft through my own mail server. That rule lives in the server, so it holds even if every instruction above it is ignored. Every other send passes through a guard that logs it before it runs.
Per-channel filters strip private context from anything leaving the system, and adversarial tests actively try to smuggle content past them.
Permission configs are hashed and checked every day. A guard that can quietly switch itself off is worse than no guard, so a mismatch raises a blocker, not a log line.
Credentials live only in environment variables outside the repository. They never enter the knowledge base, and a pre-execution hook blocks shell commands that would print them.
// 04 quality
An integration that keeps returning plausible, stale answers after the platform underneath it changed is worse than one that crashes, because nothing looks wrong.
A probe suite runs twice a day. When a failure is confirmed and code can check for it, it becomes a permanent probe, so that mistake can't come back unnoticed. 70 of the 150 trace to a specific logged miss. The registry can grow or hold. It can't shrink without a dated reason.
For the interfaces that have already failed silently once, standing checks read a known-recent record and assert its shape still holds. That is the fix for the message-reader failure above.
An LLM-as-judge layer scores generated drafts against a hand-labeled golden set. It is advisory on purpose: it flags, it never rewrites.
20 runtime hooks run around every action. Some block unsafe actions outright; the rest log and audit. The principle: anything that relies on the model remembering to behave eventually won't.
// 05 what_it_runs
The piece I'd point at first is a daily brief that sweeps mail, calendar, tasks and message history live at the moment it's written, never from a cached snapshot. It surfaces what's owed, what's going stale, and what needs a decision. Its whole job is to be useful to a non-technical person before their first coffee. Everything else is plumbing in service of it.
One example of that plumbing is inbox triage. It decides by sender, not by message. Cheap rules settle most senders. A model judges only the ones the rules can't. A human approves the groups, and every override is logged so the next pass learns from it.
// 06 first_client
KNKY Comedy is the live comedy company I started: five platforms, none of them talking to each other. One morning the system flagged a show that had come in far below its own average. It pointed to two likely causes nobody had connected to it. Our paid ads had been off since April. And our emails had drifted from early warm-ups to day-of blasts. It told me to restart the ads and rebuild the early emails.
The same analysis found that one ticket tier, VIP, brought in 32% of our LA revenue from about 14% of tickets, and we were barely promoting it.
// 07 stack
// walkthrough
I'm happy to walk you through the architecture and the evaluation layer in 20 minutes.
[email protected]