23:12Simon Scrapes · Tutorial
3 Claude Memory Systems to Get You Ahead of 99% of People
A 23-minute systems teardown comparing Claude Code default memory, MemSearch, and Hermes -- then synthesising the hybrid setup that beats all three.
May 16thThe argument in one line.
A team agentic OS demands one permission model declared in your shared drive and mirrored exactly across GitHub and your memory database, because a gap in any single layer leaks context to people who should not have it.
Read if. Skip if.
READ IF YOU ARE…
- You already run a solo Claude Code agentic OS and want to extend it to teammates without exposing everything to everyone.
- You manage client work across multiple accounts and need hard isolation between clients inside the same AI toolchain.
- You are a technical team lead trying to let non-technical teammates edit AI context without touching config files or YAML.
- You are evaluating shared vector memory (Supabase/Postgres with RLS) as a replacement for per-person local indexes.
SKIP IF…
- You have not yet built any personal agentic OS -- this video assumes that foundation is already in place.
- You are looking for a no-code or SaaS solution -- everything here is file-based and requires some GitHub familiarity.
The full version, fast.
The problem with team AI setups is not the model -- it is context management and access control. The video proposes a three-tier hierarchy: Notion or GDrive for human-editable markdown (brand voice, company rules), Claude Code for agent-maintained files (skills, settings, memory updates), and GitHub as a backup of everything. The key rule is that Notion permissions become the master access model that GitHub repo membership and any shared vector database must mirror exactly. For memory, a single Postgres store with row-level security per client scales better than per-person local indexes, at the cost of a harder initial setup.
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:57
01 · Cold open -- the team problem
States the three challenges that appear when scaling an agentic OS to a team: shared memory, non-technical access, and future-proofing against tool churn.
00:57 – 02:03
02 · Agentic OS recap
Quick definition for viewers who have not yet built one: folders and files that inject the right context at the right moment, stopping every session from starting at zero.
02:03 – 05:00
03 · Three-tier storage model
Notion/GDrive for human-maintained markdown; Claude Code for agent-maintained files; GitHub as backup and version control. Borrows architecture from GBrain and software's principle of separating what changes frequently from what stays stable.
05:00 – 07:45
04 · Team OS file structure
Full annotated folder tree: CLAUDE.md, SOUL.md, brand_context, context/, clients/<acme>/, workstations/<finance>/. Color-coded by who edits each file (Notion = blue, GitHub = purple).
07:45 – 11:17
05 · Access control across four systems
Rule: Notion/Drive is the permission boundary. GitHub repo membership must mirror it. Local Claude Code only holds what the token was allowed to pull. Memory database needs RLS per client. Two memory approaches: per-person local indexes vs. shared Postgres with RLS.
11:17 – 11:48
06 · Portability and no vendor lock-in
The OS is plain markdown files and folders -- move it to Claude Code, Codex, or any CLI agent without rebuilding. Closes with next-video CTA on memory systems.
Lines worth screenshotting.
- The permission model for a team AI system must be declared once in your shared drive and mirrored exactly in GitHub and your memory database -- any gap leaks context.
- Non-technical teammates should edit AI context in Notion or Google Drive, not in YAML files inside a code repo they cannot safely modify.
- Skills and agent-maintained files belong inside Claude Code, not Notion -- passing skill YAML through Notion introduces formatting errors that break execution.
- GitHub is version control only in this architecture; non-technical team members never need to touch it.
- Per-person local memory indexes are free isolation but create silos -- there is no shared brain to query as a team.
- A shared Postgres store with row-level security per client is harder to stand up but gives every team member access to a single queryable institutional memory filtered by their permissions.
- The entire agentic OS is just markdown files and folders, which means you can move it between Claude Code, Codex, or any CLI agent without vendor lock-in.
- A user's local Claude Code environment only ever holds what their Notion token was allowed to pull -- the laptop is a result of permissions, not a gate.
- GitHub repo membership must mirror Notion access for the same client exactly -- Notion permissions do nothing inside GitHub; they are completely separate systems.
- Garry Tan's GBrain system at YC inspired the multi-tenant isolation model here: each person gets a scoped slice of company memory, not the entire brain.
One permission model, four systems, zero gaps.
WHAT TO LEARN
The moment you add a second person to an AI workflow, access control becomes the product -- and it only works if every system enforces the same rules.
- Store human-maintained AI context (brand voice, company rules) in the tool your team already uses -- Notion or GDrive -- not in YAML config files that non-engineers cannot safely edit.
- Agent-maintained files like skills, settings, and memory updates belong inside Claude Code, not in Notion -- formatting errors introduced by Notion exports break skill execution.
- Your shared drive is the permission boundary for the entire system: GitHub repo membership and memory database access must mirror Notion access exactly, because the systems do not talk to each other.
- GitHub is version control and backup only; non-technical team members never need to open it if the sync from Notion to Claude Code is set up correctly.
- Per-person local memory indexes give you free isolation inherited from sync permissions, but they eliminate the shared institutional brain -- no team member can query what another has stored.
- A shared Postgres store with row-level security per client is harder to stand up but scales to many teams and clients: each query is filtered at the database layer, not in application code.
- The entire architecture is plain markdown files and folders, which means you can swap the AI harness (Claude Code, Codex, any CLI agent) without rebuilding your context library.
Terms worth knowing.
- Agentic OS
- A set of folders and markdown files that tells an AI model which context to load at which moment -- brand voice, client details, rules -- so every session starts with the right information rather than from zero.
- Context rot
- The degradation in output quality that occurs when too much information is loaded into a single LLM context window at once, causing the model to lose track of earlier details.
- Row-level security (RLS)
- A database feature that filters every query so each user only sees the rows tagged with their permitted clients or scopes, enforced at the database layer rather than in application code.
- claude.local.md
- A personal override file on an individual team member's machine that adds or overrides rules from the shared global CLAUDE.md, kept private via gitignore.
- GBrain
- Garry Tan's production AI memory system at Y Combinator that inspired the multi-tenant team isolation model in this video -- each person queries a scoped slice of shared company memory.
- Vector memory / semantic database
- A database that stores information as numerical embeddings so queries return results by meaning and relevance rather than exact keyword match, enabling long-term AI recall across sessions.
Things they pointed at.
Lines you could clip.
01:38
“Having one stops us from starting every conversation from zero.”
01:50
“The LLM model provides the intelligence, and the OS provides the memory and the judgment about what information to load when.”
08:01
“Notion/Drive is the permission boundary. Git and Memory must mirror it.”
11:17
“The whole OS underneath is just markdown files and folders. So this means you can be completely portable. No vendor lock-in.”
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.
metaphoranalogy
00:00Everyone's talking about building an agentic operating system, and building one for yourself is relatively straightforward. But building one for a team is where things get a little bit more difficult. Memory needs to be shared without exposing everything to everyone.
00:12Your teammates need to be able to improve the system without touching the technical details. And whatever you build needs to survive the next wave of AI tools and updates and not get you locked into one interface. So over the last few weeks, I've been taking ideas from systems like Gary Tan's g Brain, combining them with best practices, and building what I think of as a team operating system inside Claude.
00:32A system where editable knowledge lives inside the tools that you use day to day, like Notion and Google Drive, where memory is shared only where it should be, and where context stays separated across different teams and clients. So I'm gonna walk you through the three core considerations underpinning the system, and by the end, you'll have a complete blueprint that you can hand to Claude to build your own team OS today, even if you've not built out your own Agenic OS yet.
00:55So let's get straight into it. So quick recap, if you've not built an AgenTek OS yet, here's what it is and why it's important that you have one. So underneath all the jargon you hear, it's a set of folders and files that manage context, and that's pretty much it.
01:08They tell your AI model to inject the right context at the right moment, like your brand voice or your client implementation details, only when you need them, though.
01:17And you want to have one because out of the box, an LLM has real limits. It's forgetful when you give it a lot of information at once. This is known as context rot, and it is no long term recall of your business or of the decisions you've made, your clients, your voice, your rules.
01:30So having one stops us from starting every conversation from zero. So you can think about it like this. The LLM model provides the intelligence, and about what information to load when.
01:43And with those two together, you can achieve high quality outputs every time you use Glockcode. So everything in this video comes down to just one question. How do you structure those files and folders to achieve all that but still ensure it's usable for the whole team whilst respecting what should always be kept private per individual team member?
01:59So effectively shared where it should be, private where it shouldn't be. Well, first, we've got to consider where we should actually keep the files. What is gonna be our ultimate source of truth, and how do we ensure version control, especially across multiple team members?
02:12And the way that we personally think about this is a three tier system. So the location where you put the files and where you edit the files depends on whether a human maintains them, an agent maintains them, or whether it's just your backup and version control system. And, ultimately, if we're sharing this with a team, we want our nontechnical team members to be able to access it in a nontechnical environment and set up their rules in a really clean interface like Notion or Google Drive.
02:37Now, of course, these are just examples. You could use this in any shared file system. A couple of people in the community are using OneDrive or Dropbox for this, so it could be any file system that you use.
02:46And we do that for two reasons. Firstly, because it's already where we work, so it's really simple. And secondly, it's nicer to look at, which means editing is really easy.
02:55We can edit it in a really nice markdown format way because we're familiar with Notion already. So that means then our Notion or our Google Drive is our source of truth for all of our human edits for files like our global rules in the Claudette MD or our brand context, which we keep updated over time. So those shared file systems are limited though to markdown files.
03:14So we don't wanna store scripts and system files inside Notion because we don't actually need to see those files, and also we could potentially cause errors passing them between Notion and our ClawCode interface. So inside ClawCode, we're gonna store all the files that effectively need our agents to update them and therefore don't need to face our team.
03:31The one exception to that is our process documents or better known as skills, which also sit inside this bucket and are operated on and edited from directly inside Clawl code. Now arguably, those could also live in Notion and Google Drive, but there are some technicalities around passing the formatting of that name and description YAML front matter of skills from Notion or Google Drive into ClawCode that could cause errors as well.
03:53So we operate on those files using ClawCode or Codex or another harness, and their source of truth is actually gonna be stored inside GitHub. So we're using GitHub as a third tier, but as a version control system that backs up absolutely everything, including the files that we've passed down from Notion or Google Drive.
04:09So this borrows from how Gary Tan from Y Combinator and a huge thought leader in this AI infrastructure space thinks about shared company brain for his g brain. And for reference, he's running a really large team and needs separation between hundreds of companies worth of data. And then it combines that with software architecture principles.
04:27So separate what changes frequently from what's actually gonna stay stable. And with these three tiers set up, you have somewhere that your team can actually work that's familiar to them. You have the agent editing what it should be editing and working inside the context of ClawCode.
04:40And then you have GitHub as a complete backup of everything. And it's important to note, any nontechnical team members don't necessarily have to touch GitHub. That's our version control system for our technical team.
04:50So next, we'll see how this looks with all of our usual claw code files. But before we move on to that, do me a massive favor. Make sure to hit the like and subscribe buttons below if you're enjoying the video.
05:00So this is our complete folder structure inside the team OS at a high level. So we've got our company rules inside our claude.md, our agent identity, like our sole dot md, and our brand context, which is how we speak, who we speak to, and our visual identity, as well as any shared files that we want every team member to access, basically authored inside Notion.
05:20Now not everybody has access to those, and we'll come back later to show you how you control that. And then we have a similar structure with our knowledge base or effectively our memory files inside our context folder.
05:31We want some of our memory files to be shared amongst the team. For example, about specific projects or in a client folder or a department or workstation folder, but then still allow users to add their own personalized rules that overlay on top of what they've inherited from those global rules. So global shared rules come down from Notion, but a user is able to actually override those or add rules for their own specific bespoke setup in a claw dot local dot m d file.
05:55So what we're trying to do is basically map out the shared brain versus an individual teammate's brain. So everything in blue is managed by Notion as markdown files, and all of the files that the agent or code is gonna manage and maintain are managed inside GitHub.
06:09But we operate on them within our Claude code environment. And those show in purple, and it's things like the skills, the settings, and the memory files that the user doesn't need to see. And then, of course, they get merged from all the stuff, all the shared files that get pulled from Notion too.
06:23Now things like memory have a slightly more complex set of rules because we're effectively pulling long term memories from a vector database. So they're indexed and stored in that vector database.
06:33And what you need to make sure there is that you can have user level control over what user can access what things from the memory. And because that's stored externally, we effectively need to sync up the permissions in the memory database with our permissions in Notion and GitHub.
06:46This could be, for example, controlled at a client level. So for example, a second user can access the Acme client, and therefore, they're able to retrieve all the shared data about that client. But if they don't have access on Notion or GitHub to that client, then they're not able to access the memories from that client either.
07:02And then as we touched on, there's a bunch of additional rules that a user can overlay, and these are kept in claw.local.md files or dot local dot m d files so that a user can keep still their own rules but keep it private on their machine. And the last key point around this folder structure is project.
07:18So all of a user's outputs needs to be stored somewhere. And, actually, if we want nontechnical team members to access those outputs, then we would do a push back into Notion just to display the output.
07:28So they're not editable inside Notion. These are just pushed back into Notion to display those outputs or kept inside Claude and managed in version control inside GitHub. So now we've covered where the data lives and how it's inherited at different stages, let's talk about how you can actually control access to the different levels of data.
07:43So you don't want someone seeing a file they're not allowed to see. So we have to control it at different levels and kind of across four different systems, your shared drive, your working environment, GitHub, and the memory database, which we've got to consider separately. So it sounds pretty complex, actually we've got some simple rules to define that make it relatively straightforward to set this up.
08:01So firstly, the shared drive. So the team owner is gonna control the shared context here, the brand, the rules, and sets who can view and who can edit each doc.
08:12So two things are gonna enforce this. So we've got per document view and edit rights and which spaces that each user's login is actually connected to. So your login is only ever gonna see the spaces that you've been added to as a team member.
08:24If So a client's face isn't shared with you, you simply can't pull the information into ClawCode from that client. So this is the source of truth for access, and everything else is gonna copy the shared drive permissions.
08:35So number two, we've got your local machine running ClawCode. So each person works on their own machine, but what lands inside that machine is decided entirely by the token from Notion or Google Drive.
08:47So the laptop only ever holds what the token was allowed to pull. As a result of token generated by our shared drive and the permissions in there, we're actually able to permit certain files to be pulled to claw code and not others. Three, we have GitHub, and this is the part that was tripping me up at first as well.
09:03So your Notion permissions do nothing in GitHub. They're completely separate systems. So to prevent leaks, you've got to have one repo per client, each scoped on GitHub to exactly the same people who have access to that client's Notion access.
09:17Then any private tweaks a user makes to their own claw dot local dot m d file are git ignored and in their own private repo that's theirs alone. So the important part is that git membership mirrors our Notion or Google Drive membership, and that's controlled by the owner.
09:32Now number four is the memory database. So this is if you've got a memory database pulling long term memories by meaning from our semantic database. If you haven't got a setup like this, then you don't need to worry about this part.
09:42It's all kept in the first three tiers. But there are two key ways to do this, and the second one is much more scalable. So the first is a bit easier to do, which is effectively set up separate data stores.
09:52One memory index per person built locally on that person's machine. Your memory is built from the files that they sync. And because they only sync files that they're actually permitted to do so, they can't access any files that they weren't given access to in the first place.
10:05So the upside is the isolation is completely free of inheriting files that they shouldn't, but there's no central system to have a shared memory with this. So the second one then is a shared Postgres memory on something like Superbase, for example, a Postgres memory that everyone can query live. So you've got a shared memory in one database tagged by client and then using row level security to filter every query by who's asking.
10:29So an Acme only person gets Acme and company wide rows, and the database, therefore, because of the row level security, is gonna refuse them access to other clients they don't have access to. Now the downside to this is that the setup is harder to stand up and maintain, and it's a single thing you now have to secure properly on its own.
10:45Now the upside to this is it's hugely scalable. Once you set this up and secured it, you've got that shared brain across the entire team. Now we are personally implementing the Postgres memory number two that we just spoke about so that it's scalable across multiple teams and clients.
10:58So if you want to just grab this AgenTik operating system with full team considerations taken into account and memory databases being built in this scalable way, then you can just join the AgenTek Academy in the community below. We'll be releasing the team edition in June. Now there's something important that's underpinned this whole thing.
11:15The whole OS underneath is just markdown files and folders.
11:20So this means you can be completely portable. So there's no vendor lock in. You can use this inside ClawCode or anywhere else.
11:26So it's important you build infrastructure that you can take and move to any system that you want to move to in the future. So that is the complete blueprint for building out your own team operating system to get past the limitations of LLMs out the box and share between teammates. Now if you want to understand how to build out a memory system that's gonna support this team operating system with short term and long term recall, then check out the next video.
The Hook
The bait, then the rug-pull.
Solo agentic setups are solved. The moment you add a second person, three problems appear at once: memory has to be shared without leaking, non-technical teammates need a way to edit context without breaking anything, and whatever you build has to survive the next wave of AI tools without locking you into one interface. This video is the blueprint for solving all three.
Named ideas worth stealing.
02:03model
Three-tier team OS storage model
- Notion / GDrive (human-editable markdown)
- Claude Code (agent-maintained files)
- GitHub (backup + version control)
Separates who edits what: non-technical team members work in Notion, agents work inside Claude Code, and GitHub backs up everything including the Notion exports.
Steal forAny multi-person AI workflow where some members are non-technical
08:01concept
Permission mirror rule
Notion/Drive is the permission boundary. GitHub repo membership and memory database row-level security must mirror it exactly -- no system enforces another's rules automatically.
Steal forDesigning access control for any multi-system team AI setup
09:30model
Two memory database approaches
- Approach 1: Per-person local indexes (simple isolation, no shared brain)
- Approach 2: Shared Postgres with row-level security (scalable shared brain, harder setup)
Choosing between isolated local memory (easy, no cross-team queries) and a shared Postgres store with RLS (complex, enables institutional memory across the whole team).
Steal forDeciding how to structure long-term memory for a team AI system
How they asked for the click.
VERBAL ASK
10:30product
“If you want to just grab this agentic operating system with full team considerations taken into account and memory databases being built in this scalable way, then you can just join the Agentic Academy in the community below.”
Soft sell mid-video before the memory database section. Mentions specific release date (June) which creates urgency. Community link (skool.com/scrapes) in description.
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.
