§ 01 · 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.
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.
Visual structure at a glance.
Named ideas worth stealing.
00:36
concept
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 for evaluating any new AI tool or workflow before adopting it
01:41
model
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 for scoping any new AI automation project
04:20
model
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 for designing any AI system with persistent context needs
11:25
concept
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 for choosing between Notion, Obsidian, or plain markdown for any new system component
13:25
model
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 for roadmapping any business AI implementation from scratch
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."
Things they pointed at.
How they asked for the click.
13:40
next-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.
Word for word.
HOOK opening / re-engagementCTA the pitch metaphor analogy story
00:00HOOKIn 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,
00:14HOOKit's never gonna work in a business. And 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:30HOOKThat 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,
00:39you'll notice that their menu is ridiculously simple. Some of them have different variations.
00:44One 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. So when you go in there and you read this menu, you don't get overwhelmed by anything.
00:54But 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
01:24instead of just looking at these flashy pictures out there and saying, oh, wow. That's amazing. That's super cool.
01:28Let's go and implement this. That'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.
01:45You absolutely do not need to be running agents if the path you have is predictable. What 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
06:36onto the fact that they have no idea what they're talking about. For 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,
12:02I would prefer to only store larger business documentation that Claude wasn't gonna be using to run its daily skills. Because for me, again, with progressive disclosure, stashing things in a skill folder is still better.
12:13A few other things you need to think about in this whole visual layer. For me, a Pretty UI is not Obsidian. That's why I don't use it.
12:19I don't like its visual layer. To me, it's not intuitive. It's lacking tons of features compared to Notion.
12:23I'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. Via 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.
12:39The second thing you need to think about is collaboration. Now 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.
12:52So 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. The 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.
13:10Tons of people love Obsidian. I don't. But I don't tell anyone not to use it just because I don't like it.
13:16CTAI'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. So just to wrap things up here, we need to look at our constraint builds the stack process over here.
13:29CTABecause 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. More importantly, it helps us stick to reliability, accuracy, and predictability
13:42CTAbecause those are the things that we need for our business. So you start with the foundation. Your context system is gonna be the most important part.
13:48CTAYou 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. But 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.
14:04CTANot agents, because, again, most of these you will have defined. They will be workflows that you understand. The 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.
14:14CTAAnd if you don't, you should probably address that first before trying to automate something. So skills come into play here. And for anything that you can't figure out, then you start looking at agents and have them figure these things out for you.
14:25CTAThen 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:42CTAAnd 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.
— full transcript
§ 05 · For Joe
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.
