Speaker A
Today, I'm going to explain the different levels of building your own AI second brain. You can see here we have a visual of three very different types of data.
Nate Herk explains five levels of building an AI second brain using Claude and other AI models for efficient data organization and retrieval.
Key Takeaways
- An AI second brain organizes your data for easy recall and efficient use with AI models.
- Start simple with exact search and routing before scaling to semantic and autonomous levels.
- Reverse engineer your system based on how you want to access and use your data.
- Proper folder and file architecture is critical to avoid losing or misplacing information.
- Not all users need the most advanced level; choose the level that fits your pain points.
Summary
- The video explains five levels of building an AI second brain to organize and recall personal and business data.
- Nate Herk uses Claude code but emphasizes the system works with other AI models like CodeX and Hermes agent.
- A second brain is a system of folders and markdown files designed to store notes, recordings, and threads for easy retrieval.
- The importance of reverse engineering the system based on how data will be accessed and recalled is highlighted.
- Level one focuses on exact word or file name searches with routing rules to locate information efficiently.
- Higher levels introduce semantic search, relationship mapping, and autonomous data management.
- The video stresses starting with the simplest level that meets your needs to avoid unnecessary complexity.
- Examples of folder structures, routing files, and practical use cases are demonstrated.
- Challenges such as managing large data sets and avoiding hallucination in AI responses are discussed.
- The video also touches on team collaboration and syncing data for a shared second brain.
Chapters
- 00:00Introduction to AI Second Brain Levels
- 01:46Using Claude and Other AI Models
- 03:47Overview of Five Levels Explained
- 05:35Level One: Exact Search and Routing
- 07:19Navigating Folder Structures and Files
- 09:03Automated Ingestion and Memory Features
- 12:48Semantic Search and Relationship Mapping
- 17:37Challenges and Best Practices
- 19:32Team Collaboration and Syncing Data
Full Transcript — Download SRT & Markdown
Speaker A
This one is where we have our context really starting to form, and we're starting to see some relationships, and we're starting to see some different nodes and entities form. And then as we continue to scale this up, add more
Speaker A
knowledge, more knowledge, more relationships, we start to get something that looks a little bit more like this, where we have clearly different clusters, and inside of all of these nodes, we can see how they relate to each other. And
Speaker A
then over here, we're taking all of those relationships a step further, and we're able to then start to see how everything really pieces together rather than just having files that sort of link back to each other. This is relationship
Speaker A
mapping. And so really, the idea of an AI second brain has blown up because we're all trying to get as much information out of our heads into our systems as possible. That's the true value. Your moat is your data. It's your
Speaker A
IP. But the process of organizing that into a system so that you can use it with a bunch of different AI models and so that it can actually recall things in a way that makes sense rather than just
Speaker A
hallucinating or spending a bunch of your time and tokens trying to look through everything. That's the issue. So clearly, all of this is my real data, and this is what the actual project looks like. It is my Heroku project. I have a
Speaker A
bunch of folders and files here, and at the end of the day, that's basically all it is. It is markdown files that are organized in a way that I understand and that my agents understand. And so yes, I'm going to walk you guys through what
Speaker A
I have here and how it works. But I also have this other project where I'm going to show you if you're starting from scratch or if you feel like maybe you're in between level two and three, how we
Speaker A
can actually look at the differences and what it might look like to scale up your own systems and start to add context in different ways. So super excited to dig into this today, and I don't want to waste any of your guys' time. So let's
Speaker A
just start looking at these five levels and how they differ. All right, so every level of a Claude code second brain, and I'm going to be obviously kind of referring to Claude code a lot, but keep in mind this can be used with any AI model.
Speaker A
I use my second brain all the time with CodeX as well. I use it with Hermes agent. This can be used by different agent harnesses because it's just files and folders. So what is the actual job of a second brain? A lot of people
Speaker A
probably define this differently, but the way that I think about it is that it's a place for me to save notes, meeting recordings, ClickUp threads, stuff like that. I can save it there, and then it helps me basically ingest it
Speaker A
and get it into the right spots so that it can actually find it later. And so that's really the thing to think about: can your agent find it again? And could you find it again? Because if the
Speaker A
answer is no, then you probably don't have the right routing or folder architecture set up, which is what I'm here to talk about today. And one other sort of mindset thing that I want to get out there before we dive into these five
Speaker A
levels is that you kind of have to work backwards. You want to reverse engineer based on the question. So, this will start to make more sense as we get into it. But really, what you should be thinking about is how do I want to use
Speaker A
this data in the future? Because how it's going to be accessed and recalled determines the way that you put it in in the first place. For example, a basketball hoop and a basketball. We know what shape the hoop is, and we know
Speaker A
that the ball needs to go through. So why would we ever design the ball to be a giant square? Because it just wouldn't fit through the hoop. So that would make no sense. So you need to start with the
Speaker A
end in mind a little bit. Once again, I will show you exactly what I mean by that as we continue on. Because remember, we're trying to get to the point where your second brain knows everything about your business, about
Speaker A
you, your relationships. It knows everything to the point where it probably can recall stuff better than you can because it has a better memory, and it can search through things way faster than you can. So, we've got five
Speaker A
different levels to talk about, and they each kind of have different questions. So, level one is, can you find the file or the info by looking for an exact word or name? Level two is, can you pull everything on a certain topic together?
Speaker A
Level three is, I searched for different words than I wrote. So, semantic search, you're searching for meaning rather than an exact word match. And then trace relationship chains. Can you ask about topic X? And then trace that all the way
Speaker A
back to topic A? And then level five is just kind of making this whole second brain thing super autonomous to the point that you don't even have to think about it. And by the way, this isn't me saying that number five is best. I have
Speaker A
some arguments about why I do not currently sit on level five. The point I'm trying to make here is each level is different, and you want to find the simplest level or the lowest level that actually fits your needs. If you don't
Speaker A
have a pain point in your system, then I don't really think there's a need to go experiment or develop a new sort of, you know, architecture. If there's no pain, then why create more? Okay, so level one is pretty simple, and this is where you
Speaker A
always start. So you start with a claw.mmd, or if you're using CodeX or something, you would start with an agents.mmd, but you start with a claw.mmd, which is kind of, you know, that gets loaded up. That's almost like the system
Speaker A
prompt for that session, for that project, and then you've just got a bunch of folders and files. But the key part there is the claw.mmd is kind of treated as a router. So yes, you've got some, hey, this
Speaker A
is your role here, is what's important, but you also have routing rules. If you ever need to find information about me personally, look in this folder. If you need information about our quarter 1 priorities, look in this folder. Because
Speaker A
if you've ever had a point where you ask Claude to do something, and then it asks you, "Hey, can you give me more info? I don't know what you're talking about," but you know there's files and folders in your project, then you probably just
Speaker A
didn't give Claude the knowledge to go look there. It's not just going to go search your entire codebase automatically. I mean, you wouldn't want it to do that because it's going to waste your time and your tokens. So, if it
Speaker A
doesn't know if something lives somewhere, then it's probably not going to be able to find it. So, when this is properly set up, you will stop having to reexplain things. You will talk to it, and it will just know where to go look
Speaker A
and why. But the problem with this is that if it grows too big, it can start to get messy and feel ignored. And this is typically more of like an exact word type of search depending on the way that
Speaker A
you route. So if I open up my, um, example project here, let's open up level one.
Speaker A
So in level one, what you can see, pretend this is its own cloud project.
Speaker A
We've got a cloud.md. So let me click into that. We can see here it says this file loads automatically every time you open cloud code in this folder. It is the one file that tells the AI who you
Speaker A
are, how you work, and where things live. At level one, this file plus a few folders is your entire second brain. So, here's kind of like that basic knowledge. And then right here, it's this simple where things live in the
Speaker A
context folder. Always true background about you and how you work. Read this first projects decision log. And that's basically it. So, right here, you can see there's a context folder. We have an about me file, which you could grow. We
Speaker A
have stack and conversations file. We have decisions. So this is a decision log wh-
Speaker A
business. And then we have projects. So this is where you could have a markdown file or even folders within the projects for all of your ongoing projects, all of your ongoing clients, whatever it is, however you want to organize it. That's
Speaker A
where you can have some projects. And you can even start to organize these things by dates if you want. So if you want to just have one that's for like May and then you have all of those stuff
Speaker A
and you have one for June. The thing that I really want to stress here with level one and the thing that I answer a lot in my community and in the comments is that there is not yet a standard way
Speaker A
that has been proven the best way to set up your projects or your second brain besides some of the most common things like your context and your cloudmd and your you know whatnot. But the point I'm trying to make there is don't see what I
Speaker A
do and think that that's the right way or see what someone else you watch does and think that that's the only right way. All that matters is do you have proper routing in place and does it make sense to you and does it make sense to
Speaker A
your AI? Okay, so let's say I have my Herku 2 project right here and I need to find something in here but I can't ask AI for some reason. What I need to find is easy because I understand the drill
Speaker A
downs. You know I understand my base folders and let's say I'm looking for the HTML slide deck I built for my ranking cloud code features video. I would come into here and I say okay I know that's a project so I'll go there.
Speaker A
Within my projects, I've got another project for YouTube videos. I'll open that up. And now I know I made this video right here, May 30th, Claude Code top 50 features. In here, I have the actual tier list deck. And when I open
Speaker A
that up, now I have the slide deck. And not only can I find it easily, but my agent can find it because it all makes sense and I have routing rules. Real quick, guys, if you're watching this video, you're probably interested in
Speaker A
building your own AI operating system. Lucky for you, I have a full free course on that in my Free School community. The link for that is down in the description. Join the Free School community. Hop in here, take the 7-day
Speaker A
challenge, build your own AI operating system, and apply these principles into building your second brain, which will make your AI operating system even more powerful. So, links in the description.
Speaker A
Let's get back to the video. Awesome. Okay, so that is how you start. Now, as you move up to level two, you might be able to start to work in some things like the LLM wiki, which is what I've
Speaker A
got set up for a few different things. This is the whole Carpathy LLM wiki, which I did make a full video about. If you want to check that out, I'll tag that right up here. But this is when you
Speaker A
start to have more files and and they start to take a bit of a different shape and you want to organize them together in a bit of a different way. So it could be really good for researching all on a
Speaker A
certain project. It could be really good for, you know, a few of the ones that I've got set up is my YouTube transcripts all live in their own wiki.
Speaker A
I've got all of like my meeting transcripts that live in their own wiki. So for example, this is the obsidian view of my wiki for all of my YouTube video transcripts. You can see here if I go to wiki you can see there's main
Speaker A
concepts like aentic workflows AI coding market context window and all of these in here start to relate back to other tools and concepts and videos and stuff like that. So we've got the sources we've got platforms we've got um context
Speaker A
management techniques and all of this was autocreated by our cloud code when I told it to ingest this YouTube transcript into our wiki. So I'm not going to dive super super deep into all this right now but definitely check out
Speaker A
that YouTube video I linked. Now, what else is cool about this is this transcript wiki actually lives within my main Herk 2 project. So, here's Herk 2.
Speaker A
If I go right here to other worlds and then I go down to YouTube OS and I click into the transcript wiki right here, this is what we were just looking at in Obsidian. We could see the concepts, we
Speaker A
could see the comparisons, we could see sources, techniques. This is what we were looking at in Obsidian. So, all Obsidian is is it basically just visualizes your markdown files. You see here wiki concepts comparisons techniques. This is what we were just
Speaker A
looking at. All we get now is we just get a visual view of all that. And so the reason I wanted to bring that up as well is because I think a lot of people obviously get pretty infatuated by that
Speaker A
visual view. And obviously I started the video with that because I think that's what hooks a lot of people in. But all that really matters is can your system grab that and give it to you. If you are
Speaker A
a visual person and you really want that view, then by all means install Obsidian and set it up. It's super easy. But I'm saying that you don't always need that visual layer if it's not beneficial to you. I hardly ever open Obsidian just to
Speaker A
be honest because I know that it all lives here and I know that my second brain and my OS can find all of that. So anyways, in level two here, let's look at this. It's very similar in shape to
Speaker A
level one. It's just building on top of it because now we have our cloudmd which starts to route to some other things because it routes to the wiki and it still routes to context projects decisions but it's also routing to
Speaker A
references and memory. So we're just starting to add a bit more of these routing rules inside of the claw.md. We can grow the context. We can grow the decisions. We can grow projects and references. And we can also start to get
Speaker A
this idea of memory. And what's really cool about this is you can turn on automemory in cloud code. And the AI will basically start to write this file and update it on its own. So you don't even have to think about it. If you come
Speaker A
in here and you do /memory, it'll say automemory on or off. And if it's off, if you want to turn that on, just turn it on. And now one thing to think about is I mentioned earlier that we want to
Speaker A
make our second brains tool agnostic. And this is one thing that's pretty specific about cloud code is it uses claw.mmd and it uses this memory.mmd and it keeps that updated on its own. So if you wanted to move this over to codeex,
Speaker A
what you would do is you would first of all transition your claw.mmd. You'd make a copy of it called agents.mmd. As you can see here in my herk 2, I've got my if I scroll down cloud.mmd right here
Speaker A
and then I've got agents.mmd right here. And they're essentially the exact same file. Just so codex can read this one and cloud code can read this one. But because cloud code keeps that automemory, all you need to do is make
Speaker A
sure you have that memory MD file and just tell codecs, hey, by the way, for memories, look in our memory.mmd file.
Speaker A
It's all about the routing there. Anyways, just felt like that was important to throw out. But at a certain point when you have these, you know, wikis, they do start to degrade a little bit because what's what's great about
Speaker A
them is that they have indexes, right? So when your AI starts to look in the wiki, it knows, okay, if the user is asking about agentic workflows, I'm probably going to start here. And then from here, I'm going to drill down and
Speaker A
read this to see what else is important to them. Maybe they're asking about the WAT framework, and then I can drill into that. And maybe from there, I need to learn a little bit more about the cloudmd system prompt, and then I will
Speaker A
drill into that. So there are relationships here a little bit, but this isn't the same as like semantic relationships or knowledge graph relationships that have more meaning.
Speaker A
This is more about just actually following a trail and reading the page in its entirety. And I'll be fully honest with you guys. I pretty much sit my entire Herk 2 project in this level in level two because this has been
Speaker A
working really well for me. Like I mentioned earlier, I haven't felt a pain yet big enough to switch over to level two. And here's what I meant by that. My wiki has links. Isn't that a knowledge graph? Not exactly. Because this doesn't
Speaker A
have connections of how they are related. like this is endorsed by this or this has cron to here. These just have connections because it's like a a C also. It's like backlinks. So, they're very similar and yes, they can achieve a
Speaker A
similar effect, but it's still a little bit different. Anyways, let's take a look at level three, which is where you start to do things like semantic search.
Speaker A
Whether you do that in Obsidian, whether you do that with Pine Cone or Superbase, however you start to grab the actual semantic search, that is what level three is. And so just as a quick visual for you guys, let's take a look at this
Speaker A
quadrant cluster of images. So every one of these vector points is an image. And what we see in here as the payload is stuff like the file name, the URL, the name of the author or the artist and the
Speaker A
URL. But we don't actually see like what's in the image. We don't get a description. So what we have to do is we have to organize these images by meaning or by similarity. So, when I open up this graph and we start to visualize the
Speaker A
stuff here, what you see is that we have this main image, these owls, these kind of like I I don't even know. Um, it's a very trippy style, like hallucenic style. Anyways, then this one is kind of similar, right? It's got those colors.
Speaker A
It's got the paint. This one is also similar, but they're not the same. They just share similarities. And as we start to expand these more and more, we can start to get into different styles. So, this one has like some creepy eyes and
Speaker A
mushrooms or whatever. This one is kind of more down that fantasy lane. And as we start to build out more of these relationships and meanings, we can expand and grow away from them. And so quadrant really just gives you a
Speaker A
visualization here. I mean, it's a it has clusters and vector store, but the reason I pulled this up as a demo is just because we start to see the actual relationships form here based on meaning. And that's what's important
Speaker A
about semantic search is that we're no longer doing keyword matching. We're searching based on meaning. So here in my YouTube transcript second brain if I go to the smart lookup over here this is very different from just the regular
Speaker A
search. So for example if I search here for um feedback let's say we're actually doing a match on the word feedback and it's only showing me where that word actually appears inside of our second brain. But if I come over here in the
Speaker A
smart lookup and I search for feedback we are getting matches that have things in here that mean feedback. So live test results, cloud code skills, which was talking about evaluations and stuff. So there's a big difference between keyword
Speaker A
matching and semantic search, you know, similarity matching. This one over here is saying X equals X. And this one is saying X is similar to X, Y, and Z. And so this all just goes back to vector databases. I've talked so so much about
Speaker A
vector databases, so I'm not going to dive super deep in. I've got so many resources on my channel, but basically what it is is we take a document, so let's just say YouTube transcript. We chunk it up and then each chunk is ran
Speaker A
through an embeddings model. And the embeddings model puts that chunk of text onto like a three-dimensional space where space is related to meaning. And so it decides, okay, this chunk is about a company, so we're going to put it up
Speaker A
here. This chunk is about finances, so it's going to go here. And we start to see these vectors form near other similar vectors. Now, do you guys remember how I said earlier like you want to think about how is the data
Speaker A
going to be used? What type of questions are you going to ask? This is a reason why that's so important. So think about this. Let's say I put my meeting transcript of March 5th meeting into my second brain and I put those in as you
Speaker A
know vectorized chunks. So let's say when I vectorize that meeting we actually get you know like 20 chunks. It actually creates 20 chunks or however many that is. And then when I say hey Mr. AI agent can you summarize the
Speaker A
meeting on March 5th. It will basically search for March 5th meeting summary and it will pull chunks that are similar to March 5th meeting summary. And then even if it gets the right chunks, it's going to only summarize those five chunks.
Speaker A
It's not able to look at the entire meeting summary or sorry like meeting transcript in entirety. So it doesn't really know a summary. It might be missing a lot of key information. Now yes, there are things you can start to
Speaker A
play with there like metadata and other things like that to make these results better. But at the end of the day, people kind of assume that a vector database was some magic solution where it could always pull back what you need.
Speaker A
But that is very false. And I mean, think about it like this. Let's say we have a table and we say, "Hey, which week did we have the highest sales?" Okay, the agent looks for highest sales.
Speaker A
It maybe grabs this chunk outlined in gray of data and then it looks at, okay, week six here was the highest sales, so that must be the answer. But in reality, you can see week 14 was higher. Week 19
Speaker A
was higher. So, when you need something that has actual full context, then you can't do the vector database chunking.
Speaker A
That's where you'd rather just have a markdown file of March 5th and then all this agent would have to do is read that entire markdown file and then give you a summary and that's just going to be more
Speaker A
accurate. So in this project, if we open up level three, you can see it's very similar because you can still have context files, decision files, you can still have all that. And then you might identify, okay, actually this one
Speaker A
specific unit of my business, maybe my YouTube transcripts, maybe I want just that to be a vector database, but I still want my context and my projects and my decisions to be marked down files. So another point I'm trying to
Speaker A
make here is just because you have a second brain and just because you have a massive, you know, folder here with a bunch of folders and files doesn't mean that the whole folder needs to be one style. Doesn't mean that everything
Speaker A
needs graph rag. Doesn't mean that everything is just LLM wiki. It means that you're able to decide based on the type of data and the way you use it, how can you structure this specific folder in the way you want it. So here we have
Speaker A
a vector index folder and we click on the how search works. It works by chunking embedding search hybrid reranking. There's some things you can get really, really nitty-gritty on when it comes to semantic search. But what vector retrieval is really, really good
Speaker A
at is looking at tons and tons of data, typically just like a lot of text, and when you need a very specific answer, something that's very similar. So, if you had a thousand rules that you needed to store, and you basically said, "Hey,
Speaker A
um, can you remind me what rule 17 was?" That might be a really good use case for vector search because it's able to search for rule 17, pull in those chunks, and just give you a little snippet because it would be a waste of
Speaker A
time and tokens for your agent to read the entire markdown file of all a thousand rules if you just needed rule 17. So that's kind of the difference there. Like I said, I've got so many videos on vector stuff on my channel,
Speaker A
but really you could say, "Hey, to your cloud code agent, I have this data.
Speaker A
Here's how I want to use it. Do you think this would be better for now as markdown files or should I do semantic search?" Like what would actually make more sense here? and it will help walk you through the way that you should
Speaker A
actually set that up. So now I hope you guys are starting to understand why I said, you know, moving up on or I'm sorry, like moving up on levels, moving down doesn't necessarily mean better.
Speaker A
It's all about figuring out what is the pain point with what you're currently doing and where would a different level help you out and fix that pain point.
Speaker A
Okay, so now let's take a look at level four. This is where we start to get into like knowledge graphs and relationship graphs, which typically are going to be the most complex and sometimes the most expensive as well. If you're doing it on
Speaker A
a certain platform, you could always use open source software. But anyways, knowledge graphs. And I also want to be upfront. I've played with these a lot, but I do not actually use these on the day-to-day because I found out just
Speaker A
other ways to use routing files and wikis that fit my needs. Now, my work is very different than what a lot of your guys' work may be. Mine is very project based and it is very, you know, content
Speaker A
heavy. I don't have a massive CRM to manage with a bunch of different businesses and clients, you know, and if I did, maybe a knowledge graph would make a lot more sense, and it probably would. But typically, the cool part
Speaker A
about that is if you identified that you needed a knowledge graph, let's say for all your projects, you needed you wanted to put all of this in a knowledge graph, the data probably already exists here.
Speaker A
And that's the thing about building out these relationships in your knowledge graph is that the system, whatever software you use, is typically going to be pretty good at embedding that and creating that. But the problem that you have to solve is you have to give it
Speaker A
enough data. And so one thing that I really like to do is I like to have these brainstorm sessions as you can see. And what I do with these brainstorm sessions is I use a skill called grill me. So if you see here I have a skill
Speaker A
called grill me which I originally got from Matt PCO. I customized it a little bit. I'll leave the skill for grill me in my free school community. The link for that is down in the description. All you have to do is hop in here, go to
Speaker A
classroom, click on all YouTube resources, and you can find all the skills and everything like that. But the skill, what that does is it basically just grills me. It interviews me relentlessly about a certain topic and it creates a brainstorm file here. It
Speaker A
only stops when it knows everything about it. So if you wanted to start building up a knowledge graph for all your clients and businesses, just say, "Grill me about client A, grill me about client B, grill me about business A."
Speaker A
And it would ask you questions and you can feed it files, you can give it stuff, you can feed it in transcripts, you can feed it in, you know, contracts, whatever it is. And that's how you can start to form a lot of data. Hey guys,
Speaker A
me again. Real quick, I'm editing this video and I realized that I needed to throw out one thing here, which is that obviously if you're putting all of this data and you're sending it all to Enthropic to Claude Models, then that's
Speaker A
not private. So, if you feel comfortable with that, that's fine. I am putting a lot of my data in there and it is my business stuff and that's what I'm doing. But if you don't feel comfortable with that or you, you know, don't want
Speaker A
to send client data, of course you don't, then maybe you want to do that through open source models and maybe cloud code isn't where you have this second brain that has every single piece of information about you and your
Speaker A
business and your client's business. So the point I'm trying to make here is just this is what I'm doing. I'm obviously aware of the fact that my data goes to Enthropic when I process it through Claude. And if you guys are
Speaker A
doing that, then you should also be aware of that. But there are other options if you can't do that. So I had to throw that out there. I am planning to make a ton of videos here soon about
Speaker A
local AI and open source models and all this stuff cuz it's a really really exciting space that I think is going to start becoming bigger and bigger. So yeah, keep that in mind. Back to the video. I think sometimes that's a
Speaker A
misconception about how I got here and how people build their own AIOS or second brain is that they think the problem is the system not retrieving it great, which sometimes it is, but sometimes it seems like the bigger
Speaker A
problem is getting everything out of your brain into the system. So before you blame AI, take a look at your folders and files and say, is this actually holistic? Is this does this have all the nuance that I have in my
Speaker A
brain? Anyways, from there, when you open up level 4, you can see that it's it's, you know, very similar still.
Speaker A
We're just adding on a few things. You can see here we've added an agents.mmd, which is the exact same as the cloud.MD.
Speaker A
And what else is cool is you can literally just reference inside of your cloudmd at agents.mmd and then you can delete all this because this basically just like injects that file into here.
Speaker A
But I just wanted to show that. But anyways, you can see we're still following the same principles. We have a wiki. We've also added a knowledge graph layer. We've still got the same where things live with the routing with all
Speaker A
these just regular folders and boring markdown. But boring is beautiful. You can see that our memory is still here.
Speaker A
It's starting to grow. And we just keep building on top of this. So one thing we added here as you can see was our knowledge graph folder. And so what happens here is we get different entities, right? So like we can see,
Speaker A
okay, Jordan is a person, Acme is a company. And then we can start to form relationships between all these things.
Speaker A
So Jordan works at Acme. Acme is endorsed by Postpilot. Postpilot is a competitor of Cadently. And it starts to build out not only these entities, but it shows you how they're all related.
Speaker A
And so that's why when I said that I really like using, you know, this um what's it called? LM Wiki is because I have enough of that feel of all these relationships because I've put so much time and effort into ingesting these in
Speaker A
the right way and giving it context. The thing about this one is that it has to read every single file it wants. Maybe it was looking at AI video production and all it needed to know was 11 Labs.
Speaker A
It still would have read this entire file first. And so that's where sometimes the knowledge graph is actually more lightweight in that sense.
Speaker A
And this is the example I showed at the beginning of the video where we have light rag. And forgive me, I'm going to have to blur some of this stuff out cuz this is like legitimately my entire second brain and our business. But as I
Speaker A
really zoom in here, and this kind of slows down my computer cuz there's so much. But what you'll notice is that we actually start to get relationships. I probably shouldn't have done this with so much data, but you can see like we
Speaker A
have this collaborates with that. We have this builds that. And so if I really started to open up all of these little, you know, circles, we could see what was going on and how they're all related. We can see that our 7-day AIS
Speaker A
challenge. It was provided from YouTube. It connects to the onboarding process of AIS Plus. It was developed by Aiden. And so we can basically follow around these relationships as you see. And even though it's pretty much the same data
Speaker A
that you see here in Obsidian, we're not getting that same level of relationships between these different entities. So anyways, if you guys want to see, you know, a full breakdown video on something like light rag or um graphifier or all the other solutions
Speaker A
that there are out there for more of a knowledge graph, relationship graph, then let me know. But that is kind of the difference there. So if you don't need those sort of relationship chains and you're not worried about that
Speaker A
semantic type of relationships, then you probably don't need to use something like a knowledge graph. And then level five, we have more of the always on brain OS and something like Gbrain. Gary Tan, CEO of Y Combinator, he created
Speaker A
this thing called GBrain, which pairs really well with GStack. But GBrain is kind of the idea of everything we've talked about here, wikis, routing, relationships, tools. But GBrain has kind of that always element because it is like constantly syncing and
Speaker A
refreshing memories and adding more stuff. So adding in Gbrain to something like a Hermes agent would be really, really good. You could still do it in cloud code, but you'd have to handle those crons and get all that stuff set
Speaker A
up, which is why I don't currently run GBandra at the moment, but I have been playing around with it with my Hermes agent. So, anyways, the point here is that it's very similar to everything else we've just talked about. It's just
Speaker A
having that auto updating feel, more of the autonomous always on feel. But I will say another thing that I kind of that kind of scares me about that is you have this whole dilemma of, you know, when do you have too much context and
Speaker A
when does it get to the point where it's actually doing more damage than it's doing good? And the reason I bring that up is because I am in complete control of what my second brain ingests. I will run a skill to go grab all of my meeting
Speaker A
transfers from the week. I will say, "Hey, here's something. Help me figure out like help me brainstorm about this and then let's ingest it together." And for me, I really like being in that control because in my mind, there's a
Speaker A
big difference between a few types of data. If you guys remember in my like AIOS videos, I've talked about the four C's. So, context, connections, capabilities, and cadence. And for the second brain, I mainly think about it as
Speaker A
just these first two. So, context and connections. And so, when I think of context, that's stuff like, you know, what my business has done. So, if I come into here into my my second brain, and you can see here, if I go to um up at
Speaker A
OTAAS, so OTAAS are basically just our projects for the quarter. And so here I can see all the Q1 ones, right? I can look at all those and I can click at them and see decisions that we've made
Speaker A
in the statuses. And I can also see Q2 OTAAS. So I can see what's going on here. And my second brain is able to see that because that has been basically those are locked in decisions. This is what we're doing this quarter. And then
Speaker A
I'm updating the statuses of that stuff. So that's like context. That's what's going on in the business. But when it comes to connections, if I go back to this, this is more of like the real data that isn't as evergreen. This is stuff
Speaker A
that changes. This is like Slack threads. This is emails. this is customer data and that type of data you don't want to ingest into a second brain because that's just noise then then you have to go back every month and like
Speaker A
delete old stuff. So the way that I like to think about my actual second brain is stuff that I'm not going to delete. This is stuff that is like okay in a year will it be good for me to have this
Speaker A
memory in here? Yes. Otherwise it's just adding noise. So when you're adding data into your project think about it like the context and connections. think about if this is kind of like more evergreen holistic data or if this is more things
Speaker A
that are going to change next week. So, you probably shouldn't pull it in, but you should make sure that your second brain has access to go grab it. So, that way if I said to my second brain, hey,
Speaker A
can you just take a look real quick at what John and I were talking about last week about, you know, OTAA number seven, it would first go to our OTAA file and it would search through there and it it
Speaker A
would try to find it there. If it couldn't find it there, it would look through the wiki and it would look through meeting transcripts and see what we talked about there. And if it couldn't find it there, it would finally
Speaker A
go to ClickUp itself, pull real data in from me and John's conversations and see if the answer lived there. And so that in my mind is still a second brain because I'm able to ask a vague question and the second brain knows exactly where
Speaker A
to look in what order to find that real-time data and then give me back the answer that I need. That's the question I ask myself is does this thing understand where my data lives and where to look and can it give me accurate
Speaker A
answers. So as far as finding your level, remember your whole project doesn't fit into one level. Maybe this folder is level two. Maybe this folder is level four. or maybe this folder is level three. Here are some things to
Speaker A
think about. If you are reexplaining your setup and you need to find things by exact words or files, look at level one. If you have 30 plus notes and you keep forgetting what's in them, look at level two. That's where you sort of like
Speaker A
ingest them and get that wiki with relationships. If your project is just completely whiffing on notes that you know exist and your routing isn't working, then maybe you want to look for something more like a semantic search that doesn't rely on an exact wordle
Speaker A
match. If you're looking for relationships and to be able to follow chains of questions and thoughts, then you probably want to look for something like a knowledge graph. And if you're running agents offline and you've got so much data and you want to sync up a
Speaker A
bunch of Hermes agents together, then you probably are looking for something like Level Five, something like Gbrain.
Speaker A
And another topic that I get some questions about, which I'm not going to fully address in this video, but I will briefly bring up is the fact that you are building your own second brain OS.
Speaker A
So are other people on your team. The next question is how do you actually make sure that everyone's data is syncing together and how do you have more of like your team second brain?
Speaker A
There's a lot of different ways to solve that. I think once again it's not an issue of oh do we use Google Drive or notion or GitHub or cloud plugins. I think the issue to figure out with your
Speaker A
team is how do we actually make sure that we all habit shift so that this stuff is actually useful and not just noise. How do we make sure that process owners are updating their docs and syncing their stuff there? How do we
Speaker A
make sure that other people are pulling from that rather than always just pinging the same people for questions and answers all the time? I think the adoption and the change management question is the bigger one. The tech and
Speaker A
the way it actually functionally rolls out is a little bit less. But what I do know is that you getting set up with your own first and understanding how it works, how you should route, how you should make the decisions of where the
Speaker A
data should live, that's the first hurdle. You can only solve the teamwide problem once you feel comfortable about the way you run it every single day and that it works for you. That is going to do it for today. Like I said, you guys
Speaker A
can grab all the skills and everything that you need from this free community. The link for that's down in the description. I will also include the slide deck if you guys are interested in flipping through. So, if you guys
Speaker A
enjoyed the video or you learned something new, please give it a like. It helps me out a ton. And as always, I appreciate you guys making it to the end of the video. And I will see you all in
Speaker A
the next one. Next.
Topics:AI second brainClaude codeAI automationsemantic searchdata organizationknowledge managementAI agentsfile routingautonomous AINate Herk
