13:29Mansel Scheffel · Tutorial
Claude Just Launched Live Dashboards
A walkthrough of Claude's new query-backed Dashboards feature, and how to wire one to a Supabase database so it stays live instead of freezing like an old artifact.
October 9thThe argument in one line.
Better AI output comes less from a stronger model than from a decoupled, well-organized context layer, with knowledge, live data, memory and team ownership each stored in the system built for it.
Read if. Skip if.
READ IF YOU ARE…
- A solo founder or consultant who uses Claude or ChatGPT daily and keeps re-explaining the business in every new chat.
- Someone building an AI operating system in VS Code or Claude Projects who is unsure what belongs in markdown, a database, memory or a RAG index.
- A small team of two to ten people about to share one AI workspace and worried about who can edit the company price or ideal-client file.
- An operator deciding whether to copy CRM, payment and call data into a central table like Supabase or just query live through MCP.
SKIP IF…
- You want step-by-step build instructions; this is an architecture map that defers the hands-on setup to other videos.
- You run a large enterprise with existing data governance; the advice is explicitly scoped to solo operators and teams under about ten people.
- You already run hybrid RAG, a synced context repo and a memory review loop; most of this will be review.
The full version, fast.
Generic AI output usually means the model was never briefed, not that it needs more power. Context is not one bucket: it splits into task instructions (skills), knowledge (markdown context files), data and state (databases and source systems), memory, and the working chat window, and each needs a different home. Extract it from existing docs, interviews, examples of good work, databases and past conversations, then keep it in one decoupled place such as GitHub, Notion or Google Drive so every AI app reads the same copy. Read live facts from their source systems, add a meaning file so the AI understands your tables, review memory on a schedule to keep, promote or retire it, and gate company-level changes behind an owner's approval.
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:27
01 · Why your AI answers are mediocre
Cold open: a genius with no briefing does bad work, and that is how most people use AI. Credentials and the plan to walk a pixel character from single chat to team.
00:27 – 06:44
02 · What context actually is
Same AI, different answer: the only difference is what it could read. Context splits into task instructions, knowledge, data, state, memory and the working chat window, each living in a different system.
06:44 – 10:16
03 · Getting it out of your head
Five capture methods: read existing work by connecting apps, have the AI interview you, show examples of good work, read existing databases, and mine the last 30 days of conversations.
10:16 – 15:09
04 · One home your AI can reuse
Separate copies in two apps drift apart, so keep one decoupled home. Claude Projects library, GitHub, Notion or Google Drive, three ways AI reads your stuff, and the overwrite problem that needs an audit trail and review gate.
15:09 – 24:24
05 · Data and state: the facts that change
Rules are not today's facts. Records, events, current state and history; read facts live from source systems; give the AI a meaning file; copy to a central table only for retention, cross-tool relationships or heavy repeated analysis; pick a sync mechanism per source.
24:24 – 28:56
06 · Databases, search, RAG and wikis
Three jobs: database for exact records, search for the right passage, wiki for already-worked answers. How hybrid RAG works, why most solo operators do not need it, and when context files are enough versus a compounding wiki.
28:56 – 32:50
07 · Refining memory over time
Give feedback, remove rules that now hamper the AI, and review memory on a schedule. A learned observation is not an approved rule; keep it, promote it to a skill or context file, or retire stale state.
32:50 – 39:28
08 · Running it for a team
A laptop that sleeps cannot serve a team, so go cloud-first. Company, role and personal context with separate ownership and access, a Notion layout example, RBAC, the owner's yes for company facts, and the closing principle: rent the AI, own what it works from.
Lines worth screenshotting.
- Two identical AI models give very different answers when only one of them can read your offer, price and voice.
- Many people reach for a bigger model like Opus when the real fix is clearer information fed to a smaller one.
- Context is six separate things: task instructions, knowledge, data, state, memory and the working chat, and each lives in a different system.
- A skill file is an employee handbook for a repeatable workflow, including what good looks like and known failure patterns.
- Thirty days of past AI conversations is an untapped source of context; ask the AI to find patterns and problems you keep raising but never solve.
- Uploading separate copies of your context into Claude and ChatGPT guarantees they drift apart, so keep one decoupled home every app reads from.
- Every fact about a client is stale the moment you write it down, so live facts should be read from the source system, not copied to markdown.
- Your CRM stays the single source of truth even if you later copy its data into a central database for analysis.
- A short meaning file that explains your tables, fields and statuses stops the AI from guessing what each row represents.
- Copy data into your own central table only for long retention, cross-tool relationships or heavy repeated analysis; one-off questions can go live through MCP.
- Putting simple lookups like a customer name into a RAG vector database is overkill; an exact-match database query does that job.
- Pure vector search confuses things that mean similar but are not the same, which is why hybrid search adds exact keyword matching.
- A wiki is only worth building when a topic keeps growing with new sources and each addition should sharpen the distilled answer.
- A learned observation is not automatically an approved rule; check its source, confidence and scope before keeping it.
- Memory that captured temporary state, like an unpaid invoice, becomes pointless the moment the client pays and should be retired.
- Recurring memory habits that belong to a workflow should be promoted into a skill so they load only when invoked.
- On a team, controlling what a person's AI can access is the same as controlling what that person can access, so role-based permissions do double duty.
- Changing a company-level fact such as a price can break every automation attached to it, so it needs the owner's approval.
- Rent the AI model, own the context layer it works from.
Fix the briefing before you upgrade the model.
WHAT TO LEARN
AI output tracks what the model can read, so split your context into the right systems, keep one decoupled copy, read live facts at the source and review memory on a schedule.
02What context actually is
- Two copies of the same model give different answers when only one can read your offer, price and voice, so check the briefing before blaming the model.
- Treat context as six inputs (instructions, knowledge, data, state, memory, the live chat) and store each in the system suited to it.
- Write repeatable workflows as skill files that include steps, examples of good output and known failure patterns, like an employee handbook.
03Getting it out of your head
- Connect the tools where your knowledge already lives, such as Google Drive, Gmail, Slack and Notion, before writing anything from scratch.
- Have the AI interview you on one area at a time and save the answers as small context files.
- Ask the AI to review your last 30 days of conversations for recurring problems, preferences and inefficiencies you never captured.
04One home your AI can reuse
- Keep one decoupled home for context, such as GitHub, Notion or Google Drive, because separate uploads to different AI apps drift apart.
- Require an audit trail and a human review gate before shared knowledge files get overwritten, especially when several people write to them.
05Data and state: the facts that change
- Read client facts live from the CRM, payment and calendar systems, because any fact copied into a document goes stale.
- Add a short meaning file explaining your tables, fields, statuses and relationships so the AI does not guess what the data represents.
- Copy data into a central table only for long retention, cross-tool relationships or heavy repeated analysis, and give each source one sync mechanism with a last-synced time.
06Databases, search, RAG and wikis
- Use a database for exact records, hybrid RAG for finding passages across large document sets, and plain context files for everything else.
- Build a wiki only for topics that keep growing with new sources, so each addition sharpens the distilled answer instead of piling up notes.
07Refining memory over time
- Tell the AI when it repeats something you dislike, and delete old rules that now get in the way.
- Review memory on a schedule: keep only high-level conversational facts, promote workflow habits into skills or context files, and retire stale state like a since-paid invoice.
08Running it for a team
- Split team context into company, role and personal layers, and decide separately who can change each one and who can use it.
- Use role-based access so a person's AI can only reach what that person can reach.
- Require the owner's approval before anyone changes company facts like prices, since one edit can break every automation that depends on it.
Terms worth knowing.
- Context layer
- The full set of information an AI can read when doing a task: instructions, business knowledge, live data, memory and the current conversation, organized so any AI app can reuse it.
- Skill (SKILL.md)
- A markdown instruction file describing a tested, repeatable workflow, including steps, examples of good output and known failure patterns, which the AI loads when the task is invoked.
- State
- Information that changes over time, such as a deal stage, ticket status or whether an invoice is paid, usually stored in a database rather than a static document.
- Decoupled storage
- Keeping your context in a neutral location like GitHub, Notion or Google Drive instead of inside one AI vendor's app, so every model reads the same single copy.
- MCP (Model Context Protocol)
- A standard way for AI apps like Claude to connect to external tools and data sources so they can read and act on live information.
- Context map (meaning file)
- A short document, often markdown or JSON, that explains what each table, field and status in your data means and how records relate across systems.
- RAG (retrieval-augmented generation)
- A method where documents are split into chunks and indexed, the most relevant chunks are retrieved for a question, and the AI answers from them with citations.
- Vector database
- A store that represents text as numeric coordinates by meaning, so a search finds passages that are conceptually similar rather than literally matching.
- Hybrid search
- Retrieval that combines meaning-based vector search with exact keyword search to improve accuracy when similar-sounding concepts differ.
- RBAC (role-based access control)
- A permission model where access to files or pages is granted by role, such as owner, sales team member or individual, rather than person by person.
- Webhook
- An automatic message one system sends to another the moment an event happens, such as a payment clearing, instead of waiting for a scheduled check.
Things they pointed at.
00:20productClaude Certified Architect
02:30toolVS Code
02:30toolClaude Code
07:50toolGoogle Drive, Slack, Gmail and Notion connectors in Claude
11:30toolClaude Projects library
11:40toolGitHub
12:15toolNotion
21:40toolSupabase
22:20toolSQLite
25:00linkAndrej Karpathy's LLM wiki idea
33:10toolClickUp / Microsoft SharePoint
Lines you could clip.
00:00
“So you've hired a genius, given them absolutely no briefing, and now you're wondering why the work is terrible.”
01:15
“A lot of people often confuse that they need more power of the model when in fact, they just need to be clear with the information that they're actually feeding the agent.”
17:50
“Every time you've actually made some form of fact, they are pretty much stale the moment that you make them.”
24:31
“You don't want to store simple information inside some kind of rag database. That would be absolutely ridiculous, despite what the YouTube kiddies tell you.”
34:05
“In controlling what John's AI model can do, you're essentially controlling what he can do.”
38:30
“Just rent the AI and own what it works from.”
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
So , and now you're wondering why the work is terrible. That's actually how a lot of people use AI right now. So today, we're going to demystify the entirety of what makes a business brand by walking this little guy from a single chat to an entire team using a shared context and data layer.
For those of you who don't know me, my name is Mansell. I've been consulting for Fortune 100 and 500 companies over the last 12 years. I built two consultancies in that time, and I'm also a Claude Certified Architect.
Let's get into it. Okay, so context can be a pretty long game, but it's one of the most important things, if not the most important thing for any AI model, because without your context, you'll soon see that the AI is pretty much useless. useless to you.
So as a part of trying to demystify this whole thing, I thought I would turn it into some kind of little adventure that we can go on with our little pixel character over here to walk you through the stages from right at the first steps that you're going to take all the way through to doing this as a team. So first things first, you can have two AI models sitting right next to each other and you'll have one without any of the information about who you are and what you're actually trying to achieve and the other one with this little bucket filled with all of the things that your business is and who you might be trying to reach out to.
And in doing so, you're going to get a lot more value out of the AI that you're actually using. And this is a very important thing to understand because what goes into our context ultimately forms what we get out of our AI model. And you'd be surprised by just how much you can actually get out of models if you have the right amount of context and data and all of the things that you need.
You might not even need Opus or something like that to achieve a specific goal. A lot of people often confuse that they need more power of the model when in fact, they just need to be clear with the information that they're actually feeding the agent. So when we're looking at context, what actually goes inside context.
That might be things like business facts, your voice and your preferences for the way that you work and speak. And if you're creating content, of course, if you're writing some form of script, you would want your voice to be able to cater for that. There are also rules and belief systems that you have within your business or your personal values that you might want to portray in the model.
It could also be your methods and your definitions of doing things. There are so many things that form context and we'll get into those soon. But first, we need to not just lump everything into one box called context, because that really confuses a lot of people thinking that it all needs to be stashed in the same place.
Realistically, context and memory, as a lot of people call it, it all sits inside different systems. And when we understand what types of systems this information needs to live in, it means we're going to have a clearer understanding of the types of systems that we should be building. And also what we can get away with when we're trying to manipulate things that don't exist yet for us.
And it would probably be a good idea to talk about some of these different forms of context. over here. The first one being task and instructions and this is usually the information that comes out of your head that you're turning into some form of repeatable process aka a skill and inside our skill .md for those of you who don't know it's literally just an instruction manual of what we are trying to get the AI to do.
It is a repeated workflow that we know is good and we have ideally tested it end -to -end to do the same thing over and over again. It's basically like giving a new employee a handbook on exactly what to do and inside here we have context. It's not just context engineering by giving it these exact steps and the information that it might need to pass through systems.
But we also have references of what good looks like, what failure patterns it might encounter in here and how it could get over them from historical runs. You might have specific frameworks or methodologies that you wanted to follow. This forms part of context.
The second thing that we have over here is knowledge. And this is the stuff that already lives in your head. Generally, we're going to be pulling this stuff out for our AI operating system and stashing it in a context folder.
And you'll see as we get through this journey, there'll be a bunch of places that we store this folder. For mine, it just lives here inside VS Code. But inside here, you'll see all of these knowledge folders in here around marketing, my brand, my go -to market strategy, and all of these folders that my AI operating system needs in order to extract knowledge that either I know or a system knows.
And that's part of this game, right? We have various methodologies of getting this out that we'll explore very soon. But without this, the AI wouldn't be smart at all in solving any of my business problems.
The third thing here is data. And this is important to understand because it's not as simple as these simple markdown files that we have over here. Data lives inside pretty much every single system out there.
And with this data, we can make business -driven decisions. We can figure out what our customers do over time. We can understand how our business is doing over time.
And data generally lives inside a database. It's kind of in the name. So we wouldn't just stash this in a normal markdown file, even though we could.
It's probably not going to be the most efficient way to do this, especially when you're dealing with vast amounts of data. And that ties in with state, because state generally lives inside a database. And although, again, it forms part of context, it's a very different thing.
If I have a whole bunch of leads inside a CRM and they're currently going through stages of in progress, won, lost, closed, whatever it might be, that state changes. And we're not just going to go and stash that in a markdown file.
We're going to have that in the database, mostly because the dynamic way of the state being handled. Then next up, we have memory. And this is kind of the blanket term that everybody uses for your AI remembering something that you had.
But realistically, as you've seen by now, all of these are technically a form of memory because the AI can go and read any of this and remember or know something about you. way of working. So the way that I view memory is every time I come into my VS Code or something and I have a conversation with Claude, while working with it, it will remember certain things about me.
I could either ask it to blatantly remember something or it would pick out patterns that it learns about me over time and stashes it inside a simple file called memory .md that lives inside my AI operating system. The majority of the frontier models out there have their own form of memory that are being stashed inside their desktop apps.
They are trying to make these better and better over time. But for me, there's a very important thing to think about with these memory systems that they have. If everything is living inside a simple memory .md file, surely it creates a cluttered problem where we have these memories living in there and we don't even know if they should be there anymore.
So my idea with memory is, if the AI learns something about me, what I like to do is refine my memory .md and come back to my memories every now and then to understand what we actually have stored and whether it just belongs in that simple file Or did it actually pick up something in one of the skills that we have and say, hmm, well, you know, this ICP that we spoke about once, a few things have actually changed about them.
We need to go and update our skill and our knowledge files inside context and maybe update a database as well. That's a lot better for your system over time than just simply having a memory living inside a memory .md file somewhere. Then finally on this, we have our working context.
And that's literally your chat window that you're working in. All of the information that is currently stashed in this conversation that you're having now, all of the tools that it has pulled in, your previous conversation, conversation history and things like that that obviously forms a part of this context and being able to manipulate this Effectively means not only do we get more out of the current conversation that we're having but more accurate results based on that conversation So you can see from these six little bubbles that although context refers to pretty much everything here It's actually made up of all of these separate moving parts that we can manipulate in certain ways to get better results The next logical question then is cool.
All of this information is trapped in my head perhaps even systems. How do I get it out of there? And that brings us into breaking our first roadblock.
It can be really enticing to just rush through everything and try and make a system work because AI has essentially destroyed our attention span. But the one thing that you shouldn't skip is this context layer because once you get all of this information into a system, everything else can easily 10X because it already knows everything about you, your clients, and all of the things that I've mentioned.
And there are various ways that we can get that information. I have deep dives into all of these things I'm about to speak about that I'll link down below. It's important that you understand how we can do this.
The first one being is to read any existing work. So anything that you have written down somewhere in documentation, maybe you've got stuff stashed in Notion as a business, maybe you have some notes in a notepad somewhere, just connect all of that. All you need to do is go into your Claude account.
and connect all of your apps. This is really as easy as that. If you have things stashed inside Google Drive, that's one of the best things to connect.
Of course, anywhere where you're stashing documentation, it could be Slack, it could be Gmail, and there are several things that we can get out of these systems apart from business context or information. you can also get your writing style from gmail inside slack as well of course you have dms inside there and then also if you have notion perhaps you split things into personal work and also actual work in which case you have more context that you can pull out of there so your existing systems are one of the best things to do the second thing here is pretty obvious we could just ask the ai to interview us relentlessly on a specific area within our business or about who we are so that it can extract that information for us and then stash it as a simple file inside our context folder.
I have a bunch of skills that I'll link down below for this as well. The third thing here is to show what good work actually looks like. So what we're doing here is we're showing the AI exactly how we want something done or what a definition of done might look like.
And if we come on back to Claude over here, you'll notice that we have that inside our skills folder. For instance, here, if we look at my thumbnail generator, all I've done is found my most successful videos and then pulled those thumbnails down to stash them in here. So every time I want Claude or ChatGPT to make me a new thumbnail, all I have to do is show it one of these examples and say, cool, let's go with this one in this style and that way it knows exactly what to generate me human on the side with the folder and then whatever the text is over here that we might change so these are shortcuts for getting to done a lot faster the fourth thing here is any existing databases that you have remember data is separate to what might be living inside these things And with the information that we get from our databases, we can learn a whole lot about all of our customers, perhaps the systems that we have connected and the intricate nature of how our business has changed over time.
This can include things like your financial state so that you can either predict where you're going or figure out what's currently going wrong. If you have a YouTube channel, it could be metrics from your best performing videos, what people like, how long they stick around for. Those are the types of things that we're pulling out from various systems to help us make data -driven decisions, which in turn tie in with content to make our system smarter.
The final thing over here is to review work that you've already done. So after you've been doing this for a little while, you will have at least 30 days worth of discussions that you can grab inside Claude. And literally all you have to do is come down here and say, hey, can you figure out patterns from the last 30 days of discussions that we've been having?
Find out things that I keep talking about and I never solve. Tell me about my way of working and how could I be more efficient? There is so much information that you don't even realize you have in the previous conversations that you've had with Claude because you weren't really thinking about that at the time that you were solving another problem.
But now you can come into it with a fresh lens and literally go and audit your entire environment to review and extract new information. There is something that we need to think about here. And that is if you upload separate copies into two different apps.
your issue can be that these apps would drift apart so one of the most useful things that we can do to solve this is ensure that wherever we're keeping our context it's a decoupled centralized place for instance you wouldn't want to work inside claude with your own little context bubble and have the same thing inside chat gpt but a separate context bubble because then which one is the right one and you'd have to figure out a way to merge them so it's much better to think about this up front and we solve for this during our architecture phase when we're building our context layer so decoupled is the answer that we want to lead with here and you can see how straightforward it is.
Really every single one of these frontier models can connect to our central repo over here. There are a ton of approaches you can take with this and it's really quite simple to solve as you'll soon see. For me when I'm trying to solve something with my AI I'm pretty technical so I just do everything inside VS Code as I'm sure you've seen by now.
This simple folder over here called context, it gets synced up to every single AI app that I use. I just use something called GitHub. You absolutely do not need to do this or even think about this if you're non -technical and don't want to go down that route.
But we do need to think about this because it's very important. So if it's just you flying solo and you're quite technical, then taking my approach is probably going to be your best bet at a decoupled layer right now. If you really didn't care about the whole lock -in thing, because it's really not that bad at the end of the day, what you could do is just use Claude's native projects because inside here they've actually got a library that we can use if we click across to the library tab over here you can see that we can easily upload context and then claude's project will have this natively inside here we could also upload folders and add google drive folders if we wanted to that means that claude could use this whether we're on our phone or whether we're on our computer providing we weren't just connecting a local folder to this and everything that we were using was actually going to the cloud but i imagine for a lot of you that doesn't really sit well with you so the second approach is to find something that sits in the middle for me i chose github because
because it's really not that difficult, but you could use anything. You could use Notion, you could use Google Drive, you could use Dropbox. Whatever makes sense as a cloud provider so that you have something that's always on, but then also isn't one of the frontier models so that it's decoupled and can be used anywhere.
Each of these solutions has their own pros and cons that we'll talk about in another video. But right now, all you need to understand is the concept behind it. We are just decoupling ourselves from those frontier models with another cloud provider.
Something that I do want to mention quickly is that Notion is fantastic if you're on a team. Of course, this was already built for teams and because we can just connect to it with MCP, it's one of the easiest ways for your... AI model to work with whatever your team is doing natively inside Notion.
It's also cloud -based and it's decoupled. So it's a really good solution for those of you working with teams. When we're trying to choose one of these apps, there are a few things that we need to think about.
The first one being that AI reads your things from various locations and how you're currently working is going to affect that. For instance, if we upload something to the cloud, we're doing that because we want something that is always available. pretty much anywhere on any device.
That's why we have cloud storage. Also because it's safe and we're outsourcing all of that liability to someone else in the hopes that their data center will keep our stuff always online. But it does provide us the added benefit of not having to have a MacBook stashed somewhere in the corner of our room that's always on.
So that's why I always opt for a cloud solution. Our second option over here is really straightforward. We're literally just linking a folder from our local computer.
The third option here is to connect an external app. And again here, this is really simple because we're just using AI to connect to any of the tools that we already use every single day.
So these are three separate ways that we can get AI to interact with our information or our context, and each of them piggybacks off of a way that we actually need to work in our business. The second thing that we need to understand here when we're trying to choose a system is that if the AI just keeps overwriting pages, that can be problematic, especially if you're working with someone else.
Because think about it, if you've developed something about who your ideal client is, But then Sarah working next to you went and updated that ideal client as well inside the same workspace, but never told anyone. That would be problematic for the rest of the team because you guys would be working off of someone else's data instead of what you think that ideal client is.
So what we need when we're looking at a system to store the information is to have some form of record of who did what and when they did it, like an audit trail. And that again is why Notion is so great because it's built for teams and collaboration. You can see those sorts of things quite easily as opposed to just having all of this stuff stored in Google Drive.
Yes, you do have version history and a few other things but it's not as straightforward as in Notion where you can literally see these things in real time. This is where we can kind of piggyback off of what Git does over here and you have some form of approval before anything gets overwritten. So you have that human review gate and I think you should be doing that no matter what system you choose because if your team are all working together it's important that they're in sync.
You don't want them to be editing global knowledge files that everyone in the team is using without anyone in the team knowing about it except the person making that change. So solving this problem isn't only up to the tool but also up to the way that you work with your team every time someone makes a change that team should be notified saying hey we went and updated this file make sure everyone is aware of that and then people give it a thumbs up and everybody carries on doing their soulless work okay and so as we make our way further into this we need to understand what happened next because The AI now knows our business, but what happens for the things that change over time?
This brings us into state and data and how it all ties together to form our little context picture over here. So if we look at the context section that we just covered, we have our price and our offer, our voice and our examples from previous emails that we might have sent, any rules about how we write these emails and the methods for writing them.
Those form part of our simple markdown files that are basically the knowledge of the system. It feeds the context and it also tells us how should we actually write this email. What it doesn't do though is tell us what is true for this customer right now.
In this moment that we're about to reach out to this human, a lot of things could have changed from last week even. And that's where changing business data comes into play, where you have your customers and your invoice records, calls that you might have had with them and things that happened on those calls, more information that you pulled out from those calls.
What is the status of this client right now? What are they waiting for? What do they need you for?
feeds the type of email that we will put in our follow -up and you can see if all we had was this stuff on the left hand side here our original knowledge it wouldn't really help us follow up much which is why this changing business data is so important to keep harvesting from each of the systems that we're using as we use them ultimately leading to the point that both of these become context when the AI needs to use them for something and so if we take a look at what's actually inside our data you'll see that we have records over here which is your customers your invoices any tickets that you have open and they live inside a simple little database that just lists them line by line but then if we wanted to paint an even better picture for the business what we could do is we could take these records and we could attach events to them so we could have hey we had a call with this person on the 24th of july this invoice was sent and this was the result of the call ultimately it led to them paying you could tell a whole journey just by using data that we could then use later on
as a part of our system. More importantly, it tells us the current state of events with a particular client that we have up at the top over here. Do they have anything open?
Are they late on payments? All of these things lead into other systems where we need to take actions as a business to solve the problems that we might be facing. And you can see how this cascades, especially if you're monitoring your company financials.
It's important to be able to do this because the more we know about our clients who aren't paying us, the more we can understand our financial picture. And then finally, as a part of this, the history of what happened and when did it happen and Why did it happen?
Retaining this history over time is very important, again, for that long -term view that we want as a business. Some of these systems will let you keep data for quite a long time, but a lot of them do actually cull your data, especially if you're on a free plan. So it's important to understand your needs behind this.
How long do you need this data for? And does the system that you're either paying for or not paying for cater for that? There's something really important to remember here, and that's every time you've actually made some form of fact, they are pretty much stale the moment that you make them, especially if they're about clients and things like that.
Because I could have a call with someone today, five days from now, their situation could change entirely. So it's important that we read our information live as often as we can from specific systems. And of course, Claude has made this so ridiculous easy now with mcp you can literally look into any single system that you want and build entire dashboards around them just by asking claude to do that there is something important to know about this though even though at some point we might want to create some kind of central storage for all of the data from all of these systems we never want to deviate from these systems as being the single source of truth for instance i don't want to take data out of my crm and go and stash it in a markdown file somewhere and then tell the ai to go and always read that markdown file i think that's a terrible approach because your CRM is the source of truth.
This is where all of your information for the whole company comes in. So always remember that today's facts is in the information that you need now should always live in its source system despite what you're doing with this data later on. And so as we continue our journey, we hit another roadblock over here where we can have all of these rows and these numbers inside a database.
And sure, to some degree, the AI can figure out what they mean, but that doesn't mean that we shouldn't give it a hand. And we can easily do that by giving it some form of map or some form of map to meaning so that all of this data that we have inside our systems... that we are querying, we can give it a context map over here, which could just be a simple markdown file, maybe a JSON file, depending on what it is that you're building, with the idea being that this context map over here explains what our data is to the AI, so it doesn't have to guess every single time.
And again, you can think of this just like showing an employee this. They could go and look at a database. If you told them absolutely nothing about it, they would look at you funny and make their own assumptions of what this might mean.
But if we gave them a very clear picture of what each row represents, it's in there what we're trying to do with it and how it links to other systems the employee would be far more efficient at doing a specific job that we wanted to in this case it's our AI for AI analysis on all of our business and this is a really common pattern right now a lot of people don't think about these sort of things because they think AI is this really technical machine that they need to understand and to some degree of course that's true But if you just take the time to think about this as person to person, what would you need to give to a person in order for them to understand how to do this job at the best of their ability?
At every step that you're taking in your system when you're building something, If you think about it from that perspective, you're going to get clearer results every single time. Okay, and then next up, we need to think about getting this data out of these systems that we have scattered everywhere.
Because while we can use AI to go and read all of these separate systems out there to gather this stuff, wouldn't it be great if we had a central repository that we could store all of this meaningful data in and then use that central repo to go and query things? And that's definitely a good idea, but not for every single occasion, especially if you're just doing like a one -off query or something that you're not looking for over a long period of time.
So when we want to copy that data out of all these systems to a central database, it's usually going to be when the history inside those systems doesn't keep it there that long, like I mentioned earlier on in this video. We would be able to create our own retention scheme inside a database. Think of Superbase.
We could keep that data for up to a year or even more if we wanted to or needed to. The second thing here is relationships across tools. So instead of me having to go into every single tool every time to figure out how they relate to one another from a data perspective, we could build our central database to store all of that information in one single place and attach meaning and relationships to those specific tools.
So for instance, you could have a CRM with a client and then you could have your payment system like Stripe to see if this person paid you. And you can see that over time to see how many recurring payments there were. Again, it's not that we can't do that live.
It's just that if we wanted this at scale over time, it could make more sense for us to have some form of central repository. But for most of these, I think at the end of the day, if somebody did want the central repo, it's usually going to come down to heavy repeated analysis.
I certainly wouldn't build this type of thing if I'm going to be querying something once a week, sure. Just run out there via MCP and go and figure out this information for me. But if you're trying to figure out these patterns over a long period of time, say every other day, that's when having this type of thing definitely makes sense.
That brings us on to the next question of where should this table live, this database that... building for our data. For a lot of people, I think Superbase or something like that in the cloud is probably going to make the most sense.
They do have a pretty good free tier for most very small businesses, of course. the more data you store, you're eventually going to have to pay for a plan, especially if you're going to be keeping that data for a long period of time. But for those of you flying solo and you don't need something that's always online, SQLite works perfectly fine inside VS Code.
I've been using that for ages, though right now I am moving across to Superbase because I've got so much data that I want to use in so many different systems. And I think it just makes far more sense for me to have, again, that decoupled layer that's always online, regardless of where I need it. I think it helps me move between ChatGPT, Claude, and Grokbot.
depending on what they need but like most things it should always stem from a use case then there's something else we need to think about here and that's scheduling because you know you do this thing once okay but how often do you need this information surely if you're trying to stay on track with your business and make sure everything is up to date you want to be doing this repeatedly So, for things like a CRM, you could be doing this type of thing on a schedule where we're pulling this information down and building our meaningful data map.
For payments, you might want that thing to happen the moment that the payment takes place. You update our table over here and say, hey, this client has paid. Everything is on time.
For calls, this is very important. You might want to analyze that call as soon as it's happened and stash any relevant information about your client as fast as possible. Something to note about these calls though is that while it might update a table and some of the things that you have stashed in there, it could also change the knowledge that you have about a client which might just live inside those markdown files we used at the beginning of this video.
And then the fourth thing here is outside reviews. So if your business relies heavily on Google reviews or Trustpilot or something, you would want to be pulling those things in maybe every other day, potentially every week, that you can see where your company was trending over time and obviously take action as fast as possible.
So what we're trying to understand here is the mechanism that we need to get this data out? Is it just a simple scheduled task?
Do we need some form of webhook to set up for this? In which case, with Claude, we might have a bit of problems at the moment because Claude doesn't have any native webhook ability. There are ways around that, as I've shown in other videos, but this is more just to help you understand the architectural decisions that you need to make.
And of course, you can ask Claude about this while it's analyzing your systems. You can get it to come up with ideas of how often you should be pulling information out of these systems and what the mechanism should be behind it. Okay, so we understand context, we understand data and state, but now we need to understand how to kind of store all of these structured records so that we can get them out accurately.
And there are various systems that we can use for this. I'm sure you've heard of a lot of these, but we really need to nail this thing down because you don't want to store simple information inside some kind of rag database. That would be absolutely ridiculous, despite what the YouTube kiddies tell you.
So at a very high level, you might have three different jobs that we're trying to achieve here. We have a database, which is to find exact records. For instance, name equals John Smith.
If we had to go and search that from a database, it would go and find that exact name. Then you can have search, where we are searching for a specific passage within a body of information.
And we'll get to that soon. The third thing here is a wiki as made famous by Andrej Karpathy, which is essentially just gathering all of the information that we already have answers to and then stashing it in a logical way that our AI can read quite efficiently. But each of these things has a different place in the job that it's trying to solve.
The first thing here is if we have a needle in a haystack, if you have vast amounts of information, it must be inside somewhere. And that's where RAG really comes into play, where you're trying to find relevant sources for something across a lot body of work definitely with citations so that you know accuracy is improved and really a lot of the time this is more of a hybrid architecture we don't need to get into the weeds of that but rag isn't as simple as everybody paints it out to be at a very high level rag works by taking your documents and chopping it up into things called chunks then it stores it in something called a vector database which is essentially a place that stores your stuff as meaning in mathematical space so if somebody's talking about let's just say advice on fishing, that might live down here in this meaning space.
But if somebody is asking about a cooking book, that might live somewhere up here in the meaning space. And what it's doing is it's searching for these things within these meaning spaces, as opposed to looking for things literally. And that's why I mentioned this hybrid approach, because while that is great, it can be a little bit inaccurate, especially if you have things that mean the same thing, but aren't the same thing.
So by having a hybrid approach over here, what we allow ourselves to do is search for things by meaning, but then have this added accuracy by having exact word keyword search. So in the same way that we would go and look for John Smith in our database, if we wanted to go and find something related to John Smith in our meaning structure over here, we would combine both this meaning structure with the exact keywords that we were looking for.
So your user journey with RAG would be asking your question. It then goes and queries both the meaning and the exact words. It looks for the top chunks that match whatever it is that you're looking for, sends it back to you in your window, and then it shows you the answer with it.
source ideally some citations so that you know everything that's in front of you is accurate for a lot of people you absolutely do not need rag at all you can solve a lot of the problems especially if you're a solo founder or small business just by using a simple database or even having some of the things that we've spoken about already But just because that's the case doesn't mean that we can store everything inside a wiki.
And that brings us into our second part over here, which is context files versus a wiki. Because for a lot of you guys, just having these simple context files that you're updating when they need to be updated, it's going to be more than enough. But saying that, a wiki can be entirely useful, especially if you have specific topics that you talk over a lot and new information gets added and it grows and grows and grows so that you can keep talking about it.
So if we look at our little table over here, you can see that our context is written either by the human or the AI drafts and we approve. It holds our rules and all of the things that we spoke about already.
It changes whenever the business changes and its size is usually going to be small. You're not going to have massively long markdown files because the information that you realistically need for most of your systems is small and it's chunked down in various files. When it comes to a wiki, this is usually going to come from the AI doing the work for you from the sources.
For instance, I turned my entire YouTube channel into a wiki so it knows all of my long -form stuff and my opinions, all of my answers, all of my information on how I view AI and the world that I'm speaking about and in doing so it distills it into this wiki that I can use for specific topics. So all of those sources for instance if I have seven videos on building an AI operating system and how I think it should all work Those would be a specific topic inside my wiki and it would have all of my opinions and viewpoints and thoughts on how I build this and deal with it and sell it to clients and things like that.
And this will always change whenever I add a new source. So just because you have a bunch of context files absolutely doesn't mean that you need a wiki at all. I would only bother getting a wiki when you have specific things that compound over time on similar topics.
The idea here is that we're trying to make our answers better each time we add a new source, more accurate, with more information, but not hoarding all of this information. distilling it into better and better answers. Okay, so now we know what context is, what data is.
We kind of know where we should be storing data because for the most part you're going to be storing it in either context files or just a simple database like Superbase with RAG being something that you would know when you need it in which case you go and find one of my other videos on that. But right now we need to focus on how to refine what we already have.
Because like I said, you don't build once and everything's just fine forever. You need to keep iterating. Your system always improves.
And one of the first things that you need to do is make sure that you are working with the AI over time. If there are things that it keeps doing that you absolutely hate, tell it to stop doing that because I have that problem all the time. And originally it was just because I never gave this system feedback.
The moment I started saying, why are we still doing this? Why is it done this way? And asking questions.
We started to develop better rules inside the AI operating system so that it could function better. Maybe you need to go and update a skill that you've written. Maybe you just need to change a way that you are actually working with the AI model.
Or maybe you even need to remove rules because some of the rules that you previously made are now hampering down on the way that the AI actually needs to do the job, which is a massive problem for a lot of people at the moment. Point is here, anything that the AI has learned about you over time doesn't mean that it should always be there, like I mentioned earlier.
Now, depending on what system you're using for your native clause, memory it could be stashed in many places if you're in vs code it's in a simple memory .md file within claude if you're inside the desktop app of claude it's inside your memory file over here so you would just click on settings and then go to your claude and then come and have a look at your memory and click Manage.
Inside here, you'll see all of your memories that this thing has harvested from you over time. So all you have to do is either delete a memory or edit a memory. And if you want to do something even simpler, set up a recurring schedule to go through these memories with Claude.
You could say, cool, it's been 60 days. We've been working together. Are any of these memories actually still useful?
Do they need to be moved to a skill? Should we update a specific part of our system? The point being is that we want to turn them into something else, not just leave them rotting inside that memory .md.
So for me, when I look at this memory .md file, I break it down into chunks just like we did with everything else. So the things that I actually keep in memory are things that just make the AI more conversational with me or high -level things. that it needs to always, regardless of whatever we're doing, remember about me.
That could potentially be my name. It could be my business, what my business is about. Again, at a very high level.
I'm not talking context file in -depth stuff here. Basically, useful observation that's just going to help the AI. do a better job with the least amount of input for specific lanes.
It would be amazing if these things could remember absolutely everything, but they don't, which is why we need to tune this thing and make sure that you're only keeping useful things in here. And then otherwise, putting these into other files, like a context profile. If I really wanted an in -depth analysis on who I am, my favorite color, my entire life story, and every specific thing, that's when I would look to pump some of these memories into Markdown files.
maybe even create some kind of arrogant, self -centered wiki of myself so that AI knows absolutely everything about me. That would be one way to do it, right? The other thing that we could do is go and change our skills and our processes.
Like I keep saying, something stashed in the memory, if it forms part of a daily workflow, perhaps that should be a skill instead of being stashed there so that it only gets invoked on command when it needs to. Something else is that sometimes the AI can go and take something that is actually staked. For instance, if you're dealing with something in the moment, let's just say a client and they haven't paid you yet.
There are some times where the AI might actually go and make a memory out of that, in which case it's completely pointless, because what does it do after that? Okay, cool, now this client's paid, and you don't need to care about this anymore, and yet it's still stashed inside its memory .md. So like I said, reviewing is important because of that, because ultimately, you might just need to remove stale stuff that no longer needs to be in there at all.
So our cycle is very simple. We observe, we review, and then we just have a decision of whether to keep, promote, or retire. And that way, we always have a fresh memory, but more importantly, again, a better working system because all of the information is exactly where it should be.
And this kind of thing can be totally automated. You don't have to keep doing it manually. You can set up a schedule to do it.
And now as we progress to the final part of our journey over here, we've gone from kind of working as a single person to working as some form of a team. This definitely isn't the right approach for every single team out there, especially if you're a very large team, but certainly for small teams of two to even 10 people, this type of approach can work quite well.
I definitely think when we get to this point that you can no longer just be vibing off of a laptop that sometimes stays open or not that's not going to serve your team very well which again is why all of these frontier models are building some form of cloud infrastructure everybody thinks it's a bad thing and they're all going to get locked in but vendor lock -in is really minimal with AI right now because most of the stuff is universal and you can easily connect your context without ever having to worry about it.
But definitely when working with a team, a cloud -first approach is going to be the best way to go. You don't want to be running on a laptop anymore. But in the way that we actually view or use context needs to change because it's no longer just us.
I can no longer just come into VS Code and do whatever the hell I want to any of these files because now my actions have greater consequences. I know my business. I know everything about me and what I'm changing.
But if I do this and I don't tell anyone on my team, they're not going to know what the hell to do when the AI outputs some kind of information that they view as wrong because I didn't tell them about the changes. So we need to cater for this and we need to think about it in the architecture that we put forward to our business.
And when we do that, we break it down into specific chunks. So we have our company -wide context over here. For most of you, this would probably be something like the offer that you're putting in front of clients, the prices that you have, the policies that you might have as a business.
This is all maintained by the business. No single person should be going in there and just randomly updating things without anyone else knowing about it. If a change needs to happen at a company level, it should be put forward to a bunch of people and those bunch of people should review it before they approve it because it's going to affect every part of the system.
Something to note on company, it could be the entire company, but then you could have a sublayer to that for a sales department or a marketing department. because they might have their own specific context that is still company -wide or department -wide in that case, which again would have the same rules if you wouldn't want one single person going and screwing things up for an entire department.
Then secondly, you have role, and this is where you have specific playbooks for specific teams. You might have specific duties that people on a specific team might fulfill. You might have managers that have access to specific context, and only they should have access to that.
in which case you wouldn't, again, want these personal people going and changing that. So what we're saying here is that company is maintained for the entire business or department. The role is maintained for a specific job within the company or that department.
And then finally, we have personal, and that's pretty self -explanatory at this point. That is, say, John and Sarah both working in this company. They would have their own voice.
They would have their own preferences, their own private notes, and they would certainly have their own AI operating system. Again, probably be inside Claude with a desktop app or something, but everything is pretty much... much the same over here.
They would still have their markdown context files just for them. And then the business as a whole would connect to this company repository, which would have that larger body of information. realistically as a team that's probably going to be something like notion maybe click up if you're an even larger company it might be microsoft sharepoint the point is you would no longer just be some solo dude plugging into a super based database you would have to think about the company as a whole but thankfully because of this video you now understand the different layers that form context and memory and data and the different tools that we can use to understand these layers in which case all we need to do is apply that understanding in a hierarchical level for our business.
So if we're using Notion here as an example, we might have some company pages that has the company handbook. It's got our offer and our prices and maybe some start here stuff and a bunch of other files that everybody reads and only the owner can edit. Underneath that, we might have a team space for sales and that has the sales playbook who some of our clients might be in a simple CRM and various other things that the specific sales team would need to access.
And then we might have John sitting over here and he's got some private pages with his notes and his own voice and how he wants the AI to be doing things. In reality, you could control this quite easily because you can just not give John access to anything other at a company level apart from these files up at the top over here.
Same thing for the team space over here. If John had to go and access something because he was on the sales team, you would only give him access to specific things. And it all comes down to role -based access control.
That's the best way to scale this type of thing. Because realistically, in controlling what John's AI model can do, you're essentially controlling what he can do. It's the same user, unless you're using Notion's own AI, in which case you would still use RBAC to control this type of thing.
And just to make it very clear, this is just one illustration, right? I recommend Notion for teams because it's already a team -based program. But realistically, you could have the company stuff inside Notion or whatever it is that you're using.
And the private pages could simply live inside Claude. So you could just stash this as a person. If you had any private markdown files, you could either upload it to your library or you could just add it via Google Drive or whatever else you have that stores plain markdown files.
I think if you're a business, you're not going to be juggling between Claude and ChatGPT and CrockBot. As a business, you will make a decision about... which one to use, which best suits your business needs, and in which case you're technically already locking yourself in to some degree.
So that's why it's not really an issue to have those personal markdown files for you, using them natively inside the library here, or if you want it to be decoupled, using Google Drive or whatever your business uses. And then finally on this, just remember you need to have the owner's gate. Whatever system you're working in, if there are global changes or department level changes, nothing gets changed without the owner knowing about it.
Because if you change a price, you change some information, it can totally scrub every single automation that is attached to your system. So this human gate is vital and should not be skipped.
But as we get to the end of our journey over here, we can take a final look at what this bigger picture looks like. And if you remember one thing, I think the best approach for what we're doing now is to just , which as you have now seen is our context layer and all of the moving parts that form a part of it.
We have our AI app at the top over here, and then we have our business context, we have our business data, we have any meaningful tables that we've written to this and below this we just have our search or our wiki we have our always -on machine which is probably going to be one of these air models up at the top and then our team with proper ownership and access attached to that the best way to approach any of this is to scale it step by step and do what you need to only when you need to do it instead of falling into all of the hype out there If you made it this far in the video, thanks very much for watching.
There are videos and deep dives into literally everything that I've spoken about with all of the skills attached to do whatever it is that you need to do. If you do need more help, I have a community where I'm helping AI builders and consultants every single day navigate this crazy world of AI. Thanks very much for watching.
I'll see you guys in the next one.
The Hook
The bait, then the rug-pull.
The title promises an upgrade that has nothing to do with the next model release, and the first line pays it off: you hired a genius and never briefed them. What follows is a level-by-level map of the context layer, built around one running example, drafting the follow-up email after a sales call.
Named ideas worth stealing.
02:13list
Context for This Job (six parts)
- Task + instructions
- Knowledge
- Data
- State
- Memory
- This run (working context)
Context is an umbrella term for six inputs that live in different systems: skills for repeatable instructions, markdown knowledge files, databases for data and state, a reviewed memory file, and the live chat with its tools and history.
Steal forauditing why an AI workflow produces generic output
07:09list
Start With What the Task Is Missing (five capture methods)
- Read existing work
- Ask for the gaps
- Show good work
- Read the system
- Review experience
Pick the capture method that fits the information: connect docs, email and Slack; have the AI interview you; store examples of what done looks like; pull from databases; and mine recent conversations for patterns. Then capture, check meaning and scope, and route to the right home.
Steal foronboarding a new client or employee into an AI system
13:34list
Three Ways Your AI Reads Your Stuff
- Upload (a copy inside the app)
- Link a folder (reads your computer while it is on)
- Connect an app (sign-in connection)
Each access method piggybacks on how you already work, with different tradeoffs for availability and copies.
Steal forchoosing where a team's AI reads shared documents
17:01model
Records, Events, Current State, History
- Records
- Events
- Current state
- History
Business data is rows of customers, invoices and tickets, enriched with dated events, rolled up into a current state, and retained as history. Use tables when you need to match, filter or count.
Steal fordesigning a CRM or client-health table an AI will query
20:58list
Five Reasons to Copy Data Into Your Own Table
- History the tool does not keep
- Relationships across tools
- One shared answer
- Decisions you've made
- Heavy repeated analysis
Copying data out of source systems is justified by retention, cross-tool joins and repeated analysis. Speed and saved tokens are not reasons on their own.
Steal fordeciding whether to build a central Supabase table or just query through MCP
23:26list
One Way In, On a Clock
- On a schedule
- The moment it happens
- An export you import
- Forms writing in
Each data source needs one sync mechanism: scheduled pulls for a CRM, event-driven updates for payments, imports for systems without an API, and forms. A copy is only as fresh as its last sync, so tag it with a last-synced time.
Steal forplanning data pipelines into an AI-readable table
24:54model
Database vs Search vs Wiki
- Database: exact records
- Search: the right passage
- Wiki: the answer, already worked
Three storage jobs with different strengths. Do not push simple lookups into a RAG index; reserve RAG for finding passages across large bodies of work and wikis for topics that compound.
Steal forpicking the right retrieval approach for a knowledge base
30:52model
Observe, Review, Keep / Promote / Retire
- Observe
- Review
- Keep in memory
- Promote to context, skill or state
- Retire
Inspect each learned memory for source, confidence and scope, then keep it if it only makes the AI more conversational, promote it into a profile, skill or state record if it belongs there, or retire it if it is stale.
Steal fora recurring memory-hygiene routine for any AI assistant
33:37model
Who Owns This Context? (Company, Role, Personal)
- Company: offer, prices, policies, maintained by the business
- Role: playbook, duties, handover, maintained for the job
- Personal: voice, preferences, private notes, maintained for the person
Separate who can change each layer from who can use it. One person can wear all three hats, but company-level changes need the owner's yes.
Steal forrolling out a shared AI workspace to a small team
How they asked for the click.
VERBAL ASK
39:05product
“If you do need more help, I have a community where I'm helping AI builders and consultants every single day navigate this crazy world of AI.”
Soft, one-sentence pitch at the very end after the recap, pointing to deep-dive videos and a Skool community linked first in the description. No mid-roll pitch.
MENTIONED ON CAMERA
FROM THE DESCRIPTION
PRIMARY CTAWhere the creator wants you to go next.
OTHER LINKSAlso linked in the description.
Visual structure at a glance.
