The argument in one line.
Most AIOS tutorials optimize for visual impressiveness over operational reliability, and three specific myths -- agent front-ends, unified memory, and Obsidian-first storage -- account for the majority of failed business AI implementations.
Read if. Skip if.
READ IF YOU ARE…
- A solopreneur or small team lead who has watched AIOS tutorials and feels overwhelmed or behind.
- Someone who has built agent workflows that feel unstable, hard to maintain, or impossible to debug.
- A builder managing AI memory with markdown files who finds it breaking in subtle ways.
- Anyone who has been told to migrate everything to Obsidian and is skeptical of why.
- A consultant who needs a clear framework to explain AI automation decisions to non-technical business clients.
SKIP IF…
- You are looking for a hands-on step-by-step build tutorial -- this video is conceptual framework only.
- You are already working at infrastructure scale with thousands of documents that genuinely require vector search.
The full version, fast.
The AIOS tutorial space is flooded with impressive-looking agent frontends and Obsidian graph views that do not reflect how actual businesses should build. The core argument: an AI operating system must be reliable, accurate, and predictable -- which means using skills (defined step-by-step workflows) instead of agents (open-ended goal-runners) whenever the path is known, splitting memory into three containers matched to data shape (context in markdown, state in a database, learned preferences natively), and choosing tools based on whether a human needs to read the output. The Constraint-Build-Stack framework -- Foundation, Skills, Database, Memory, Apps/RAG -- gives every layer a reason to exist before you add it.
Free for members
Chat with this breakdown — free.
Sign in and you get 23 free chat messages on us — ask for the hook, quote a framework, find the exact transcript moment, generate a markdown action plan. Bring your own key when you want unlimited.
Create a free account →Where the time goes.
00:00 – 00:36
01 · Cold open: the noise problem
Every influencer just dropped an AIOS video. Most are technically correct but operationally wrong for businesses.
00:36 – 01:41
02 · The three pillars and the Michelin analogy
Reliable, accurate, predictable -- the backbone of any AI operating system. The Michelin star kitchen analogy: a small menu means consistent output. Simplicity is the meta-rule.
01:41 – 04:20
03 · Myth 1: You don't need agent front-ends
Skills (known-path workflows) beat agents for anything where you can write down the steps. Agent front-ends exist to look impressive on YouTube, not to serve business outcomes.
04:20 – 06:25
04 · Myth 2: Memory is three things, not one
Context/knowledge (markdown), state (database), and learned memory (atomic/native) are different containers. Conflating them is where most builds fail.
06:25 – 08:05
05 · Why RAG is the wrong default for memory
Short-term vs long-term memory is the wrong axis. Data shape decides the container, not time. RAG is for thousands of documents -- most businesses never need it.
08:05 – 11:25
06 · Myth 3: Stop migrating everything to Obsidian
Claude cannot use Obsidian semantic search or backlinks -- those are human features. Skill portability: context lives with the skill folder. The 20K demo problem.
11:25 – 13:25
07 · Human layer vs AI layer
Will a human read it? is the right decision framework. Notion beats Obsidian for team collaboration. Apps are for humans; files last, apps change.
13:25 – 15:23
08 · The Constraint-Build-Stack
Five-layer pyramid: Foundation, Skills, Database, Memory, Apps/RAG. Each layer earns its place when the constraint demands it. Constraint-driven, not hype-driven.
Lines worth screenshotting.
- If you can write down the steps, you do not need an agent -- you need a skill.
- Agent front-ends are almost never justified for business use; they exist to look impressive on YouTube.
- Memory is not one thing: context, state, and learned memory belong in different containers.
- Databases were built for state -- tracking leads or pipeline in a markdown file is the wrong tool.
- RAG is for semantically searching thousands of documents; most businesses will never need it.
- Time is the wrong axis for memory -- data shape decides the container, not how old the data is.
- Claude cannot use Obsidian semantic search or backlinks; those features exist for the human, not the AI.
- Skill portability -- context lives inside the skill folder, not in a separate vault -- is a concrete operational advantage.
- The Michelin star kitchen keeps a small menu; constraint is what creates consistency, not more tools.
- Start from your constraints, not from YouTube tutorials, and your stack reveals itself naturally.
- A pretty Obsidian graph is not a business outcome -- automation running in the background while salespeople close deals is.
- Apps are for humans. Files last, apps change.
- Every layer of your stack needs a reason to exist based on a real constraint, not on hype.
- The right question before choosing any app is: will a human read this output?
Your constraints should build your stack, not the trends.
WHAT TO LEARN
The most expensive AI automation mistake is adding a layer before the constraint that justifies it actually exists in your business.
- A skill -- a written, step-by-step workflow -- is always more reliable than an agent when you already know the correct path. Agents are for genuinely unknown territory, not for familiar tasks dressed up as autonomous.
- Memory is not one container. Context belongs in markdown; state belongs in a database; learned preferences belong in native AI rules. Mixing them causes the failures most builders blame on AI.
- RAG is a tool for semantically searching thousands of documents -- it is not a general-purpose memory upgrade. Most businesses will never have a use case that justifies it.
- The question of whether a human will read the output is the only decision framework you need to choose between a file, a database, or an app. Apps are for humans; the AI layer works fine with plain files.
- Obsidian's semantic search and backlinks are human features -- Claude cannot use them. Building your AI operating system around a tool's human-facing features is a category error.
- Starting from your constraints, not from tutorial recommendations, is the fastest path to a reliable system -- because your constraints make the correct tool selection obvious.
- Each layer of a well-built AI stack should exist because a specific operational problem demanded it, not because it looked good in a YouTube thumbnail.
Terms worth knowing.
- AIOS
- AI Operating System -- the collection of workflows, memory systems, and tools that run AI-assisted business operations, often built around Claude Code or similar CLI-based AI environments.
- Skill
- A defined, step-by-step workflow where every action is written out in advance. Runs the same path every time, making it predictable, auditable, and schedulable.
- Agent
- An AI given a goal and a set of tools and told to figure out the path itself. Appropriate only when the correct path is genuinely unknown.
- RAG
- Retrieval-Augmented Generation -- retrieves relevant chunks from a vector database to supplement an AI prompt. Designed for semantic search across thousands of documents; often misapplied to small datasets.
- Context / Knowledge layer
- The slow-changing business information the AI needs to act on your behalf -- ICP, offer, voice, processes. Stored in markdown files alongside the skill.
- State
- Fast-changing operational data like lead pipeline status, task progress, or workflow checkpoints. Belongs in a database (SQLite, Supabase, Airtable), not a markdown file.
- Skill portability
- The ability to hand a complete skill -- including its context, references, and examples -- to another person or environment by simply moving the folder, with no external vault required.
- Constraint-Build-Stack
- A bottom-up stack-building approach where each layer (Foundation, Skills, Database, Memory, Apps/RAG) is added only when a real operational constraint demands it, rather than because it looks impressive.
Things they pointed at.
Lines you could clip.
01:45
“You absolutely do not need to be running agents if the path you have is predictable.”
02:28
“There is almost no point in having this agent front end apart from having something flashy to show on YouTube.”
05:00
“Databases were made for state.”
06:36
“Time is the wrong axis.”
10:50
“Claude does not use RAG in here. Even if you have the plugins that allow you to use semantic search, that is for you, the human.”
13:45
“Your business builds the stack. Constraint-driven, not hype-driven.”
Word for word.
Read-along
Don't just watch it. Burn it in.
See every word as it's spoken — crank it to 2× and still catch all of it. The same dual-channel trick behind Amazon's Kindle + Audible.
metaphoranalogystory
00:00In the last seven days, every AI influencer channel out there has put out a new AIOS video like they just discovered salt. The problem with those videos are they're entirely wrong. Now the technical concepts are really awesome, but because they're pushing these for businesses to use them, it's never gonna work in a business.
00:15And in this video, I'm gonna break down why, but I'm also gonna make these three myths far less overwhelming for you when you're approaching your build. So first things first, when we are looking at implementing AI in our business, specifically around workflows and agents and whatever, you wanna focus on them being reliable, accurate, and predictable.
00:30That is the backbone of your AI operating system. These pillars will form everything that we're gonna be building. So to understand this from an analogy, if you go to a Michelin star restaurant, you'll notice that their menu is ridiculously simple.
00:42Some of them have different variations. One might just have a fixed menu where you might have seven layers of a tasting menu. Another one will have one variation of fish, one vegetarian, and one meat.
00:51So when you go in there and you read this menu, you don't get overwhelmed by anything. But more importantly, it helps the back end as well, the kitchen, because they can just churn out these perfect dishes every single time because they're not overwhelmed by this ridiculous amount of choice. Like you have in many other restaurants where they have a massive menu, people get overwhelmed, and the kitchen can't keep up cooking consistently good food.
01:09So the thing that we can learn from these Michelin star kitchens is that simplicity is the meta rule here. When we're looking at reliability, accuracy, and predictability, we want to keep our system as simple as possible and base everything that we need off of our actual constraints instead of just looking at these flashy pictures out there and saying, oh, wow.
01:27That's amazing. That's super cool. Let's go and implement this.
01:30That's what people did when AI was first released and why enterprises and mid market clients, the ones that I work with, actually fail because they implemented things that they didn't need in first place. And this brings us neatly into myth number one, which is people building front ends for these agent workflows. You absolutely do not need to be running agents if the path you have is predictable.
01:50What they're doing is actually going against what Anthropic and most AI providers recommend you do for your workflows. For instance, if we look at what a skill is versus what an agent is at a high level, a skill is literally a workflow that you write down from a to b, step one, all the way through to the end of the goal.
02:06It will then go and do that in that exact order every single time, and that's what we want because it ties to our three pillars of predictability, accuracy, and reliability. When you're using an agent, essentially, you're doing is you're giving it a goal and a set of tools, you're just saying, go fly free.
02:20Go and make this thing work for me. That's what people use agents for when they don't know the predictable path of where they want to go. So when I see these flashy agent systems pop up on screen, apart from the fact that you would have to maintain and manage them and a whole bunch of bugs can go wrong, it's also the least efficient path over literally just using a skill that runs on a schedule.
02:39There is almost no point in having this agent front end apart from . To illustrate how ridiculous this is, let's sit down with our imaginary friend next to us, and we're gonna walk through their sales process. Now if you were going to automate a business' sales process, you would sit down with them, you would say to the sales guy, tell me about your workflow.
02:56What do you do day to day? So that you would understand exactly where he's wasting time, energy, effort, and then how to automate the process as much as you possibly can. And then by writing out the standard operating procedure that you can see me scrolling through on the right, mixing it with a bunch of scripts, which in this case are the tools that get the job done, and a few references and examples and other things like that so that it knows what the definition of good is, you would essentially have given Claude the ability to go and create the perfect workflow and give you exactly what you want.
03:23It is repeatable either on demand by just doing forward slash research lead or setting it up as a schedule in three or four different environments, including the cloud. So you have everything that you need to make sure that this thing can always run whenever it needs to run-in the way that it needs to run.
03:37The alternative part here is to go and create an elaborate front end system that serves no purpose to then speak to an agent to not give it the tools that it needs in order to go out there and run the task that it needs to do, and also don't give it enough of the context to actually understand what it needs to do to get to that definition of good.
03:53Which of those two things do you think is probably the better choice for a business? It's super important to understand this distinction because you don't need to have all of these layers in the system. Again, we want to start with the most basic thing.
04:03Not only will this reveal holes in your own workflow if you actually take the time to go through your workflows with your employees, but you'll also be setting yourself up to success because you get a clear definition of what good is. Great.
04:13So I think we're all on the page here that having this little train track that takes us exactly where we wanna go is a much better path than having an entirely new system that we need to manage for absolutely no reason at all. Then next up, we go into myth number two, is memory. Everyone out there is lumping memory into one thing when memory is not one thing at all.
04:28There are separate components of memory. And people ask me tons of questions about this because they get confused by memory and state and context, which are entirely different things. So when I look at memory, I have these three boxes over here.
04:39I have context, state, and memory. And realistically, this should be knowledge, but my AI drew the wrong thing, so that one's on me. Just picture this as being knowledge.
04:46And what we have over here is the curated parts of our business, the things that we have told Claude about who we are, what our business does, who we're trying to reach out to, things like that. It is the information that Claude needs to act on our behalf or in a way that we need it to for a specific workflow. That is the knowledge.
05:01Then we have state, and this is where a lot of people are getting things wrong is they are managing state inside context files or markdown files when it's probably not the best way to do it. Databases were made for state. If you are tracking your leads through separate workflows, you wouldn't wanna stash their progress inside an empty file.
05:17You would stash it in a database. That's what it's for. It doesn't have to be something complex.
05:21It can even be an Excel sheet. More likely, it's gonna be Airtable by today's standards, but you can also use SQLite, Superbase. The point is here, when we're looking at tracking tasks or leads or pipeline status and things like that, that is the state of a system.
05:33It is entirely different to knowledge even though both of these things do form part of the agent's memory. There are different parts of the memory, they belong in different places within our system. And then finally, we get on to learned memories over here, and this is what the AI learns as a result of working with you.
05:47If you kept saying the same thing over and over again, Claude will eventually tell you, I'm gonna make a rule for this so that next time I don't do this again. You can also set these things up statically in the same way that we do with markdown files over here in context. But the nuance and the line that I draw over here specifically for this AI learned memory is that I would not help this thing in any ways.
06:05The things that it discovers about me while we're working together. And so when I understand these three things, it means that I can manipulate them and break them down inside my business in a much clearer way because I understand where each little piece belongs. And as a result of that, I can look at the specific tools or applications that I need in order to achieve that.
06:21And we'll get on to the application thing in just a second. That's the third myth we're about to bust. The point is here, I want you to understand these different layers because everybody is saying rag everything, do this, chuck it in Obsidian because it's rag and Carpathi and all of the other names that they throw out there to attach credibility onto the fact that they have no idea what they're talking about.
06:38For the majority of people watching this, you will probably never need to use rag, and rag is often the worst thing that you can use for a lot of your use cases because RAG isn't entirely reliable. Most people who implement a proper RAG solution are mixing it in a hybrid approach to increase its accuracy and its ability to make sure that it's not giving somebody the incorrect information.
06:59But more importantly, what I see several channels doing is just splitting memory into short term and long term, which makes absolutely no sense, especially because they are saying use Rag for long term memory. That makes absolutely no sense.
07:11That means that if you're saying stash something in an MD file, it needs to constantly be updated. And anything that's in there, what, longer than some arbitrary number like six months is all of a sudden meant to live in a Rag database. That's ridiculous.
07:23At its highest level, Rag is used to semantically search across thousands of documents. You wouldn't even begin to look at it for something that is blatantly simple like time. It's the wrong measurement.
07:32And that's why I prefer to break things down by knowledge, state, and memory because it is a clearer separation, but it also gives the average user a way to think, oh, I just need to look up this keyword. Cool.
07:42That probably belongs in a database because if all I need to do is match name equals mansaw, there's no reason to use rag. And if you wanna see a deeper dive of what this might look like, I'll link all the videos that you need to build all of this stuff from scratch and understand it from a business problem perspective because constraints are the way that you want to address these sorts of things.
07:59These three things are actually really simple to solve when you remove all of the complexity and YouTube FOMO from the equation. Then we're on to the third myth where everybody should absolutely rip everything out of their business and just migrate to Obsidian because everybody just discovered that Markdown is a way of storing information.
08:15There are several problems with doing that, one of which being that Obsidian isn't really as great as most of YouTube makes it out to be. Also, you'll have to excuse my voice. I guess I'm just allergic to all the bullshit going around right now.
08:27But if we flip on back to our environment over here, if we look at what Obsidian is actually doing, it's stashing things in local markdown files, which sounds kind of familiar. Right? If we're looking at a scale over here, let's let's look at this one, you'll see that we have a markdown file over here, and this is perfectly stashing our skill.
08:44But what some of the people are saying is that you should store any and all of your context for your entire business and your skills out there in this Obsidian repository. That's not really how I work in a business. How I would work is remember how I spoke about using skills to create that definition of done?
08:59The best thing you can do to get to your definition of done is proper context engineering, which means giving this skill the exact right amount of context that it needs in order to get to its definition of done. And we do that with references and assets and examples and things of what good looks like. And those for me should always live inside this skill folder over here.
09:19Because when we do that, we're not just not having to go out into a separate system, but we also have skill portability. So it means if I wanna hand my AI SEO skill to anyone in my community or any of the other businesses out there that I serve, all I have to do is lift and shift this thing and then tailor it a little bit to their environment as opposed to having to go into Obsidian and then set up Obsidian for them so they can access the vault where this information lives.
09:40Even though it's stashed in markdown, which AI could probably just go and read from that markdown file, but then why not just include it here? So that whole argument is entirely pointless to me. Then we get on to my second most loved feature is most of videos out there are zooming rapidly in and out and saying, look how cool this is.
09:55Look how cool this is in Obsidian. Okay. It's cool.
09:57But could you imagine sitting down in front of a business and saying, guys, I want you to give me $20,000 for the system and wait for it wait for it. Watch.
10:05This this is what it's all about. Problems solved. Now when I see this kind of thing, it immediately tells me that this person has never worked in a business because this type of stuff, to any person who is serious about running their business, knows that you don't make money with things like this.
10:21You make money with the boring stuff, the things that other people are afraid of, like consistency and doing those sales calls every day despite rejection. That is how you make money, not with crap like this. So when you look at something like this, you ask yourself why would you need this?
10:35And to me, it's when people are learning or doing research or working in a field where it requires this type of information to be seen on a visual layer. For most business people, they do not need to see how most of this stuff happens.
10:47They need automation. They need workflows running in the background to get their salespeople on calls a lot faster so that they can make more money. They don't care about this.
10:56And then finally, my gripe on this whole Obsidian thing is that people are saying this is a Rag database that Claude can use to do whatever it needs to do to search more efficiently, which is also entirely not true because fun fact, Claude does not use Rag in here. Even if you have got the plug ins that allow you to use semantic search, that is for you, the human.
11:14Claude cannot use that yet. There is no reliable MCP, and I cannot do that via CLI. The second thing here is even the backlinks.
11:20Claude does not use that. That is for the human. So when I zoom out of all of the stuff and stop the rant right there, I obviously need to give you something to think about when you're trying to choose your applications.
11:29So the easiest way to split this in your mind when you're trying to choose an application to go alongside your AI operating system, think about what you need for the human layer versus what the AI is gonna be doing. So like I spoke about, most of those features that Claude is actually using Obsidian for, it can be pretty good if the human needs a visual layer.
11:46But if you're never gonna be reading any of this stuff, you absolutely don't need Obsidian at all. You can just stash everything inside your AI operating system in Versus Code over here with the skills where it should be, and this should be your first best practice before you start dumping things in Obsidian. Even if I was using Obsidian, I would prefer to only store larger business documentation that Claude wasn't gonna be using to run its daily skills.
12:09Because for me, again, with progressive disclosure, stashing things in a skill folder is still better. A few other things you need to think about in this whole visual layer.
12:16For me, a Pretty UI is not Obsidian. That's why I don't use it. I don't like its visual layer.
12:20To me, it's not intuitive. It's lacking tons of features compared to Notion. I'm just one guy who's doing most of my work with this back end layer and then most of my business documentation where I need to read specific things lives in Notion.
12:31Via MCP, that is negligible for my AI to go out there and write something to a Notion database or pull something from there. It causes absolutely no problems. The second thing you need to think about is collaboration.
12:41Now if you are working on a small team, Notion beats Obsidian hands down for collaboration because of comments, tagging, and all of the other things that go with the front end layer. It was built for team collaboration. So again, I wouldn't just pull all of my working team off of this piece of software and then go and throw Obsidian in there because it works better with markdown.
12:59The point I'm making here is everything that you have needs to stem from a business decision and from an understanding of how your team actually works and how even you as a solopreneur might work as opposed to just jumping in there because people are telling you to. Tons of people love Obsidian. I don't.
13:13But I don't tell anyone not to use it just because I don't like it. I'm telling you not to use it because most of you have been missold about its capabilities with Claude, and that's forcing you to think you need to rip out what you have in place. So don't do that.
13:25So just to wrap things up here, we need to look at our constraint builds the stack process over here. Because when we start from our constraints, that's when we realize the things that we actually need because the problem is so vivid. It's in front of us and we can see it, and that's how we know what we need to solve.
13:38More importantly, it helps us stick to reliability, accuracy, and predictability because those are the things that we need for our business. So you start with the foundation.
13:46Your context system is gonna be the most important part. You need to uncover all of that. Again, in the videos in the description below, I will have skills that will help you uncover all of these things and build out the entire process from you in this foundational way.
13:58But once you've uncovered exactly who you are as a business, what you're doing, what you're trying to achieve, then you start looking at building skills around that. Not agents, because, again, most of these you will have defined. They will be workflows that you understand.
14:09The people in your business doing this work for you, even if it is just you, you definitely understand what you're doing day to day. And if you don't, you should probably address that first before trying to automate something. So skills come into play here.
14:20And for anything that you can't figure out, then you start looking at agents and have them figure these things out for you. Then when you've started to build out some lead generation systems and content systems, you might wanna have databases in place to track the state of whatever it is that you're doing. And then finally, it's already baked into Claude, but if you needed to add any more functionality to your memory, that's where you could start adding new rules or figuring out new events that get pulled from the conversations that you're having.
14:42And then finally, if and only if you need this sort of thing, you will start exploring Rag or ripping out systems that you already have in place if they no longer fit with any of the other layers of this constraint build stack that you now have. And if you take this approach, you don't have to worry about all that noise out there because you're focusing only when you hit a roadblock.
15:00And when you hit that roadblock, you can then find exact tools that you need to get over the roadblock and onto the next step. So I hope this video was helpful in reducing a little bit of your overwhelm. More importantly, I realized that a lot of these concepts need deeper dives, is why I have them in the description below.
15:12Every single thing that we have spoken about will be this, that you can figure out what you need to do for your business. Leave some comments below, I'll get back to you as soon as possible. Otherwise, check out the videos on the screen.
15:20They'll definitely help you. Thanks very much for watching.
The Hook
The bait, then the rug-pull.
Every AI influencer channel dropped an AIOS video this week. The problem, according to this practitioner, is that nearly all of them are wrong -- not on the technical concepts, but on the fundamental question of whether any of it will work inside an actual business.
Named ideas worth stealing.
00:36concept
Reliable + Accurate + Predictable
The three non-negotiable pillars of a business AI operating system. Every architectural decision should be measured against these three criteria.
Steal forevaluating any new AI tool or workflow before adopting it
01:41model
Skill vs Agent Decision Rule
- Known path? Write a skill.
- Unknown path? Use an agent.
- Can you write down the steps? Always start there.
A binary decision rule for when to use a defined workflow versus an open-ended AI agent. If the path is predictable, it should be a skill.
Steal forscoping any new AI automation project
04:20model
Data Shape Determines Container (Memory is 3 Things)
- Context/Knowledge: slow-changing business info -> markdown
- State: fast-changing operational data -> database
- Memory: AI-learned preferences/rules -> atomic md / native
- RAG: semantic search across 1000s of docs -> vector DB (rare)
A four-container memory model replacing the oversimplified short-term/long-term split. The data shape -- not its age -- determines which container it belongs in.
Steal fordesigning any AI system with persistent context needs
11:25concept
Will A Human Read It?
The single question that determines whether you need an app with a human-facing UI versus a plain file in a skill folder.
Steal forchoosing between Notion, Obsidian, or plain markdown for any new system component
13:25model
Constraint Builds The Stack
- 1. Foundation (CLAUDE.md, context)
- 2. Skills (when you do it twice)
- 3. Database (when data has shape)
- 4. Memory (when rules are forgotten)
- 5. Apps / RAG (when humans read it or 1000s of docs)
A bottom-up five-layer pyramid where each layer is only added when a real operational constraint demands it. Your business problems build the stack -- not YouTube trends.
Steal forroadmapping any business AI implementation from scratch
How they asked for the click.
VERBAL ASK
13:40next-video
“Check out the videos on the screen. They'll definitely help you.”
Soft end-screen CTA with linked deeper dives in description. Primary offer (Skool community) referenced in description, not verbally during video.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
Visual structure at a glance.
