WEBVTT

00:00:00.000 --> 00:00:05.920
Everyone's talking about building an agentic operating system, and building one for yourself is relatively straightforward.

00:00:05.920 --> 00:00:46.775
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. Your 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. A 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

00:00:46.775 --> 00:00:57.095
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. So let's get straight into it.

00:00:57.890 --> 00:01:07.730
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,

00:01:07.890 --> 00:01:11.410
and that's pretty much it. They tell your AI model to inject the right context

00:01:11.665 --> 00:01:15.665
at the right moment, like your brand voice or your client implementation details,

00:01:15.985 --> 00:01:38.420
only 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. 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. So having one stops us from starting every conversation from zero. So you can think about it like this. The LLM model provides the intelligence,

00:01:38.660 --> 00:01:50.145
and the OS provides the memory and the judgment about what information to load when. And 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.

00:01:50.385 --> 00:01:56.370
How do you structure those files and folders to achieve all that but still ensure it's usable for the whole team whilst respecting

00:01:56.370 --> 00:02:02.930
what should always be kept private per individual team member? So effectively shared where it should be, private where it shouldn't be.

00:02:03.570 --> 00:03:19.540
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? And 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. Now, 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. And 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. We 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. So we don't wanna store scripts and system files inside Notion because we don't actually need to see those files,

00:03:19.780 --> 00:03:58.095
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. The 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. So we operate on those files using ClawCode or Codex or another harness,

00:03:58.255 --> 00:05:00.155
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. So 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. So 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. And 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. So 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.

00:05:00.715 --> 00:05:27.895
So 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. Now 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

00:05:28.055 --> 00:06:08.040
or effectively our memory files inside our context folder. We 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. So 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

00:06:08.200 --> 00:06:31.545
are managed inside GitHub. But 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. Now 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

00:06:31.545 --> 00:06:45.380
and stored in that vector database. And 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

00:06:45.685 --> 00:07:09.490
and GitHub. This 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. And 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

00:07:09.490 --> 00:07:20.755
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. So all of a user's outputs

00:07:20.755 --> 00:08:00.710
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. So 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. So 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.

00:08:01.430 --> 00:08:02.390
So firstly,

00:08:02.550 --> 00:08:28.600
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. So 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. If So a client's face isn't shared with you, you simply can't pull the information

00:08:29.000 --> 00:08:39.320
into ClawCode from that client. So this is the source of truth for access, and everything else is gonna copy the shared drive permissions. So number two, we've got your local machine running ClawCode.

00:08:39.575 --> 00:08:44.855
So each person works on their own machine, but what lands inside that machine is decided entirely

00:08:45.175 --> 00:09:00.470
by the token from Notion or Google Drive. So 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,

00:09:00.630 --> 00:09:30.420
and 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. 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. 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,

00:09:30.660 --> 00:11:17.035
and 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. If 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. So 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. 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. 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. 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. 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. 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. 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. 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. 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. We'll be releasing the team edition in June. Now there's something important that's underpinned this whole thing. The whole OS underneath

00:11:17.275 --> 00:11:18.635
is just markdown

00:11:18.715 --> 00:11:26.090
files and folders. So this means you can be completely portable. So there's no vendor lock in. You can use this inside ClawCode

00:11:26.090 --> 00:11:48.015
or anywhere else. So 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.