§ 01 · 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.
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.
Visual structure at a glance.
Named ideas worth stealing.
02:03
model
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 for Any multi-person AI workflow where some members are non-technical
08:01
concept
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 for Designing access control for any multi-system team AI setup
09:30
model
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 for Deciding how to structure long-term memory for a team AI system
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."
Things they pointed at.
How they asked for the click.
10:30
product
"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.
Word for word.
HOOK opening / re-engagementCTA the pitch metaphor analogy
00:00HOOKEveryone'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:12HOOKYour 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:32HOOKA 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:55HOOKSo 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,
01:07and that's pretty much it. They tell your AI model to inject the right context at the right moment, like your brand voice or your client implementation details,
01:15only when you need them, though. And 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.
01:23This 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. So having one stops us from starting every conversation from zero. So you can think about it like this.
01:35The LLM model provides the intelligence, and about what information to load when. And with those two together, you can achieve high quality outputs every time you use Glockcode.
01:47So 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:50HOOKSo 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:00HOOKSo 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,
09:00and this is the part that was tripping me up at first as well. So your Notion permissions do nothing in GitHub. They're completely separate systems.
09:08So 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. Then 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,
09:30and that's controlled by the owner. Now 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.
09:39If you haven't got a setup like this, then you don't need to worry about this part. It'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.
09:48So the first is a bit easier to do, which is effectively set up separate data stores. One memory index per person built locally on that person's machine. Your memory is built from the files that they sync.
09:58And 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. So 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.
10:21CTASo 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. So 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.
10:38CTANow 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. Now 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.
10:52Now we are personally implementing the Postgres memory number two that we just spoke about so that it's scalable across multiple teams and clients. So 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.
11:09We'll be releasing the team edition in June. Now there's something important that's underpinned this whole thing. The whole OS underneath
11:17is just markdown files and folders. So this means you can be completely portable.
11:22So 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.
— full transcript
§ 05 · For Joe
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.
