Back to Blog

How to Build a Custom Claude Code Agentic OS in 3 Steps

8 min read

How to Build a Custom Claude Code Agentic OS in 3 Steps

Most people use Claude Code like a slot machine — random prompts, random tasks, random results. The fix is an agentic OS: a system you can optimize, track, and hand off to your team or clients. I've built mine around three layers — architecture, memory, and observability — and once you wire them together, you stop guessing and start operating.

Here's exactly how to set yours up.

What Is a Claude Code Agentic OS?

A Claude Code agentic OS is a structured system where every workflow you do regularly becomes a skill, every skill that should run on its own becomes an automation, and the whole thing sits inside a memory layer with an observability dashboard on top.

Three things define it:

  • Architecture — your skills, automations, and the way they're organized
  • Memory — an Obsidian vault Claude Code reads from and writes to
  • Observability — a dashboard where you (or your team) can trigger skills and automations with a single click

The architecture is the part that actually creates value. The dashboard is sexy but useless without skills behind it. The memory is what keeps Claude Code from re-doing work it has already done. Get all three right and you're operating ahead of 99% of Claude Code users.

How Do You Design the Architecture Layer?

Start by breaking your life and business into domains. A domain is a category of work — research, productivity, content, community, ops, sales, whatever. You probably have between 5 and 10 of them.

Mine looks like this:

  • Memory
  • Productivity
  • Research
  • Content
  • Community

Yours will be different. The shape doesn't matter. What matters is that you've actually written them down.

Inside each domain, list the tasks you do regularly. Under research, mine looks like:

  • YouTube search
  • Deep research
  • LightRAG queries
  • Morning report
  • Competitor monitoring

Each of those is a candidate to become a skill. Some are simple — "search YouTube for X and give me a structured summary" is a one-prompt skill. Some are complex — deep research pulls from Twitter, GitHub, the web, YouTube, and my Obsidian vault to consolidate prior context.

The point is the same either way: if you do it more than once, it should be a skill.

From skills to automations

Once a task is a skill, ask one question: should this run on a schedule, or do I trigger it manually?

A morning trend scan is an obvious automation candidate — I want it to drop into my Obsidian vault every morning without me asking. Deep research is not — I run it when I have a specific question.

