StackMade OS: the agentic operating system I layered on Claude Code

I started treating my Obsidian vault as more than notes back when I got tired of explaining the same project history to a coding agent every week. That layer worked: a session could read why a decision was made, not only what the code does. It didn't fix what came after. Fifty-odd Claude Code skills had piled up with nobody tracking which ones earned their keep, a handful of checks existed only as shell scripts I ran by hand when I remembered to, and there was no single place to see any of it at once. In under five hours on 2026-10-21, logged between 17:03 and 22:40, I built the thing that closes that gap: StackMade OS, an agentic operating system on top of Claude Code, built around a framework called ARMS. This article covers what ARMS stands for and why each of its layers falls short alone, how a skill gets ranked instead of just invoked, how a routine runs on a dollar cap instead of an open tab, how the vault became the actual memory layer, and what the dashboard looks like once all three are visible in one place.

ARMS: Apps, Routines, Memory, Skills#

ARMS is not mine. It comes from a RoboNuggets video by a builder who goes by Jay E, "A NEW Agentic OS Standard for Claude 5.5 is here", published the same week I built this. Jay's framing is bottom-up: skills first, routines second, memory third, apps last, and his thesis is that the dashboard (the part people screenshot) is about 20 to 30 percent of the value. I haven't measured that split myself, so treat it as his estimate, not mine.

The layers depend on each other in order. A skill with no routing is a prompt library you have to remember to open. A routine with no memory runs blind, repeating the same guess every time it fires. Memory with no interface is a filing cabinet nobody opens on a bad morning. Each layer only pays off once the one under it is solid:

The home screen on the day I wrote this: 1,408 notes, 4,281 links between them, 55 skills, 10 routines defined and 5 of them actually scheduled.

Skills without routing is just a prompt library#

I already had close to 70 Claude Code skills before any of this started: onboarding flows, a voice-and-tone guide, an SEO auditor, music and video generation, each one a markdown file with a frontmatter block. None of them were ranked. None of them had a model attached. A trivial lookup and an architecture decision ran on the same default model, because nothing in the file system knew the difference.

The fix wasn't a new tool. It was a usage parser against seven weeks of transcripts, run once, that told me which of those skills had actually been called. Forty-four of 55 hadn't run in the last seven days. Fifteen went to a parked folder, not deleted, just out of the way. Zero calls in seven weeks of history prove nothing about a skill installed ten days ago, so I kept anything ambiguous. Nine procedural skills, the ones that are usually the whole turn, got an explicit model: and effort: in their frontmatter instead of inheriting whatever the session happened to be running on.

Every skill card carries its own week: calls, last run, and a running dollar figure next to it, not a vague sense that "the humanizer thing" gets used a lot.

A skill isn't knowledge until something tracks whether it gets opened. That's the whole lesson of this layer, and it cost one script, not a rewrite of any skill itself.

Routines without memory run blind#

A routine is a scheduled claude -p run, and the easy failure mode is giving it full tool access and no budget, the way most of the scheduler examples I read while researching this do it. One widely used macOS agent setup runs with --dangerously-skip-permissions on every scheduled job. I didn't copy that part.

Every routine in StackMade OS carries three things a cron job normally doesn't: a per-run dollar cap, a weekly cap that skips the run once it's hit, and a classification as either active (hands me an output) or passive (pings only on a finding). Passive is the one that matters at scale: ten routines that each produce an active digest is ten things to read every morning. That's not automation. That's a second inbox.

Five of ten defined routines are actually installed. The other five sit here, priced and ready, until I decide they're worth the launchd entry.

vault-health and usage-report run on a script, not a model, so they cost nothing and still show up on the grid. friday-recos is the expensive one on purpose: Opus, once a week, reading the week's sessions for work I did by hand that a routine could have done instead, capped at $10. It spent $2.49 this week. The cap isn't decoration. Without it, an unattended claude -p on a schedule has no mechanism that stops a bad prompt from reading the whole vault every night at 3 a.m. and billing for it.

