For nine years I tried every productivity stack on the market: Notion, ClickUp, Obsidian layered on Notion, seven SaaS subscriptions that each promised to be the single source of truth. None of them ever were, and eventually I understood why. Those tools stored what I had already thought. None of them could think with me, and none of them could act.
So I rebuilt my working life inside Claude Code, not as a coding assistant but as an operating system: skills as programs, markdown as the filesystem, scheduled cloud routines as cron, connectors as drivers, and a weekly audit as the health check. This is not a metaphor I am trying out for a blog post. It is the system that publishes my content checks every morning, holds my project memory across sessions, and runs real automations while I sleep. This post is the blueprint, including the parts that failed.
What an AIOS Is, and What It Is Not
A real operating system manages resources: processes, memory, devices, scheduling. An AI operating system manages cognitive resources: your contexts, your decisions, your recurring judgment calls. The definition I hold my own system to has four requirements:
- It holds context durably. Decisions survive the session that made them.
- It owns connections. It can reach the real tools, not summaries of them.
- It exposes capabilities as named, reusable skills. Not one-off prompts.
- It executes on its own cadence. Some things you trigger; some run themselves at 6 AM.
Miss any one and you have something weaker: a chatbot with memory, or a scripting hobby, or an automation platform with no judgment. The four together are the OS.
The Three M's: Mindset, Method, Machine
My first attempt at this collapsed into 31 disorganized markdown files in two weeks, and the autopsy taught me that the machine is the last layer, not the first.
Mindset is deciding what the system defaults to. Every skill either defaults to "execute the request" or "interrogate the request first." I build on the second: a system that pushes back is a mentor; a system that only complies is a very fast intern, and I already know what my fast-intern failure mode looks like.
Method is three habits, and they are non-negotiable in my setup: every non-trivial skill returns a plan I approve before it executes; every meaningful decision becomes a markdown file future sessions can read; and the whole system gets audited on a cadence, weekly, with a score.
Machine is everything people usually start with: the repo, the skills, the connectors, the schedules. It comes last because a machine built on no method just automates your chaos at higher speed.
The Four C's: The Actual Architecture
Where the Three M's are how you think, the Four C's are what you build, in strict order, because each depends on the previous.
Context is the foundation, and it lives in markdown. Plain files, in folders you control, versioned in git. At personal scale, this beats a vector database on every axis that matters: you can read it, diff it, and correct it, and the model can load exactly the files a task needs instead of retrieving fuzzy chunks. My context layer is a wiki the system itself maintains; more on that below.
Connections wire the system to real tools. Capabilities are the skills. Cadence is when things run. Most people build in exactly the reverse order, starting with a cool scheduled automation, and then wonder why it produces confident nonsense. It had no context to stand on.
Step 1: Seven Buckets Before Any Code
Before the first folder existed, I listed every kind of information my work touches and collapsed the list, ruthlessly, into seven buckets: projects, clients, content, finance, health, learning, and knowledge, the wiki itself. Seven, because past that number I stop being able to hold the map in my head.
The bucket list is the contract that keeps the system honest: if a question cannot be answered from one of the seven, my AIOS is not allowed to make something up; it flags the gap and asks. This sounds bureaucratic and is the single most important step in the build. Skip it and your context becomes mush within a month, which is exactly what my 31-file first attempt was.
Step 2: The Repo
The machine is one git repository:
aios/
├── .claude/skills/ # local skills
├── .cloud/routines/ # configs for scheduled cloud agents
├── context/ # the seven buckets, one folder each
│ └── knowledge/ # the wiki
└── dashboards/ # generated HTML views
Two disciplines keep it healthy. Context files cap at roughly 800 lines and then split, because a file too big to load cheaply is a file the system stops reading. And the .cloud/ boundary is explicit: only routines and the skills they need go where cloud sessions can see them; everything else stays local.
Step 3: Capabilities That Earn Their Keep
My local skills directory currently holds 35 skills. The ones that matter for the OS are unglamorous: a daily-plan skill that reads three buckets and returns a plan for approval, a weekly-audit skill that scores the system, a handoff skill that writes session state before I close the lid, and a thirteen-skill SEO suite that encodes the recurring judgment calls of running this website. The selection principle, and the connective learnings-file pattern that makes skills compound instead of accumulate, is its own post: the nine skills that run my workflow.
The rule I enforce ruthlessly: a skill that has not run in a month gets deleted. An OS is defined as much by what it refuses to carry as by what it ships with.
Step 4: Connections, and an Unpopular Opinion
Here is the nuance I did not expect: for personal-scale integrations, a plain API call inside a skill often beats a full MCP server. MCP is the right answer when the model needs to decide which tools to use and compose them, and my MCP roster (this site's Laravel Boost server, Figma, HeyGen, Higgsfield, Semrush) does real daily work; I wrote the whole argument up in my MCP explainer. But every connected MCP server spends context on tool definitions in every session. For a fixed, known operation, "fetch my calendar for today," a five-line API call inside the skill costs nothing until invoked. My rule: MCP for tools the model composes, direct API for pipes a skill merely reads. Getting this wrong in the expensive direction was one of my first-month mistakes.
The .env discipline is non-negotiable either way: every key in environment variables, dedicated accounts for anything the system can write to, and no credential ever inside a skill file that gets synced anywhere.
Step 5: Cadence, Where the System Comes Alive
Cadence is what separates an OS from a very organized folder. Mine runs on three timers plus hooks. The proof-of-concept that convinced me was small: a daily scheduled agent that checks this site's SEO vitals every morning and messages me only when something is off, replacing a 20-minute manual routine I had done for months. I documented that build in the scheduled SEO agent post. Weekly, a routine audits the Four C's and writes a scored report. Monthly, a review pass mines my session history for friction, the same loop I described in the /insights guide, and proposes new rules and skills.
Hooks cover the sub-cron layer: small automations that fire on events inside sessions, formatting on save, a check before commits. Cloud routines cover the "runs while I sleep" layer; when Claude's routines shipped, I migrated the workflows I had been running through n8n, and the migration write-up covers what moved cleanly and what did not.
The Wiki Is the Actual Product
Months in, here is the insight I would lead with if I rebuilt from zero: the skills and routines are replaceable; the markdown wiki is not. Every session that ends writes what it learned. Every session that starts reads before it acts. Gotchas, decisions, client preferences, command quirks, all of it accretes into a corpus that makes month three measurably sharper than month one, because the system stops re-paying tuition. The wiki is also the part that survives model upgrades, tool churn, and my own changes of mind. Context is the moat; everything else is plumbing.
And the weekly audit score keeps it honest. Some weeks the number drops, usually Context rot from lazy session endings, and the drop is visible before the damage compounds. A system you do not measure decays silently. Mine is not allowed to.
Build Yours, or Borrow Mine
Start with the seven buckets and one skill, run it for two weeks, and only then add cadence; that ordering is the entire lesson of this post. The diagnosis I would run for you first is not which skill to write but which of the Four C's your work is actually missing, because the people who tell me their automation produces confident nonsense are almost always missing Context, not Cadence. Walk me through your workflow and that is where we would start.
