Systems
How I think about building them
Editorial write-ups of the systems behind the work — what was deliberately avoided, where AI was constrained, the trade-offs made. The reasoning is the point, not the feature list. More of these get published over time.
How I work with AI
Not "an AI assistant" — a set of narrow, auditable tools wired into how the work already runs.
I've built 27 custom AI tools into my own working environment. The interesting part is how constrained they are: each has a narrow job, a human approves anything that matters, and the powerful-but-risky moves are the ones I deliberately designed out. This is the overview — each system has its own write-up.
The operating system I built for myself
A governance layer that decides what I'm allowed to work on — and the reasoning behind every constraint in it.
I built a single-operator "operating system" for running a portfolio of projects with AI. The interesting part isn't the tooling — it's the rules I gave myself to stop the tooling from making everything worse.
A system that knows who it's for
Nothing here is built for its own sake, and none of it assumes an ideal user. Every piece has to earn its place — and the guardrails are shaped around how I actually work, including the ways I get it wrong.
Two rules run underneath everything. First: nothing gets built for the feeling of building — every piece has to produce something useful or it doesn't get made. Second: the system is tuned to its operator, not a fantasy version — it plans for low energy, counters my tendency to over-build, holds big decisions when I'm in a bad state to make them, and talks to me in plain English because that's how I think.
Three kinds of memory, kept deliberately apart
How the whole memory picture fits — an operational memory that informs each session, a workshop I can query, and a durable Obsidian library — and why they're separate.
Most "AI memory" is one undifferentiated bucket. I run three: an operational memory recalled before I act, a time-bound workshop I can ask questions of, and a durable Obsidian library of concepts that lasts. Each has a different job, lifespan, and level of trust — and the boundaries between them are the design. This is the map; the deep-dives sit underneath.
Keeping what I learn
A two-layer knowledge system — a workshop for doing the work, a library for what lasts — and a memory that survives between sessions.
I separated the place where work happens from the place where durable knowledge lives, with a deliberate promotion step between them. The judgement is in the boundary: most notes are disposable, a few are permanent, and conflating the two is how knowledge systems rot.
Giving AI a memory that lasts
A persistent, inspectable memory across AI sessions — one fact per file, consulted before acting, and trusted only as far as it's verified.
Most AI forgets everything between sessions. I built a small, file-based memory layer that persists what matters about how I work — and, just as importantly, a discipline for treating what it remembers as background to verify, not orders to follow.
Making podcasts and courses compound, not evaporate
A learning system that turns passive listening, reading and courses into structured records — separating what I learned from the ideas it sparked, and scoring the result against real evidence.
Most of what you take in from a podcast or article is gone within a day. I built a pipeline that turns each one into a structured record on a single schema, keeps 'what I learned' apart from 'the ideas it sparked', synthesises across them, and feeds an evidence-scored skills matrix — so exposure compounds into capability I can actually point to.
The routines that make the rules stick
Governance only works if something runs it — so the rules are encoded as routines: every session is bracketed by a frame and a review, a weekly cadence promotes and escalates, and recurring work lives in small single-purpose skills.
A set of rules you have to remember to apply is just good intentions. So I turned the governance into routines that fire at fixed moments — a frame at the start of every session, a review at the end, a weekly promotion-and-escalation pass, and recurring work codified as narrow, auditable skills. The discipline runs on routine, not willpower; the judgement stays with me.
The weekly review that's allowed to say no
Most systems only ever add. Once a week I run the opposite — a standing appointment to demote, park and kill, and to check the week's reality against what I claimed I'd do.
A weekly review is the scheduled subtraction pass: it checks proof-of-progress, enforces the limit on active work, promotes what proved durable, and escalates when the warning signs show. The hard part isn't the checklist — it's removing things I'm attached to, on a cadence so it actually happens.
A triage gate for everything coming in
One folder on the desktop, and a filing clerk that asks how sensitive a thing is before it asks what it is — and never moves anything without approval.
I built a single drop-folder on my desktop with an AI triage step behind it. The design choice that matters: it sorts by sensitivity first, refuses to auto-route anything confidential, and never files anything without showing me the plan first.
The Diagnostic Lab
Thinking a decision through from six angles at once — a chain of narrow specialist advisors that argue a business idea from different lenses, and deliberately don't merge into one comfortable answer.
I built a diagnostic pipeline that runs an idea past a sequence of specialist advisors — research, a five-voice debate, finance, technical, distribution, legal, customer-experience — and compiles a verdict. The design choice that matters: the advisors stay separate so their disagreement survives, and a person makes the actual call.
A read-only window over the whole operation
A static dashboard assembled from the workspace and run only on my own machine — one pane over projects, ideas, memory and more, with a chat tab that answers from my own material. It can read everything and change nothing.
I built a dashboard that pulls the whole operator system into one view. The design choices that matter: it's read-only by construction (it can't alter what it shows), it's regenerated from source rather than kept as a second copy to drift, and it runs only on my machine — because what it displays is real client and personal material. I'm describing it rather than showing it, for exactly that reason.
How this site updates itself
This site isn't a brochure maintained on the side — it's an output surface of the same operating system it describes, run by the same rules: drop a file and it's a page, promote a piece with one command, and a weekly pass keeps it honest.
Adding a page here is a one-file change; a /promote command turns a workspace artefact into a guardrailed page; a sync step reconciles the live numbers with their source; and every push deploys itself. It's deliberately not fully automatic — the editorial and privacy gates are the point — but drift has a scheduled catch.
A high bar, not a schedule
I started a publication and built the brakes in first: a gate whose default answer is 'no', a cadence that waits for something worth saying, and a definition of success that ignores the subscriber count.
I run a point-of-view publication on operating AI-first. The part worth explaining isn't the writing — it's the gate in front of it: four tests a piece has to pass to earn a post, a rhythm set by having something to say rather than a calendar, and a measure of success that's about who can be sent a link, not how many people subscribed.
Assume the input is hostile
Before trusting my own agents, I attacked them — then hardened every skill that reads text I don't control. The boundary that matters isn't the skill; it's where the words come from.
I ran a prompt-injection red-team against my own AI agents: wrote the attacks myself, found six that landed, and added a trust boundary to each skill that reads outside text — web pages, emails, dropped files, transcripts. The honest part is the level it reaches. These are instruction-level defences, not structural ones, and the write-up says so rather than claiming the problem closed.
Deciding what I won't do
Before taking on a client, I wrote down how I'd handle their data, their IP, and the risk of putting AI into a real business. Most of the document turned out to be restraint — the things I decided not to do.
I wrote an IP and compliance position for the consultancy before there was a client to attach it to: who owns what, on whose behalf I act, and where AI does and doesn't belong. The useful part is how much of it is subtraction — no AI deciding about people, nothing high-risk, no training on client data, no client data in anything public. It's a position, not legal cover, and it says so.
A rule you can still break isn't built yet
I had a separate AI, a different model than the one I build with, review my whole operation with one instruction: find where reliability leans on me remembering. The fix, every time, was to move the rule out of my head into something that enforces it.
I ran an outside AI over my workspace as an adversarial reviewer, looking for where trustworthiness depended on memory and discipline rather than enforcement. It found a privacy rule that was policy-only, hand-kept counts that had drifted, and a health check I ran from memory. The repairs turned each into a mechanical control, and I looped the reviewer back over them three times until it converged. The honest limit: the checks report and catch drift; they don't yet self-repair, and I say which rules still ride on me.