A month of building had left me a working system and no map of it, so I stopped and let Claude ask the questions.
On 21 March, a month after the move to Obsidian, I wrote a status note titled “OM Restart” (OM for operating model, my name for the AI OS back then). It asked one question: what do I actually have?
The answer was under “Gaps”. Technology architecture decision: no documented decision on what runs where. Currently everything is ad-hoc. The mail processor ran on a rented web host because my hosting was there. The journal assistant, a scheduled Claude task building my daily page four times a day, ran on the old Windows desktop, Dagobah*, where the connectors were. The new VPS in Helsinki, Bespin*, had sat idle for weeks. Nothing was broken, and nothing was placed on purpose.
An interview, in the wrong direction
The next day I asked for a requirements session on the whole operating model, “taking a very broad view”, using frameworks like TOGAF (an enterprise-architecture method) where they fitted, with “you prompting me with questions”.
Claude first sent a research agent to judge which parts of TOGAF, ITIL 4 (a standard for running IT services), Wardley mapping (a way to map strategy), GTD and PARA suited a solo consultant and which were overkill. Then it interviewed me. For once the assistant asked and I answered.
A decision written down after the fact
By 24 March I had written my first architecture decision record, ADR-001: a one-page note of what was decided, why, and what else was considered. It chose a hybrid: the always-on VPS for scheduled work, the desktop for work that needs the local GPU, and Claude for judgement. The machines should not call each other; Obsidian Sync would be the glue.
The warning for others: I had already built most of it. The mail processor had moved to the VPS on 23 March, as the note itself admits. Nor did the glue last. In October the notes moved to git, but that is a later post.
A specification in a day
On 28 March I asked Claude to recreate my requirements document, aiming for “clarity of requirements before coding, testing against these before committing”. In a single day it drafted versions 0.1 to 0.5, about 2,600 lines, from my old requirements, notes and plans. A second agent checked the draft against the original.
I reviewed it by voice on a walk. I do not remember the details, but my notes do: the speech recogniser heard “power mirror” for PARA, and Claude worked out what I meant. It also mapped my 22 skills to the document’s capabilities and found three gaps. And it dug WOOP, a method I had mentioned, out of my mailbox, added it to the spec and removed it the next day. Some of this was more than a one-person system needs, and I did not always tell which part at the time.
The pattern
Stop and take stock before building more, and borrow only what fits. Of all the frameworks on offer, three things earned a place in a system of one: a capability map (what the system must do, whichever tool does it), decision records, and an acceptance criterion on every requirement. By 18 April each requirement had an ID and a way to check it; version 1.2 followed the next day. The rest of the ceremony stayed out.
What I learnt is mostly about the assistant. Without a written purpose it has no memory of what the system is for, and every session starts from zero. The specification gave later sessions a stable why, the decision records a stable where. Still unsolved: such documents go stale unless something reads them, a theme of this series.
Part 2 of twelve in the series on how I built my AI OS. Start with the preface.
Next: a frontier model read a fixed script aloud to my journal four times a day, for weeks. What I learnt about which jobs deserve an AI at all.
* Host names are changed (here: Dagobah, my old Windows desktop, and Bespin, my VPS). The real ones come from a different saga.
Appendix — for builders
- Write a dated one-page stocktake before the next build: what exists, what runs, what is stalled, what is missing. Mine took one session.
- Let the AI interview you. Ask for questions, not answers, after a research step on which frameworks fit your scale.
- Keep three things from enterprise architecture (capability map, decision records, acceptance criteria) and leave the rest until you need it.
- Write the decision record even if you decided by doing. A dated ADR is cheap, and later tells you (and your assistant) why, when you want to reverse it.
- Review long documents by voice if it suits you, and ask the AI to flag doubtful terms rather than guess.
- Have a second pass check the first. Mine caught what the author missed.
- Give requirements IDs, so any later session or check can point to a specific line.
- What I considered instead: carrying on and fixing things as they broke (cheapest at first, but nothing would have defined “working”), or adopting one framework in full (TOGAF in full would have taken longer than building the system). A short interview, a specification and a few decision records cost a day and gave every later session something to read.