The operating system I built for myself

I run a portfolio of projects — a live directory, client work, internal tools, a learning system — as one person, alongside a job. AI makes it possible to start almost anything in an afternoon. That is exactly the problem.

The constraint on a solo operator was never capability. It's attention, focus, and finishing. AI removes the friction that used to ration what I started — and without a governing layer, "I can build anything" quietly becomes "I have eleven half-built things and no proof of any of them." So the first system I built wasn't a product. It was a set of rules for deciding what I'm allowed to work on, and a discipline for closing the loop on each thing before opening the next.

This is a write-up of that system. I'm going to foreground the judgement — what I deliberately constrained, what I refused to automate, and the trade-offs I made — because the mechanics are the easy part and the reasoning is the point.

The core bet: govern attention, not tasks

Most "productivity systems" track tasks. This one governs attention. The central rule is a hard cap: one primary build, one secondary maintenance stream, one exploration thread. Nothing else is "active." Everything else is captured and parked.

That cap is uncomfortable on purpose. The whole point is that it forces a decision: for a new thing to become active, it has to consciously displace something already active, fix a real blocker, or be genuinely urgent. "It's interesting" is not enough. Capture creates memory, not permission.

The thing I had to design against was my own enthusiasm. The system assumes the operator will generate more good ideas than can ever be shipped, and that the failure mode isn't a shortage of ideas — it's diluting effort across too many. So ideas move through a deliberate lifecycle — captured → parked → incubating → committed → active → closed — and nothing skips straight to active in the same session it was thought of. The friction is the feature.

What I deliberately did not build

The clearest signal of judgement is the list of things I chose not to do.

• No auto-promotion of ideas. The system could suggest what to work on next. I deliberately kept the promotion decision manual and gated. Automating it would optimise for momentum, and momentum is the thing I most needed to resist.
• No "do everything" assistant. AI is wired in at specific, bounded points — a retrieval system over my own notes, a triage step for incoming documents, structured advisory skills — not as an always-on agent with broad write access. Narrow, auditable, reversible.
• Nothing sensitive leaves the building. The genuinely useful information — personal records, finances, client material — lives in collections that are local-only by design and never committed to any remote. The architecture enforces that boundary; it isn't a habit I hope to keep.
• No productising before proof. There's a standing rule that planning is not proof. Proof is code deployed, content published, a decision documented, a feature working. A beautiful plan counts for nothing until something ships.

Each of those is a place where the powerful, tempting move was the wrong one. The system exists to make the restrained move the default.

How AI is actually used — and constrained

AI appears in the system in a few deliberate shapes:

• Retrieval over my own corpus. A RAG system answers questions from my actual workspace — governance state, past decisions, project notes — with citations back to the source files. It was built and tuned against a measured evaluation set, so retrieval quality is a number I can watch, not a vibe.
• A triage gate for incoming material, with sensitivity rules that are hard-enforced: high-sensitivity material never auto-routes anywhere it could leak; everything is propose-then-approve.
• A pipeline of structured advisory skills — strategy, finance, technical, distribution, legal — that I can convene like a panel when a decision needs more than one lens.

The common thread: AI is given the narrowest useful scope, its outputs are drafts a human approves, and anywhere a mistake would be expensive or irreversible, a person stays in the loop. The capability is impressive; the discipline is in refusing to let it act unsupervised where it matters.

The review rhythm that keeps it honest

A system that governs attention has to review itself or it rots. So every working session opens by loading the current state and surfacing the last session's unfinished threads, and closes by detecting drift (did I do what I framed, or wander?), capturing what I learned, and recording a clean stop point and a re-entry point for next time. Weekly, there's a forced subtraction — what should be killed or parked — because the natural drift of any portfolio is to accumulate.

There are explicit escalation triggers, too: more than three active fronts, no shipped proof for a week, a parking lot growing unchecked, strategic decisions made while tired or over-activated. When one fires, it's a signal to review the system's design — not a reason to push harder. Resentful over-effort is a signal to review the design, not proof of virtue.

Why this is the most senior thing I've built

It would be more impressive-sounding to lead with the AI tooling. But anyone can wire up a model now. The harder, rarer thing is operational judgement: knowing that the binding constraint is attention, that the dangerous failure mode is over-expansion, that the right response to "AI lets me build anything" is more discipline rather than less — and then building the system that enforces it on yourself.

That's the same judgement a business needs when it brings AI near its real operations. The question is almost never "can we build it." It's "should we, where exactly, with what constraints, and who stays in the loop." This system is me answering that question for my own operation, in code, with the constraints designed in from the start.