Memory with no interface stays a filing cabinet#

The vault itself predates StackMade OS by months, and I wrote about that layer on its own: why Claude Code loses context, and how Obsidian fixes it, and later the exact setup for wiring Serena, Graphify and Obsidian under one AGENTS.md. What changed this time wasn't the vault's structure. It was giving every department (StackMade, Clients, Content, Labs, Infra, Personal) a one-page router, and writing MEMORY.md as a card catalog that points at those routers instead of at individual notes.

No embeddings sit under any of this. No vector database. No reranking step. The whole retrieval path is grep against three generated indexes (decisions, notes, resources), rebuilt by one script in about four seconds. Jay's own setup reportedly runs the same way at around 420,000 files with no embeddings either; I haven't verified his number, and my vault is nowhere near that size, but the pattern held at 1,408 notes without needing anything heavier.

The honest gap is the context window itself, not the vault. A cold resend of a large session still costs real money regardless of how good the retrieval is. Jay claims an hourly self-ping to keep the prompt cache warm saved him $437 over 30 days. That's his number from his own session pattern, not a measurement I've run, and whether it pays off depends on how often you actually work in long sessions. I'm noting it as a hypothesis worth testing, not as something StackMade OS already does.

What's left once all three layers are visible: the apps layer#

The dashboard is a Next.js app on 127.0.0.1:4310, styled with the same CSS-token system as my other StackMade products, served by a launchd agent so it survives a reboot without a terminal open. It reads files and runs scripts. A model runs only when I click something.

What it is not: a public product, an API with a key, or something you can point a browser at from another machine. POST /api/run accepts a name from an allowlist, never a free-form prompt from the page, and every write carries a local token checked against .env.local. I verified the guard with plain curl: a foreign Host header gets 403, a missing or wrong Origin gets 403, a bad token gets 401, an off-allowlist name gets 400. None of that is exotic security work. It's the minimum a tool with write access and a public-looking URL scheme needs before it's trustworthy enough to leave running.

The Brain view, rendered in three.js: each point is a note, coloured by department, and the small orbiting icons are live Claude Code sessions. One of them, mid-screenshot, was the session writing this paragraph.

The 3D view in that screenshot almost didn't exist. My own roadmap note from the day I built this recommends against it: Obsidian already has a graph view, so a second 3D graph was flagged as presentation, not substance, and the written recommendation was to spend the remaining time on memory and routines instead. I built it anyway, the same afternoon, because I wanted to see agents move. That's the kind of decision ARMS doesn't have an opinion on, and the roadmap note records both the recommendation and the reversal, which is more useful later than pretending I followed my own advice.

What it costs, in real dollars#

Four numbers, from the screenshots above, on one week of one vault: $2.52 spent across routines, $7.37 on nine humanizer calls, $4.28 on five graphify calls, and $0.00 for the two routines that run as plain scripts instead of a model. None of this generalizes past my own usage pattern. A noisier skill set, a bigger vault, or routines that read mail and calendars instead of local files will land on different numbers, and the only honest way to know yours is to build the usage parser first, not last.

What I'm not going to hand you#

This isn't a tutorial, and I'm not publishing the one-prompt installer, the dashboard's source, or the exact skill files behind /calibrate and /note. Those are mine to keep iterating on, not yours to diff against. What's genuinely reusable and already public is the layer underneath all of this: the vault structure, the AGENTS.md routing rules, and the Serena-Graphify-Obsidian setup I wrote up separately, with the actual commands, in the setup article.

If you're deciding whether to build something like this at all, the honest version of Jay's 20-to-30-percent claim is the filter to apply. Skills and routines pay for themselves in a weekend: a usage parser and three capped scheduled scripts are a few hours of work with an immediate, measurable return. The apps layer is the one to skip if you're not already checking a dashboard by habit, because a 3D graph you built and stopped opening is just another unused skill, and this project already proved it can produce a few of those.