The Operating System That Lets One Person Deliver Like a Firm
I run my whole consultancy inside one system, then install the same architecture for clients. Notion holds the state of every engagement, a no-duplication context hierarchy holds the narrative, a small server runs the work I should not be touching, and a feedback loop turns the system's own mistakes into rules it does not repeat. It is the closest thing I have to a reference build for the operating systems I install for clients.
- Role
- Designer and operator of the system
- Tools
- Claude Code ,Notion ,n8n ,Python ,Hetzner VPS
Watch the walkthrough.
The problem
A Services Business Breaks on State, Not Talent
Every engagement carries running context: the last decision, the open blockers, the contract terms, the thing the client said on the last call, the deliverable that passed and the one still waiting. Hold several at once and the costly part of every session is reconstructing where things stand before doing any work. The usual answer is to hire, but a delivery team needs a pipeline behind it and adds its own coordination tax. The actual constraint is rarely labour. It is that the state of the business lives in too many places and none of them are authoritative.
Repetition Eats the Hours You Sold
The same proposals, the same triage, the same status updates, the same housekeeping, rewritten from scratch every time. Work you already sold, eaten by work you do not get paid for. Without a place to encode it once, every repeatable task gets rebuilt by hand on the next engagement.
The solution.
Architecture diagram, click to zoom
State Plane: Where Things Stand
Notion is the single source of truth for state. Clients, projects, and tasks live there, with status, dates, priority, and ownership. A local repository holds the narrative layer: per-project context files that carry the why, the last decision, the open thread, the things a database row cannot hold. The split is a hard rule. Status changes go to the source of truth first, narrative goes to the repository. A single command at the start of a session pulls anything that changed since I last closed the laptop, so I never act on stale context.
Build Plane: The Work I Repeat
This is Claude Code, organised as a hierarchy of context files and a library of commands. A root file holds the rules that apply everywhere, each area carries its own file for its own scope, and nothing is duplicated between them. A parent names its children in one line, a child points back to its parent, and no fact lives in two places where the two could drift apart. There are 38 of these context files today, loaded automatically based on what I am working on. On top sits a library of commands for the high-frequency work: triage, proposal drafting, end-of-session state updates, prospect updates, research ingestion. Each one is a playbook I run instead of rewrite.
Runtime Plane: The Work I Should Not Touch
A small server runs the scheduled work. Nightly it commits and pushes a full backup of the workspace and a snapshot of the system's memory, and syncs the command library to where the overnight agents read it. Automation workflows, 70 and more, run unattended. Backups go off-site to encrypted storage with locked retention that resists tampering. A weekly automated check reports the server's security posture and flags drift from the week before. Alerts arrive by email from a branded sender. The runtime plane handles the work I would forget when I am loaded, which is exactly when it matters most.
The Feedback Loop: A System That Learns
The AIOS treats its own mistakes as inputs and hardens them into permanent rules. Every engagement closes into an append-only decision record, nothing gets quietly overwritten. When something surprising happens, a mistake or a near-miss, it gets written into the system's memory layer as a rule in plain language with the reasoning attached. A new lesson starts as a candidate, not law, and becomes a hardened rule only when the same situation recurs or I confirm it holds, which stops the memory layer filling with false rules written from single events. The rule set is consolidated periodically, overlapping rules merged into themed guides and dead ones retired, so it stays sharp. The cost of a mistake gets paid once.
The impact
What the System Delivers
- Several engagements held in parallel with state intact, not reconstructed, so attention goes to the work rather than to where everything stands
- Repeatable work encoded once and triggered in seconds instead of rebuilt by hand every week
- Unattended automations watched by checks that make silent failures loud, because most automation projects fail slowly, not loudly
- A readable record of what was decided and why, so the lessons outlive the moment they were learned
The Loop in Action (No Client Data)
- An overnight backup once committed to the wrong branch and silently stopped reaching the off-site copy for a week. The fix became a permanent guardrail: a daily check now compares local state against the remote copy and emails an alert the moment they diverge
- A security patch was written into the repository but never reached the live server, which ran unpatched for days. That gap became a rule: confirm the running version against the intended version, never assume an edit in the repository is live on the server
- Commercial lessons get captured the same way, abstracted to the principle so they apply anywhere. Engage the technical gatekeeper before the close, not after. A green test proves a feature works, not that the system survives unattended or that every signed deliverable was covered
Have a similar problem?
Tell me what is going on and I will tell you what I would do about it. No obligation.