Speaker A
If you don't know how to build your own agentic OS, then you are falling behind.
Learn how to build a powerful agentic OS with Claude Code by mastering skills, loop engineering, memory, and UI customization.
Key Takeaways
- Building an agentic OS requires focusing on underlying AI fundamentals, not just flashy interfaces.
- Skills and loop engineering combined with memory/state management provide 90% of the AIOS value.
- Automating repetitive workflows through skill creation dramatically improves efficiency.
- Custom UI and distribution enable wider adoption and ease of use for non-technical users.
- These principles apply across AI models and use cases, making them broadly valuable.
Summary
- The video explains the importance of building a custom agentic OS beyond just visual dashboards.
- Focus is on the core AI fundamentals: skill architecture, loop engineering, memory and state management.
- Level one covers workflow audits, skill creation, automation, and loop engineering to codify repetitive tasks.
- Level two emphasizes memory and state control using databases or tools like Obsidian for self-improving loops.
- Level three discusses UI customization to move beyond terminal limitations and enhance user experience.
- Level four highlights distribution, enabling sharing of AIOS with teams or clients via simple interfaces.
- The approach applies broadly to any project using Claude Code or similar AI models like CodeX.
- The video encourages moving from manual task execution to automated, consistent workflows.
- The presenter promotes a masterclass for deeper learning and access to personal builds and demos.
- Overall, mastering these levels can significantly boost productivity and problem-solving with AI.
Chapters
- 00:00Introduction to Agentic OS and its Value
- 01:53Level 1: Skills and Loop Engineering
- 03:49Level 2: Memory and State Control
- 05:37Sponsor and Masterclass Introduction
- 07:37Automations and Loop Engineering in Practice
- 10:54Setting Up Knowledge Graphs and Data Mapping
- 12:39UI Customization and Distribution for Teams
Full Transcript — Download SRT & Markdown
Speaker A
But not for the reason you think. It's not because you need some fancy dashboard or a Jarvis setup, because that is not where the value of these systems lies. The value is everything under the hood. Everything you can't see. I'm
Speaker A
talking about loop engineering, skill architecture, state management, creating a second brain, and being able to bundle it all together into a coherent, customized product that works for you.
Speaker A
That is where the value lies. And the skills required to build something like this can be applied to any project you work on with Claude Code, which is why this is such a valuable thing to understand. So in this video, we are
Speaker A
going to be breaking down the Claude agentic OS construct level by level so you can learn not only how to build one yourself, but why it's so important that you do. When we are looking at an agentic OS like this one or this
Speaker A
Obsidian-based one, it's easy to get lost inside the visual spectacle of it all. All these buttons and moving parts and metrics, things you can't find inside the Claude Code terminal, jump out at you right away, and you kind of fall
Speaker A
into one of two camps. The first camp is like, "Wow, this looks really cool. I want to get my hands on this. I love all these like sort of visual things I can't find elsewhere." And the other camp sees
Speaker A
it for what it is, which is just the visual interface, and thinks, "This is just smoke and mirrors. There's nothing here that's actually moving the needle forward." And I think both camps miss something. And what they miss are the AI
Speaker A
fundamentals that are working under the hood that turn an AIOS and just a fancy looking web app into a customized weapon you can use to attack any problem with Claude Code or frankly any model. I'm going to talk about Claude Code today, but
Speaker A
this can be run again with something like CodeX or even a local model. And when we talk about these fundamentals, we can kind of break it down into four sections when it comes to this AIOS. The first level is the backbone, and that is
Speaker A
the skills and the loop engineering, in the idea that we have codified everything we do inside of Claude Code and we've turned it either into a skill or some sort of automation. Level two is memory and state control. How can we
Speaker A
make sure that our AIOS has some sort of database of information that it can draw upon when we ask it questions? And more importantly, can we use this state, this memory, whether that's Obsidian or something else? You can use something
Speaker A
like a standard database. How can we use this in combination with the skills and automation we've built to create actually properly built loop engineered constructs that are somewhat self-improving? If you watched my last video about loop engineering, you kind
Speaker A
of know what I'm talking about. The idea that we need to be able to record things and set up loops that can see how we've done in past iterations to improve future runs. And these two levels, one and two, are where we make most of our
Speaker A
money. This is 90% of the value of any sort of AIOS. And once you have that locked in, well, then you can move into some of the cool visual stuff. And that's sort of level three where we talk
Speaker A
about the interface and the UI and sort of the customization aspect of this. If you want to get outside of the terminal and also sort of spread your wings versus some of these desktop applications, because the Claude desktop
Speaker A
application is great, but there's only so much you can do inside of it or set it up in certain ways. And then lastly, we have level four, which is distribution. Because the cool thing about this is it doesn't have to be
Speaker A
personal just to you. You could share your AIOS with members of your team or even clients. And it's a great way to raise the floor in your organization. A lot of what you do on level one and two
Speaker A
can be turned into a literal button or voice command that you can implant inside of your AIOS user interface that anyone can use. They don't even need to run Claude Code themselves. It can all be done for them. So those are the four
Speaker A
levels we're going to be talking about today. I'm going to spend the vast majority of it here in levels one and two because the truth is you could still do all of this inside of your standard Claude Code terminal or the CodeX CLI or
Speaker A
the CodeX desktop app if you really nail down these first two parts, which are skills and loop engineering and memory and state. This applies to any and all problems, not just AIOS. But before we dive into level one, a quick word from
Speaker A
today's sponsor, me. So, I just released my Claude Code master class, and it is the number one way to go from zero to AI dev, especially if you don't come from a technical background. We focus on real use cases. It's updated every single
Speaker A
week, and it includes all of my personal builds. So, everything you see in today's video that I'm using for my demos, you can find it here as well. So, if you want to get your hands on all that, you
Speaker A
can find it inside of Chase AI Plus. There will be a link in the description.
Speaker A
So, level one, skill architecture, loop engineering, all this stuff. What are we really talking about here? Well, there are sort of four subphases of level one. We have the workflow audit, we have the skill creation, we have automation, and
Speaker A
then we have loop engineering. And so, step one is a workflow audit. Before we can create skills, we need to know what you actually need to create skills for.
Speaker A
Because remember, why are skills arguably the most powerful thing in Claude Code? Well, because it allows us to get a specific output. We're telling Claude to do a specific thing in a specific way for a specific output. But
Speaker A
what sort of specific outputs do you need constantly throughout your day-to-day and your week to week? Seems like an obvious question, yet most people cannot answer that. And even if they can answer it, they certainly haven't taken those workflows that they
Speaker A
do manually inside of Claude Code and turned them into skills or automated them. So this is the first thing you have to do. And this, if you do nothing else, will totally supercharge how you work with Claude Code. So here's a visual
Speaker A
representation of what I'm talking about. We have you and we have Claude Code. And for most people, it stays just like this. And it's a purely manual back and forth. You open up the terminal, you open up Claude desktop, and you tell it to
Speaker A
do certain things. And inevitably, you're telling it to do the same things all the time. Well, what if instead we did an audit of everything you do day-to-day and week to week and all the ways you use Claude and we codify that
Speaker A
into skills? You're doing the same tasks over and over. Why don't we actually get consistent with the outputs and how they work? Now, if you have used skills in any capacity, the sell here is very obvious. And I'm just telling you to do
Speaker A
what you do with skills already, but do that a hundred times more because undoubtedly the way you use Claude Code, whether it's as an individual or as a business, can be broken up into a number of different domains. For me, that
Speaker A
includes things like research, content, my online community, my agency, my sales, on and on and on. And underneath each of those domains are different things that I do, specific tasks for content that include stuff like, hey, I need to do outlines for all my projects.
Speaker A
I need to figure out the hooks for my videos. I need to repurpose my content.
Speaker A
I need to create carousels. On and on and on and on. Why are those not skills?
Speaker A
Truthfully, they should be. And yet, for most people, they probably don't have a large robust set of skills like I do right here. And this is the easiest way to improve Claude Code. Now the practical question is how do you do this at scale?
Speaker A
And there are a few different ways we can do this. Number one is we do this purely via a manual process. That means I go inside of Claude Code. I already have an idea of what it is I do. I
Speaker A
explain that task and then
Speaker A
before, is you probably haven't validated how Claude Code should go about this. The ideal scenario is you've done this manually. You've confirmed it actually works, and then you tell Claude Code, hey, see how we just did that task? Now, I want you to turn it into a
Speaker A
skill. And there's actually ways you can do that relatively quickly because remember, Cloud Code has access to essentially all your previous sessions.
Speaker A
It can see the tool calls. It can see what you told it to do. It has the full back and forth. We can really get a head start on creating this sort of like skill repository by telling Claude Code,
Speaker A
hey, I want you to take a look at our last three sessions, five sessions, 10 sessions, 20 sessions. I want you to pull out everything we've done and give me a list of things that we can turn into skills that I do all the time. So
Speaker A
that becomes option number two, which is we have it look at previous sessions and sort of pull the work out of us. This way, it's actually going off real data.
Speaker A
You know, this isn't a guessing game of what you think you should do in Cloud Code. It's actually going to take a look at what you've done. And so, that prompt can just sound something like this.
Speaker A
Hey, can you go through our last 10 sessions that I've had back and forth with you? And I want you to sort of pull out some repeated task or things we've done over and over again that aren't skills yet, but that I want to turn into
Speaker A
skills and create some sort of chart showing what that task is, what the output should be, and the proposed skill. So, that's pretty much it.
Speaker A
Doesn't have to be fancy. You can talk to it in plain language. And like you can see right here, what is it doing?
Speaker A
It's going to find our session files first. Now there's actually a third option for how we can approach this.
Speaker A
Option number three is we have it do an interview right we have Claude code interview us and we say hey I'm just going to give you a stream of consciousness about what I do daytoday week to week and I want you to ask any
Speaker A
questions if there's any blind spots and then I want Claude code to pull out of that conversation these sort of tasks that can be turned into skills. So, same sort of idea. It'd be the same sort of simple prompt. We'll just pull it up
Speaker A
right now. And then I would say something like, I'm trying to turn all my daily and weekly tasks into skills when they make sense. So, I'm going to start off by giving you a stream of consciousness of sort of like what I do each day. And
Speaker A
then I want you to sort of turn it into an interview and call out any blind spots because at the end of this I want you to have as much context as possible about what I do and sort of the outcomes
Speaker A
I'm looking for and I want you to pull out specific tasks and I want to be able to turn these tasks into skills and eventually automations.
Speaker A
That's pretty much it. Doesn't have to be fancier than that. The whole idea is that we are just throwing as much context as possible about our work, about our day, about our week into cloud code and codifying it. We kind of want
Speaker A
to just turn what we do into a checklist. This is the kind of the saying, the way you should approach this is like you brought in some person to be your personal assistant. You want to offload as many tasks onto them as
Speaker A
possible. Well, how would you do that? Well, it's pretty obvious. You would tell them what you do and then give them step-by-step instructions to do that.
Speaker A
That's all we're doing. We're just doing it with clawed code. And yet most people don't do this. And because these are skills, these are now tangible workflows that we can look at and edit as needed until we really dial in those outputs.
Speaker A
And right here you can see one of the repeated tasks that I pulled out from previous sessions. Things like checking for tool and repo updates for videos.
Speaker A
And it continues to go on and on with these tasks it found. Now creating these skills is just layer number one of this, right? We've codified it. And oftentimes these are things are going to get repeated over and over. Well, if they're
Speaker A
going to get repeated over and over, is there any reason why we don't simply turn these into automations, right? Again, we want to move away from this manual approach to everything.
Speaker A
Well, I had this task I did manually. Now, it's a skill. It's been codified.
Speaker A
Well, now let's just set it up into an automation if it makes sense. And this is so easy to do inside of Cloud Code.
Speaker A
We can quite literally just prompt it, can we turn that skill into an automation? And if you want a more visual approach, you can set this up very easily inside of Claw Desktop. We just go to routines. We give it a name.
Speaker A
So that just be like auto one. The instructions would just be run this skill. Insert the name of the skill. And then we would set it on a specific schedule. That's pretty much it. And the third level here would be setting up
Speaker A
some level of loop engineering. Now, I'm not going to go ultra deep into loop engineering because the video I put out yesterday certainly does, but we have sort of the foundation for creating strong loops. We have the skill. We've
Speaker A
turned it into an automation. Now, it's simply a question of well, are we taking a certain automation and are we trying to add some sort of like self-improvement loop to it? And this will tie into memory and state as well.
Speaker A
But that's all I'm really going to mention there. Just understand if you're someone who's trying to dive into loop engineering and that whole side of the equation, you're set up very well to do this given we laid the foundation with
Speaker A
our skills and our automations. But zooming out here for a second, this is the backbone of everything. It's codifying your life and making it so we can get consistent outputs from clawed code for the tasks we actually care
Speaker A
about. And as you can imagine, that kind of has nothing to do with these fancy dashboards and all this other stuff that comes along within a OS. I love the fancy dashboards. I think they're really cool, but this is the power. And you can
Speaker A
imagine applying that to any problem and any sort of use case with cloud code is is very simple and straightforward. It doesn't require any of the other levels, which is why I think it's important to sort of be able to create your own AIOS
Speaker A
because as we stack these levels on top of one another, you can see how sort of modular and flexible this is. So workflow audit talked about the three different ways to do that, right? We can do it manually, we can have it look at
Speaker A
our previous sessions, or we can have it run an interview. Once we've done that, we have it create the skills. Then we ask ourselves, hm, can any of these skills be automated? And then lastly, we kind of have that discussion about does
Speaker A
loop engineering make sense for this particular use case? And speaking of loop engineering, that brings us into things like state and memory, which is level two. Now, a lot of what I'm going to talk about today will be in the
Speaker A
context of Obsidian, but understand it doesn't have to be Obsidian. Everyone likes talking about Obsidian because it's free and it's relatively easy to understand. Everything that works with Obsidian can also be done inside of a traditional database, right? Doesn't
Speaker A
have to be Obsidian. Obsidian is just simple to use. And really, even more so than Obsidian, it's the idea of file structures and setting up cloud code in a coherent manner. Truthfully, you could probably have no database and you could
Speaker A
have no Obsidian. And if you just set up Cloud Code with a file structure that is coherent and makes sense, you're like 99% of the way there. Obsidian just makes it easy. And databases obviously have their own power that goes along
Speaker A
with them. So, how should we set up this part of the equation? Well, we're going to answer that question through the lens of Obsidian and what the file structure should be doing for us. Now, Obsidian, like I mentioned before, is completely
Speaker A
free. The idea with Obsidian is that you simply download it and then you're going to designate a folder on your computer as the vault. It can be any folder or it can be a brand new folder. Now, when
Speaker A
you're installing Obsidian, you'll see a popup like this where again you can create a new vault or you can open a folder as a vault. Now, when we're talking about a vault, again, it's literally just a file. So, you need to
Speaker A
ask yourself for this Agentic OS, what file should it live in? What file is going to have all the information I wanted to know about? So, if we're treating it like a personal assistant, perhaps one of the domains you're going
Speaker A
to have it help you out with is like sales. So, you have a lot of sales data.
Speaker A
Well, whatever file I designate as the vault, I'm going to put want to put at least a copy of all my sales data in there. That's sort of the idea. Now, once we've designated a folder as the vault, in order to connect Cloud Code to
Speaker A
Obsidian, it's as simple as just opening Cloud Code inside Obsidian. So, I navigate inside my terminal to whatever I called that folder. In this case, I literally called my vault the vault. So, I'm now inside the vault. Next, I just
Speaker A
open up Claude Code and boom, Claude Code for all intents and purposes is now connected to my vault. So, I now have my vault and Claude code is open and connected to it.
Speaker A
Now, the question becomes, how do I actually set up my file structure inside the vault? This is not a trivial question. This is very important because the whole value ad for something like Obsidian is the idea that clawed code
Speaker A
can be connected and opened inside of some folder that has a bajillion subfolders and a bajillion files inside of those folders. And you, the human being, can ask Claude Code a question about any of the files and folders
Speaker A
inside of here and give you an accurate and quick answer. How do we do that?
Speaker A
Well, it's going to all come down to how we sort of set this up, right? If we just have one folder with 10 million files in it and there's like no back links and nothing is connected and there's no sort of hierarchy, Cloud's
Speaker A
going to struggle to quickly find you an answer. And when I mean it's slow, I'm also meaning it's going to use more tokens and ultimately it's going to cost you more money. So, we have to set this up in a clear manner. Your mental model
Speaker A
here is setting up a map for Claude code. Right? We're looking at the knowledge graph of my Obsidian vault.
Speaker A
These are all the files inside my vault and how they connect to one another. The ideal scenario is that when I tell Claude Code or ask it a question about something inside this giant morass of files, it has a very clear path to
Speaker A
finding that file and therefore finding my answer. So think of Obsidian as essentially your filing cabinet for everything. Now there's become somewhat of a common way to set up your file structure inside of Obsidian when we're talking about cloud code. And this comes
Speaker A
from Carpathy. This tweet from Cararpathy got over 20 million views and it was all about how he sets up his knowledge base using Obsidian so that large language models like Claude can access information quickly and effectively. And it goes something like
Speaker A
this. We have the primary vault which you are now familiar with. And then we sort of have three subfolders. We have one subfolder which we call the slash raw folder. R A. This folder is where all unstructured data goes. Beneath that
Speaker A
we have another subfolder called the wiki folder. The wiki folder is where we have taken the unstructured data. Think hey we just did all this research about I don't know AI agents right a bunch of unstructured data includes a bunch of
Speaker A
articles and all that sort of stuff and we've turned it into structured data. We've now turned that into like a Wikipedia style article about AI agents.
Speaker A
So the data and like what going on here and everything we want to know about it is very clear, right? This is instead of trying to go through, you know, 20 different like source documents, we now have everything nice and neat under this
Speaker A
wiki file. The third subfolder in the vault is essentially for outputs. So let's say I did my research about AI agents which is now in the raw folder folder number one. I then turn that into structured data into a Wikipedia article
Speaker A
which is in folder number two. Now I want to turn that into say and let me move this over here. Let's say I now want to turn that into a I don't know a slide deck. Okay, some sort of clear
Speaker A
deliverable. Right? We're not just talking about data here. We've actually turned it into something useful. Well that would be folder three. Okay. And so the idea is for most of the data we play around with, we can sort of set it up
Speaker A
like this. Unstructured, structured, and then outputs. That is the Carpathy obsidian rag. And I say rag in air quotes because this is a new rag system.
Speaker A
But that's one way to do it. Now the beauty of this Carpathy system isn't necessarily that we split it up into unstructured, structured, and outputs.
Speaker A
The real beauty is that at every level of this, we have an index MD file, right? This is just a text document, a markdown file that is telling claude code at every level we go down what it's looking at. So, for
Speaker A
example, if I'm talking to Claude Code, I'm talking to my AIOS and I say, "Hey, I want you to give me all the information about AI agents. Remember, we created a wiki article about AI agents." Well, first thing it's going to do is
Speaker A
it's going to look in the vault and it's going to hit this index.md. And this index.md is going to say, hey, inside at this level of our system, we have a raw file for unstructured data, a wiki for
Speaker A
structured data, and outputs for things like slide decks and that sort of thing. So, Claude Code knows right away, hey, he wanted information about AI agents.
Speaker A
So, we're going to go to this wiki article. Now, inside of the wiki article, inside of the wiki folder rather, guess what's inside here? There is also an index.n MD. Now, we have one article in here. So, does it really need
Speaker A
essentially a table of contents for a folder with one thing in it? No, of course not. But what if you've been using this for a year or two or five and you have not one or two or 10, but you
Speaker A
have thousands of documents inside of here and potentially subfolders as well? Well, an index.md is going to make it way easier for cloud code to hit that folder and understand what it's looking at and where it needs to go. Because
Speaker A
remember, what is the purpose of all this? is to give Claude code a map. And if it every single new room it enters, there's a clear spot it can go to and figure out what it's looking at, it's
Speaker A
going to be faster and it's going to be cheaper. And it's important to understand that the power comes from that, not necessarily the somewhat arbitrary folders we created. It just needs to know where it's going. You don't have to do raw. You don't have to
Speaker A
do outputs. You don't have to do any of this carpathy stuff. You just need a map for cloud code that makes sense. And it's probably going to be unique to you because your structures of your data and what you're trying to do are always
Speaker A
going to be unique. So you have a better answer than anyone for how you should structure this. Now if you don't have that answer, guess who can help you?
Speaker A
Claude Code. Simply tell to look at your vault and say, "Hey, what sort of structure makes sense? Oh, use Carpathy's obsidian rag setup for inspiration." That will kind of do everything you need it to do. The only other thing I would mention would be,
Speaker A
hey, let's create a claw.md file that talks about this. In my claw.md file inside of my vault, it talks about my vault conventions, specifically the vault structure, aka what sort of files and folders it's looking at. You can see
Speaker A
over here on the left, I don't just have three. I have several. I have content, notes runs inbox ops projects etc.
Speaker A
etc. Furthermore, I have a whole thing about the navigation pattern, essentially saying, "Hey, when you're trying to find something, here's the path you should follow." And I think using that sort of template is very flexible. you can apply it to any sort
Speaker A
of structure or any sort of data you're working with and you can come up with something that will be effective for you. So when we talk about level two that's what we're talking about. We're giving cloud code a map and it needs to
Speaker A
make sense. Now this also plays into you know loop engineering because and skills and automations because all these outputs need to go somewhere and they need to be logged and they should be logged in a way which you know what I'm
Speaker A
going to say makes sense for loop engineering specifically when we talk about self-improving skills and automations. Well, for that to work, we need somewhere where claude code can see what the past runs have done or really what the loop should be
Speaker A
able to see what past runs it's done. So then it can make future improvements.
Speaker A
And this should all be tied together in the same place. And if you master those two levels, you have 90% of the power of an AIOS already at your fingertips. And all this can be done through the terminal or the desktop app or anything
Speaker A
because at this point you've kind of codified your workflows and now you have a way to actually see what's going on, record what's going on, sort of create your second brain and allow cloud code to pull out insights you otherwise
Speaker A
wouldn't have in an efficient manner. Now level three is where we put a custom visual wrap around everything we've done up to this point. And we have a few options with how we do this. Obviously, it can be purely customized, but we can
Speaker A
make this something that is purely web app based or something that is obsidian based. Now, when we talk about web appbased, we're talking about something like this. Again, this is cloud code under the hood. It's connected with Obsidian, but I now have a bunch of
Speaker A
custom metrics that I have tuned for what I need to see. So, for me, on the left, it shows stuff related to my content creation, right? What's my YouTube subscriber count, Instagram, my latest video, my clawed 5 hour window? I
Speaker A
have directives that are pulled from my Google calendar. I can look at documents that it's created. Over here on the right, I've taken a bunch of my automations and skills and I've turned them into just single buttons. So, if I
Speaker A
just click on something like inbox brief, you can now see that it's cued. It's popped up right over here. And under the hood, Claude is running, going through my inbox, creating drafts, and it's going to let me know what it thinks
Speaker A
is important. And the cool thing about this is again you can change whatever metrics are shown here to be whatever you want. The whole idea of this being a floor raising mechanism. The idea being I can now give some of the power to
Speaker A
claude code to non-technical team members and clients. We'll talk about that in level four has a lot to do with what you see over here on the right where we've turned automations and skills into a button you can literally
Speaker A
press. So instead of telling them, hey, learn how to use cloud code, here's a skill you need to install. Here's how you run the skill. Here's how you automate it. No, I'm just going to go ahead and I'm going to set up this AIOS
Speaker A
for them. And now they can just click a button and it will do all that for them and it'll either dump it inside their own Obsidian or Teams Obsidian.
Speaker A
Inbox brief is done. Inbox brief ready. 32 threads triaged with a Gear Up contract and the Open AI merge campaign flagged urgent.
Speaker A
All right, that's enough out of you. But yeah, you can hear in this case I also have a voice model attached to it. So I can talk to it. It can talk back. And that voice model is completely local, by
Speaker A
the way. Right? That's running on my actual computer that isn't going out to 11 Labs. So it's free. If I click on the inbox brief, it brings up the entire write up. And this too is something that I can open
Speaker A
inside of Obsidian. And speaking of Obsidian, you can also create a command center, a visual layer inside of Obsidian itself. And that's what we see right here. So the metrics are a little bit different, but they're similar. I
Speaker A
can see my token burn. I have, you know, the same sort of setup where I click a button and it runs skills or automations. I have different tabs. So for me, I want more insight into sort of like audience metrics that's going on
Speaker A
the content side as well as some research stuff. So you can make this extremely customized. And again, the cell here at this point isn't the fancy visuals. It's that I can have a one-stop shop for a lot of different things that
Speaker A
are a little harder to have visibility into when I'm strictly inside the terminal. Now, in terms of how you would create something like this, the web app is just like creating any sort of web app using cloud code. You're going to
Speaker A
give it some sort of visual idea. I mean, obviously my exact setups you can find inside of Chase AI Plus, but you should just find some sort of, you know, website or setup you like. You can take a screenshot of this. You would dump it
Speaker A
into clawed code and you essentially say like, hey, here's all the skills I already use. I want this connected to the vault. here are the metrics that are important to me that I want to see in one place. Let's go ahead and create
Speaker A
this. Let's put a visual wrapper over all this. And the same deal goes for Obsidian. Obsidian runs in a plug-in system. So, you're pretty much creating an app, but it's specifically for Obsidian. And if you just tell Claude
Speaker A
Code to hey say, hey, can you sort of take the web app we just created and create an Obsidian plug-in version of that? Again, it will give you something like this. And you just install it and run it from Obsidian. Now, a quick note
Speaker A
about what's going on under the hood here. Now, under the hood, if I click one of these buttons, which again are related to skills. Let's say I click the morning brief skill. What's actually occurring? Well, this is essentially
Speaker A
calling on a headless version of clawed code. So, it's just like as if I opened up my terminal and I have a version of clawed code running and it's now going to run, you know, forward slashming brief. The difference is when I click
Speaker A
that button, it's doing a headless version of it. So, this terminal doesn't literally pop up on your computer. It's headless. It's invisible. And it uses a command called claude-p.
Speaker A
Now, there was some drama with claude dashp not too long ago because Anthropic came out and said, "Hey, if you use claw-p, it's not going to pull from your cla subscription. It's going to pull from this $200 credit which is tied to
Speaker A
API costs." That was kind of a problem. Although, they've sort of walked back from that and that isn't something that has occurred yet. So for now, this is still pulling from your max plan. So it's the same as if you opened up your
Speaker A
terminal and ran it. And that's how we're able to create these sort of structures that still call on cloud code. We get all the power out of cloud code, but it's done invisibly behind the scenes. So when we talk about level
Speaker A
three, what is this bias? Well, bias customization. We aren't locked into the terminal or the desktop app. We can have it show whatever we want. We also have the ability to give this to members of our team. This is what we talk about in
Speaker A
level four, which is distribution. I mentioned a little bit earlier. If I hand someone this web app and it's tied to all these different skills, they're just one click away from getting a lot of power out of cloud code. Because
Speaker A
remember, all the power comes from those skills and automations. If I make it super easy for someone to use those, well, it's kind of like spinning them up on cloud code without actually spinning them up on cloud code. The obvious
Speaker A
question then becomes, well, how would you actually distribute to them? And there's a few options. When we're talking about something that's web- based, it's actually much easier. So giving something this somebody this versus giving them the Obsidian version
Speaker A
is much simpler because since it's web- based I can put it on GitHub. I can, you know, create a whole zip folder. I it's very easy for me to transfer it to them and have it get get it up and running
Speaker A
versus something like Obsidian. Obsidian is a little harder to work that way. So Obsidian would require a little more hands-on work from you. So if you're like, "Hey, I really like the sort of like Obsidian Command Center deal. How would I bring that to a member
Speaker A
of a team?" Well, you would kind of have to set it up for them. It's not as straightforward. It's not much more difficult, but it isn't as simple as like, hey, there's a GitHub repo. Go ahead and clone it and point Cloud code
Speaker A
edit. But again, the customization piece is a huge cell here, especially for those of you who are doing any sort of client work. I can't tell you the amount of people who want to use AI and want to
Speaker A
use Claude, but are totally turned off or frankly just really scared of the terminal and even the desktop app. Like, it is a bridge too far for most people.
Speaker A
If you're watching this video, you probably scoff at that. But I'm telling you, you live in a bubble that 99% of people just like won't go there no matter what you do. And being able to say, "Hey, instead I'm just going to
Speaker A
throw you this and I'm going to set it up for you and you just either talk to it with a voice or you press a few buttons." It goes a long way. The sort of dashboard effect with a non-technical
Speaker A
population like genuinely needs to be studied because it changes how people interpret these like technical tools.
Speaker A
And so zooming out now that we've gone over levels three and four, you can see they're really just the cherry on top of the AIOS.
Speaker A
Almost all the power, almost all of your time should be invested in these first two levels. The skills, the loop engineering is the automation, the codification, the memory, and the state, right? Can you do the same things with
Speaker A
cloud code every time? Can you be consistent? and can we log those things and essentially create the second brain for cloud code that it can not only reference but use to improve upon what it already does. If you can figure out
Speaker A
that then you're going to be well ahead of the general population when it comes to using this tool. So that is where I'm going to leave you for today's video. I hope breaking down AIOS and sort of these four levels made it a bit more
Speaker A
clear about how these things work, where the value is, and how you can create something like this yourself. Like I mentioned earlier, if you want my exact setups, that's all inside of Chase AI Plus.
Topics:agentic OSClaude Codeloop engineeringskill architecturememory managementstate controlAI automationAI workflowAI user interfaceAI distribution
