Transcription
So when you're working with coding agents like Cloud Code or CodeEx, the biggest question that you're probably asking yourself is how to manage your context so that your agent works exactly the way you want it to.
Thankfully, I spend hours and hours doing my research about context management so that you don't have to. And these are the three levels of managing your context that you should know.
First of all, it is markdown files that give you local control to your agents. Secondly, we have MCB servers that give you a variety of features for your agents. And most importantly, we have CLI tools that give your agents the same capabilities as MCB servers, but are much more efficient. So in this video, I'll go through the pros and cons of each level and is to give you a comprehensive overview of how to manage your context optimally. So let's dive in.
First, let's talk about markdown files. One thing that you should know is that agents are really good at working with markdown files. So you're probably familiar with the behavior that whenever your agent completes a task, it's going to generate a markdown file for that task so that in the future, it can refer back to this file if they want to continue working on, uh, this feature. For example, this is my personal project that I've been working on. So you can have different chat sections with AI and you can turn that into a podcast. And this is a brand new feature that I've just added. And when I come back to, uh, IDE, and you can see that I use Cloud Code. So after completing the task, it generates a, uh, markdown file for this task. And different agents have different markdown files for themselves. For example, when I use Cloud Code, I have cloud.md as my standard memory file. So again, markdown files are really great for local context management because, you know, they're all living in your machine and you can use them or your agent can access them whenever they want.
But there are some major challenges with markdown files. Most importantly, they are static. They're living inside of your machine and they cannot catch up with your project status. So, for example, you're probably working in the same project with many different people and your project changes over time, but your markdown files can't. So you have to update your files very manually. And as I said earlier, your coding agents tend to create a bunch of markdown files in your project, and, you know, it can be really overwhelming when your project grows. So as you can see that when I code with my agent, it generates a bunch of trash markdown files. So I have to be the one to clean this all up, which is, you know, again, very manual.
Another thing that you have to be looking for is that, you know, coding agents most of the time, they have their own memory files, which are again markdown files, and these files are preloaded into your context window. So, for example, with Cloud Code, we have cloud.md. For now, the memory files only take up, uh, over 2K tokens, which is okay in my opinion. But as I said earlier, when you have many projects or your projects grow over time, it can be really expensive to your context window. I'm making an exaggeration here with, uh, this example, but, you know, as you can see that my memory files take up over 26K tokens with over 2,000 lines in cloud.md. Most of the time, you don't have that much information stored in cloud.md, but as I said earlier, all of the memory files in your machine, as well as in the root folder, will be added to your context window. So just imagine you have 10 projects and each project you have a separate cloud.md file, and all of that added into your context window when you start a new session is going to be really terrible for Cloud Code or any coding agents for that matter. So markdown files are great, but make sure that you keep them clean and concise.
For example, I'm using Borwer MCB server and I want to have some rules for my agents to follow. So I add some concise rules for my agent to follow when using Borwer tools. Just for you to know that Borwer just launched Borwer CLI, which is a much more efficient and powerful tool than its MCB server. And because of that, I also add some, uh, you know, workflow instructions for Cloud Code to use the Borwer commands. So these are the only information I want in my cloud.md file. Regarding the problem that your coding agents always generating a bunch of nonsense files in your project, I'm not saying that it is a bad practice because, you know, it helps your agents, you know, regard to the previous implementations in the future. But of course, you don't want to clutter your project with these markdown files.
So let's move on to the next level where you can store all of your memory, all of your context without generating a bunch of markdown files. So, we're going to move on to a more advanced context management level, and it is MCB servers. Again, managing context is all about giving the right information to your coding agents. Previously, we did that with markdown files. We stored rules, we stored instructions for our coding agents. But these contexts don't need to live inside of your machine all the time. Your agents can access them through MCB servers.
As you can see here, I have three MCB servers that I use to manage my contexts. First of all, I have Linear MCB server, you know, to get all of the issues in my workspace. I also have Notion MCB to get all of the documentations or reports from my team. And most importantly, I have Borwer MCB server, which is the unified memory layer for all of the contexts. And of course, Cloud Code or any coding agents can use Borwer's context for the task. So, for example, I tell Cloud Code to get all of the documentation about Borwer CLI, which is the latest release from Borwer in Notion, and it started to use Notion tools to get all of the content from my Notion. And it gives a pretty comprehensive detail about CLI without using any markdown files. So the same thing goes with Borwer MCB server. I tell it to give me a comprehensive documentation for this project in Borwer, and it uses Borwer's retrieve knowledge tool to get all of the memories from this project. You know, from the architectural plan of this project to the recent implementation, uh, that I had in this project. Everything is captured in Borwer. Finally, it gives me a detailed, uh, summary of the project, you know, from the, uh, tech stack from front end to back end to the architecture and the database as well.
And the best thing about managing your context with MCB servers is that all of this thing is not inside of your context window when you start a new session. You know, your agents only load this information when they need it. So, you can still keep a clean context window for your agents. But there is a not-so-great thing about these MCB servers is that all of the tools and all of the descriptions from these MCB servers are directly added into your context window. Even though I said that MCB servers are great when it comes to, you know, dynamically loading context from different servers, but the agent has to understand all of the tools from these servers. So take a look here with Borwer MCB server, there are only two tools, which is okay. But with Linear or Notion, there are a lot of tools, and each tool takes up about 1K token, and all these tools combined, it takes up over 50K tokens, which is over 25% of the entire context window. So again, MCB servers are great to get contexts from external sources, but when you are having too many of them, it can be a challenge for the context window.
Now let's talk about CLIs and why they are much better than MCB servers when it comes to managing your context. I think there are three reasons for that. So first of all, agents are really good at using batch commands. When it comes to MCB servers, it's all about tool calling or previously function calling. It is still a relatively new feature for many large language models because, you know, large language models are heavily trained on public data, and public data has a lot of instances of batch commands. So your agents are inherently really good at using batch commands.
Secondly, CLIs can act as MCB servers as well. What do I mean by that? So I found a really interesting article about comparing MCB and CLI, and the author gave a really interesting point. You know, MCB servers can be seen as, you know, thin wrappers of CLI commands. So one good example is GitHub MCB server. But why do we need GitHub MCB server when we can use the GitHub CLI commands? And having an entire MCB server for that purpose is not necessary. So I have GitHub MCB servers here, and you can see that it has over 40 tools. And let's see what these tools are about. Add review command, add command to your issue, create a PR, create branch. Like, why do we need the tools? We can use Git commands or GitHub CLIs for all of these tasks. And it's not just the fact that these tools are useless. It's about the fact that it consumes a lot of tokens in your context window. So just like what I said earlier, with a lot of MCB tools, it takes up a large space in your context window. In this case, it is about 30K tokens consumed by the 40 tools from GitHub. So most MCB servers nowadays, I think, can turn into, you know, CLI commands, and they are much more effective.
Let me explain why. It's all about progressive disclosure. So, you know, when you use CLI commands, you don't add all of the instructions about these commands into the context window because we only add new information about the CLI when we use the commands. What do I mean by that? Let's look at an example. So as I said earlier, Borwer CLI. Borwer CLI commands. So it has the same functionality as Borwer MCB but much more powerful. So, you know, the first thing that your agent will, uh, do when it uses Borwer commands is, you know, using the Borwer dash help to get, you know, the information about the CLI commands. And then when it wants to use a specific command like Borwer retrieve or Borwer add, it uses the same double dash help to get the, uh, instruction or the description about the command. If it only uses Borwer retrieve tool and Borwer add tool, only these two tools are added into the context window.
So I'm going to tell you how to install Borwer CLI and test it out to see how it's going to be more efficient than Borwer MCB. First thing that you need to do is install Borwer CLI. So just npm install-g Borwer CLI. And the second thing that you need to do, just like with, uh, Borwer MCB, is to log in into your zone. Here I'm taken to the website. I need to authorize my account. And now when I go back to the terminal, it's already authenticated. Finally, use Borwer init to initiate Borwer CLI into your workspace. Currently, Borwer CLI is just in the beta version. So in my beta environment, I have one, uh, team which is Ryan and one testing space. Currently, I'm using Cloud Code. So for the agent, I'm going to choose Cloud Code. And yeah, I want the rule to be written into cloud.md. So everything is correct now. So, so when I use Borwer-help, I can see all of the tools or all of the commands associated with Borwer CLI. And so when I hit SL context, uh, I can see that the token usage for MCB tools is very efficient because, you know, Borwer CLI is not an MCB server. It is a collection of batch commands that your agent could run. So even though we have several capabilities, the memory that it takes up in the context window is very negligible. So it's very good.
And for Borwer CLI, the workflow is exactly the same with Borwer MCB. First of all, we have to add new knowledge. But now we have a middle step, which is push your knowledge from the local workspace into the cloud. And finally, you're going to retrieve the knowledge when you're working on a task. Okay. So the magic comes from here. So when Cloud Code tries to use Borwer commands for the first time, it doesn't have any memory or any instructions in its context window. So the first thing that it needs to do is use Borwer dash dash help to get all of the commands, uh, from Borwer CLI. And the first thing that I did is add new memory into the local workspace, which is in the .br folder here. Secondly, when it tried to push the memory into the cloud. So again, it does not have the instruction in the context window. So it uses Borwer push, uh, dash dash help to get the instruction for how to use the command. So it progressively discloses all of the commands from Borwer CLI. We don't preload the entire set of tools or the entire set of commands into the context window because for a specific task, we only need to use maybe some tools in the entire tool set. So it's very efficient for your context window. So that's the entire idea behind progressive disclosure. We don't preload anything into the context window. Your agent decides which tool or which command it needs to use. Okay. Finally, it retrieved the memory from the workspace. So our workflow is successful. And when I hit SL context again, you can see that the token for MCB tools stays the same. There's no tool for MCB servers. So that's the entire idea behind why CLI is much better than MCB.
Let's take a look at Borwer CLI's workspace. So you can see that we have all of the memories here, just like with Borwer MCB. And I have, uh, stored some fundamental memories for this project. We're going to test out how powerful Borwer CLI is by implementing a task in just one session. So I'm going to implement an entire brand new feature and I want to complete that in just one session. So the feature that I want to implement is, you know, converting my chat sessions into flashcards and quizzes. You know, maybe I've been learning about Borwer CLI in my chat section, but I want to retain the knowledge. So I want flashcards and quizzes to help me do that. So, this is the prompt that I'm going to give my Cloud Code. So I want to implement a feature that turns any chat sections into a flashcard and quizzes. And I want that to be relevant to the chat section, of course, to help the user retain the knowledge about the chat section. And most importantly, during the test, uh, Cloud Code must use Borwer CLI to add and retrieve new knowledge. So I think it's done. Now the last thing that we need to do is to run a database migration for this and restore our server. So let me do that and we're going to test the feature out.
Okay, back to my project. Now when I, uh, click on the three dots here, I can see there is an option for generate flashcards or quizzes. So I can choose between flashcards or, you know, multiple choice questions. So I'm going to choose, uh, flashcard and also the, uh, multiple choice questions option as well. On the left sidebar, I can see there's an option for flashcard. I can click on it and I can see all of the flashcards that have been presented here. And the same thing for multiple choice questions. And the best thing about Borwer CLI is that even though I have been implementing the entire feature in the session, you know, that the session has been really long, but when I hit SL context, I can see that I still have over 18% of the entire context window plus 20 more from the buffer. So very efficient when we don't use MCB server tools but CLI commands.
Okay, wait a minute. I want to announce some change with Borwer CLI. So after you install it using this command, we're going to use BRV instead of BR command, just like before. The reason for this change is because we want to avoid conflict with another CLI whose command name is also BR. So first of all, you also need to log into your account using, uh, BRV login. And after that, you're going to use BRV init to choose a team and the workspace for your project. You also choose the agent and, yeah, I'm going to write the rules inside of cloud.md file. So everything stays the same. To double check that, you can use BRV help and see all of the commands stay absolutely the same. We're just switching from BR to BRV. So let's get back to the video.
So I made a table summarizing everything that I said in this video. So in this video, we're talking about three levels of context management. The first thing is markdown files. We have both pros and cons of, uh, this method, but we move on to a slightly more advanced, uh, strategy, which is MCB tools. It is much better than markdown files and it gives you more capabilities to get external context. So finally, the most efficient context management level is CLIs. It gives you much more capabilities and it gives your agents more freedom to explore the tools and progressively disclose the entire CLI tool set. So we don't preload the entire thing into the context window. Your agent only uses what it needs for its tasks.
That's all for today's video. If you think this is helpful, please also check out other videos in our channel as well. And most importantly, we just released Borwer CLI in the beta environment. So if you think it is a great component in your workflow, please also check out this new feature. I'll link the resources in the description. Again, thanks for watching this video.