In 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. 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. That 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.
Some 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. So 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. So 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. That's amazing. That's super cool. Let'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.
You 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. It 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. Go 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. There is almost no point in having this agent front end apart from having something flashy to show on YouTube. 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. What 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. It 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. The 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. Which 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. Not 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. So 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. There 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. I 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. And 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. Then 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. You would stash it in a database. That's what it's for. It doesn't have to be something complex. It 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. It 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. If 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. The 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. And 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. 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.
But 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. That 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. At 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. And 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. That 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. These 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.
There 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. But 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. But 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? The 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. Because 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. Even 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. Look how cool this is in Obsidian.
Okay. It's cool. But 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.
This 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. You 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? And 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. They 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. And 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. Claude cannot use that yet. There is no reliable MCP, and I cannot do that via CLI. The second thing here is even the backlinks. Claude 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. So 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. But 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.
Because 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.
For me, a Pretty UI is not Obsidian. That's why I don't use it. I don't like its visual layer. To 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. 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.
The 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.
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. 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. Tons of people love Obsidian.
I don't. But 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. So 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. More 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. Your 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.
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. Not 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. And 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. 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. And 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. And 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. Every 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. They'll definitely help you. Thanks very much for watching.