Automations come in two flavors: local (runs on your machine, usually via cron) and remote (runs on a server, usually via Claude's scheduler). You don't need to figure out which one to use. Tell Claude Code "I want this as a local automation" or "I want this as a remote automation" and it will set it up. Better yet, hand it the task and let it decide.

Why this layer matters most

If you stop reading right here and only do this step, you'll get more value out of Claude Code than 99% of users. You're going from "ask Claude random stuff and hope" to "I have codified my actual job into repeatable, optimizable skills."

It also unlocks the team and client use case. Once everything I do is a skill, I can hand the system to a junior team member who would never open a terminal. Same with clients — package it, sell it, force them to use it.

Why Use Obsidian for the Memory Layer?

Obsidian is a free, file-based note app that's really just a nice interface on top of markdown files. That's what makes it perfect for Claude Code. No vector database, no embedding pipeline, no RAG infrastructure — just folders of markdown that Claude Code can read and write.

For 99.9% of people, you don't need a real RAG system. You don't even need something lightweight like LightRAG. Markdown plus Claude Code's native file reading is enough.

The Karpathy vault structure

Andrej Karpathy popularized a simple three-folder structure that works as a starting template:

  1. raw — the dumping ground. Quick captures, research notes, transcripts, anything Claude Code generates as a first pass
  2. wiki — the codified layer. Claude Code takes raw material and turns it into clean, indexed wiki articles you can actually reference
  3. output — finished deliverables. Slide decks, blog posts, reports, anything that ships

Mine looks slightly different — I have archive, content, ops, personal, projects, raw, and wiki. The exact shape doesn't matter. What matters is that the structure makes sense to you and is documented clearly enough that Claude Code can navigate it.

The non-negotiable: a real CLAUDE.md file

If you skip this part, the whole vault falls apart. The CLAUDE.md file at the root of your vault is appended to every prompt you give Claude Code inside that directory. It's how Claude knows what your vault is, how it's structured, and how it should behave.

Mine spells out:

  • The purpose of the vault (it's my agentic OS)
  • The folder structure and what lives where
  • How to write notes (date-prefix filenames, wiki-link syntax, key takeaways sections)
  • What to do when I dump new material in raw

Without this file, Claude Code is guessing every time. With it, Claude can find what it needs in fewer tokens, route new files into the right folder, and generate output that respects your conventions.

How Does the Observability Dashboard Work?

The dashboard is a web UI that wraps your skills and automations in clickable buttons. Click one, it kicks off a headless Claude Code session in the background, and the result lands in your vault. That's it.

Under the hood, each button is just running Claude Code with the -p flag (headless mode) and the prompt the skill defines. Nothing magic. The value is the wrapper, not the engine.

What goes on the dashboard

Two halves:

  • Action buttons — one button per skill or automation you actually use. Hit deep research, get a deep research run. Hit morning report, get a morning report.
  • Observability widgets — usage limits (5-hour window, weekly window), recent vault changes, scheduled routines, forecasts, anything you wish you could see at a glance

Everything is customizable. Mine shows my Claude usage, recent vault diffs, and active routines. Yours might show your client list, project deadlines, or KPIs.

The real value: handoff

If you're a power user already comfortable in the terminal, the dashboard mostly mirrors what you can already do. The real unlock is giving Claude Code's power to people who will never touch a terminal.

Picture handing the dashboard to a virtual assistant, a junior team member, or a client. They don't need to know what Claude Code is. They click "deep research," type a question, get an answer. They click "publish blog post," it ships. You've effectively turned Claude Code into a SaaS product for your team.

This is what makes the OS package-able and sellable. Skills as a service, accessible via buttons.

How Do You Actually Build It?

The whole system gets built through a guided conversation with Claude Code itself. I have a prompt that kicks off the build — paste it in, talk to Claude Code about what you do every day, and it walks you through:

  1. Identifying your domains
  2. Breaking each domain into tasks
  3. Turning tasks into skills using the skill-creator skill
  4. Deciding which skills should be automations (and whether each one is local or remote)
  5. Setting up the Obsidian vault and CLAUDE.md file
  6. Generating the dashboard with the skills and observability widgets you want

Open the terminal, turn on your microphone (voice input speeds this up enormously), and just talk through your day. Claude Code will turn the conversation into a working system.

The full prompt and my actual production agentic OS are inside the Chase AI+ community. If you want to skip the build process entirely, that's the fastest path.

Frequently Asked Questions

Do I need to use Obsidian, or can I use Notion or another tool?

Obsidian works because it's a markdown front end on a normal file system, which is exactly what Claude Code reads natively. Notion has an API but it's slower and more complex. Other markdown editors (Logseq, etc.) work too. The requirement is "folders of markdown files Claude Code can read and write." Obsidian is the easiest match.

What if I don't want the dashboard?

Skip it. The architecture and memory layers deliver most of the value. The dashboard matters most when you're handing the system to non-technical team members or clients. If it's just you, the terminal is fine.

What's the difference between a local and a remote automation?

Local automations run on your own machine via cron or a similar scheduler. Remote automations run on a server, usually via Claude's scheduling feature. Local is better for anything that touches your local files (like vault writes). Remote is better for anything that needs to run when your machine is off. Claude Code can decide which one fits a given task — you don't need to pre-pick.

How long does it take to build?

The first pass takes a couple of hours of conversation with Claude Code. The system improves continuously as you add new skills, retire old ones, and tune your CLAUDE.md. Treat it like an OS, not a project — it's never finished.

Can I sell this to clients?

Yes. The whole point of codifying your workflows into skills is making the system portable. Build the OS for a client, customize the dashboard with their domains and tasks, and you've delivered a Claude Code-powered operating environment they can use without ever opening a terminal.


If you want to go deeper into building Claude Code agentic systems, join the free Chase AI community for templates, prompts, and live breakdowns. And if you're serious about building with AI, check out the paid community, Chase AI+, for hands-on guidance on how to make money with AI.