Transcription
Welcome back everyone to the VS Code Insiders podcast, the behind-the-scenes look at your favorite code editor, VS Code. I have with me yet again Harold from the VS Code team. How's it going Harold?
>> Hi James. Thanks for having me back. It's good to have you back. And I think there's been so much new change and so many new things that probably since the last time you were on, the team has added about 5,000 new features. Yes, this release. I was just showing it in a live stream. Just scroll through. It's like endless endless goodies and a lot of really powerful new features and the UX on top of it is amazing, too. So, it's been amazing how it's all coming together and how we can move so much faster now on the VS Code side, too. So, it's a lot. It's a lot. But I feel like one thing that I've really appreciated is that things feel a little bit more or do feel pretty natural in their evolution. So some of the things that are new features just end up lighting up, right? So for example, if I have MCP servers that now all of a sudden have MCP apps built into them for UI, they just show up, right? If I have different agents or different things, like the UI is pretty much still all there, but a little bit more cleaner, a little bit more based on the feedback coming in. and the tasks are coming in a little bit more. And like one of the topics today that we're going to talk about sub agents like kind of just happen automatically like I think that's kind of cool about this point in time with AI development is that there are a lot of things you can go crazy deep on and really customize but now more than ever like a lot of things just happen out of the box.
>> Yeah, totally. I think I we have this planage now for a few. I think we've announced it at Universe last year was like the big big thing and it's one of these key elements that you don't have to customize much like just use plan mode and you get better results like you can iterate. You spend more time up front to gather context and align and like discuss and maybe let your assumptions be challenged. Um and then you don't have to create your own like eventually if you really wanted to you can make your own plan mode. Maybe you want to read like more more context from some MCP servers. Maybe your plan has to be super short. Maybe your plan has to be extremely long. So everybody wants to customize it, but like the out of the box experience like it's just a really nice experience plan mode and now with the latest experience is even better. But also where sub agents really help with that context um to to bring it in into the right places without overloading um where it just works. So you don't have to think about sub agents. It's just doing a really nice job context engineering for you.
Well, let's talk about that a little bit first. And let's first start with just agents, right? I'm inside of agent, you know, agent mode with the agent agent or the plan agent and then this is the mode of the thinking that the agent is there and a lot of people hear a few words which is like what is an agent and what is context that it has. So removing anything about sub agents or anything like that, just kind of break down what an agent is, how it works, and what sort of that context engineering and context window things are basically.
>> Yeah, I think it's really important to understand and if you understand it, you can use it more effectively. It's part of this I think kind of unraveling the black box. So the the agentic loop that runs inside VS Code or copilot CLI basically all starts with you giving it a question and then the the agent loop takes that question takes its system prompt which basically gives it some idea of how it's how it's supposed to act how it's supposed to talk how it's supposed to reason about what it's solving some which also depends on different models. So there's a lot of tweaking in that area usually uh that we do and then it has access to tools and a way [clears throat] it calls tools and you see that if you open up your code it will start to to do thinking about what it's supposed to do. Now those those like thinking blocks move into like reasoning blocks that you see kind of open and close as it does that and that's one loop. Um and then it starts calling tools and all of that kind of is accumulating in a conversation. So you see the agent thinking oh the user asked me to find uh to explain something in the codebase then it will start like oh I should probably look at the codebase and then then it leads to the first tool call where it starts to do a grap search maybe to find that term and that's and that's where the agent that's like the first turn where it stops that's a tool call so that that gets handed to the editor and what's cool is VS Code has a bunch of really powerful search tools that are exposed to the agent so VS code will basically do that search. If it's a grab or semantic search, it will return that result to the agent and then continue the loop. So the loop pauses for a moment to do the search, then continue on. Then the agent continues with that new information like it ran the tool, it got the result, and that's added to the conversation. So now the agent has the system prompt, the user question, the thinking it did, the tool call it where it wanted to grab and then the response and it can continue from there. What's cool as well though that the agent can actually run parallel tool calls. It could say like grab for this, grab for that, grab for this and then the all these two calls come in at once and all the responses will be done by put into VS code and then it continues on. So pool calling is really powerful in a way that can scale. Uh but as you basically as you continue doing that um the agent gathers like which files then can read the files that's another tool call and all of that builds up in a large conversation basically and that's that's your context window. So once the agent has done a few of the tool calls it will have it will has a few file paths of where to look. It will have looked at the files maybe grabbed like the first few lines to understand the file for any files it found really useful. it started to read the full file and all of that is building up context to eventually answer a question like okay now I understand how this feature works um here's my explainer maybe it gives you a mermaid diagram because that just shipped and it can it can do interesting things with that context and maybe implement the feature right but that that um context buildup especially as it explores and learns about a topic um is is really interesting part to understand and Now we also in VS Code we have a little context indicator so you see in a conversation how much context the agent has built up. So it's less you reasoning about how long it takes. So it's much easier to understand how that agent loop works now. Um aside from all the tool calls but also the the context that's being added.
Yeah. And the interesting part of that that I'm thinking is, you know, as this sort of context flows in and out and it builds up and these tools are being called, I think you made an interesting point, which is certain select parts of that information are important, but other ones aren't. And I think this is where that sort of idea of sub aents comes from which is hey if I'm having a long planning running session how much of what actually was researched and added to the context window is important right is it all that deep research is that gring all this other stuff what's the actual return so I think this is the case where how much context isn't needed in the main agent like in the main agent to actually get the job done and I think this is sort of where sub aents come in and people are going to start seeing this and why we wanted to talk about it. They probably already seeing it inside of VS Code and they see it literally will say sub agent running these things, right? Before you would just see all the tool calls which is cool to see. Now you're seeing sub agent doing this thingup. So how is that different than the main agent running and like when does that sub agent kick in?
>> Yeah. So the sub agent basically is its own agent loop with its own context. And most often I think the best way to describe it is is you want to delegate something like if I I I get asked a lot by engineers like hey what how like inform this issue like find out like why people actually want this want this feature like do we need to do this feature and that's them offloading and like here here's a feature we might want to do like here's a here's a Reddit thread some people commented maybe there's some customers to talk to and then I come tag and like here's the reason why people like this. Uh they're it's a it's a problem they are aware of. Uh it's a problem that that blocks them to do these other jobs. Uh these are the kind of customers I talked to. Uh these are the kind of users. So basically like you don't need all the context of all the things I read like you just want to know the summary and that's what sub agents are really good at. So sub agent in planning for example is just being handed like look at how authentication is implemented um and how we would add a new provider to it and then the sub agent gets that task and it has all um in case of planning it has only read readon access to tools. So it can look at the codebase find files it doesn't do any edits because it's plan mode but it can do these things really efficiently. it can look at a lot of files, run this agent loop, isolate it from the main loop. So, it's own little agent loop uh that just runs on this one task and once it's done with the task, it just returns all the things it found to in a nicely brief summarized way to that planning agent main loop. So, it [snorts and clears throat] means that that the all the planning agent does it gives the task. So that's one piece of context like the the tool call to this to this sub agent tool like do this research and then all it gets back is like this is what I found. So all that file reading and directory listing and uh like testing hypothesis like oh off might be here no it's not over here like that's a different off or is that [clears throat] the right author I have two off files now which one should I pick like need more research. So there's a lot of divergent and converging exploration these agents do but all you get back is like this is what I found and then maybe some confidence with it as well. So that's that's the sub agent solution uh that context isolation to do is like a specific task and the example here is the easiest is read only right you can really easily paralyze um paralyze hard word um to to different sub agents because you can give them different areas to research great for code review for example, that's another topic like you you don't want to read all the files like if you do one code preview on the main main loop you just run out of everything you might want to look at. But if you say, okay, one sub agent for um security, one sub agent for architecture, one sub agent checking code reviews, like checking the slop that AI potentially generates where it doesn't use existing um functionality, maybe that's a whole new utility for something you already had and you can they can all do their thing and it's different focus areas. So it's different ways how you would look for it and then return like security looks good. you might want to check this out. And then slop, there's a new function here. You don't need to create like they all just return their review findings. Um, and which means a you can run those isolated and b you can run them in parallel. And I think the important aspect here too and why sub agents are so important besides the isolation running them in parallel specialized task execution is that they each have their own context window. Right. like you were saying is you're me as developer I want to care about like that main circle that's being filled up the main context as it's going but these sub agents like you said just return back the results right here's the important thing back to the main agent so those sub aents and you can correct me if I'm wrong have isolated context windows as well that are sort of are they just like thrown away at the end of the day or how do those work
>> yes that's I think a key aspect which somewhat makes them challenging to use potentially that they start with zero context. All the context that they have is coming from either the custom agent definition if you use one or from the parent basically telling them the the or the agent orchestrator kind of the main agent to like this is your task and then they start from scratch and they try to do that task and then they answer and then they go away. So that's the kind of isolated one on oneot way that that these agents work. there's no user interaction. They won't ask you. They won't uh there's some um tool permissions that that could pop up if they don't have all the permissions yet. But that's I think something to keep in mind as well. The the very ephemeral memory. It's like a new conversation that you open in in your agent window. There's no context from what the other window was that you just did. It's a it's a new day for the AI. Hopefully your instructions are good and it says access to GitHub memory to understand what it what it should and shouldn't do, but other than that it's it's it's fresh.
That makes a lot of sense. And I think like that's a good context for people to have, especially if you start to like go further with sub agents, start to create agents that you kind of outline and delegating tasks out to sub agents. But I think before we even move on to that, like I think from a day-to-day, I'm inside of VS Code. I'm using plan agent, the main agent, ask agent. Are there any things that I should just be aware of from like a prompting standpoint or a what's being shown? Like should I think about things differently now with these sub agents getting spun up? Should I change my terminology like in some how I write? right? Like if I tell it to use sub agents, like are there things just in my normal day-to-day development that I should be thinking about, you know, just in like the main loop?
>> Yeah. So, I think the goal is everything you do will already be isolated and run in parallel as much as possible. uh right now it you can fall into that pit of success by using plan mode where the expiration that the agent's already doing um will be already run in a sub agent so you get that benefit of context isolation. So that's already an existing area. So plan mode is like if you're already not if you're not not doing it yet uh start doing it and you already get the sub agent benefit. The other way is like we once you ask the agent to do things in parallel and give it guidance on like then you don't necess need to mention sub agents or do any context engineering around it just mention oh like look at these things maybe runs parallel searches and we'll already start doing that as well uh eventually I think what we want to get and what we're having in our uh what I'm working on right now is that like out of the box if you have a larger more complex plan which multiple multiple phases that can run parallel then right now if you do that you probably already get parallel sub aents but it still requires you to like write out the plan in a way like annotating what can be run in parallel so that's something you can do in your planning as well as you maybe write specs or something else that is longer lift and executed through multiple iterations uh calling out what can be run parallel and the agent will will do that um as well very likely It's always indeterministic. So there's never like like the shorefire way. And that's that's on us to like it's one of my goals. Like I want to see everybody benefiting from sub agents heavily in their in the day-to-day that they run as well as possible. So you'll see a lot of improvements over the coming weeks and months in that area that it will just do it out of the box like magically like oh there's a back end and a front end and I can in implement them independently like here is like here's my front end sub aent implement here's my backend implement and in the end they they make sure like it all aligns because they have a good plan to start with and that's really where it all starts that's how work can run in parallel once you have a solid plan that has all the nitty-gritty details because otherwise paramentation is a really hard problem, right? Because like like just how you ask one team member like implement the front end and the other team member implement the back end and when they don't talk to each other, you probably don't end up with a product that works. So they and sub agents cannot really orchestrate that much. They still end up writing something and then they probably send it back to the main agent like I did it and then the main agent can say like yeah but I have two sub agents who did something very differently. So that orchestration bit needs a lot of upfront context building and planning.
That makes a lot of sense. Well, let's get a little bit deeper here too that we have sort of like the the base layer down of agents and sub agents and context windows because I get a lot of questions, you know, next around a like inherently there's built-in, you know, the main agent, your ask agent, your plan agents, but I'm thinking about creating my own custom agents. I think what's interesting as I've been talking to a lot of developers is like there's a lot of new tools in our toolbox, right? We have instructions, we got prompts, we got MCP servers, we got skills, we got custom agents, we have all these things and they all were built to solve a problem and they're a solution. And sometimes those things and the solutions start to overlap a little bit too. But I want to talk about specifically custom agents because now that we have the ability to start to like think about orchestrating these agents like the main agent is doing one way and plan agent is doing another way but me as a team I may want to inherently think about sort of almost replacing that system prompt right and that's where those custom agents come in. So you talk a little bit about in our our year February of 2026, how should developers be looking at custom agents and how does that change actually with sub agents?
>> Yeah. So there's an evolution here. So one is in the beginning we had chat modes which allowed you to customize like change the persona and the workflow of how the agent works. So plan mode easiest example code review another one like it's like distinctive workflows that you want to spend more time in that you maybe have multiple turns like code review is not a one shot you want to like oh like also look at this or uh take a deeper look into this. So they they have been there to like reduce this amount of tools the agent has access to and give it a more specific workflow and goal. um they have evolved into custom agents. Same same thing, new name uh but has kind of come out of the ecosystem of what we call things. Um and now with this release, custom agents can be used for sub agents. And what this means is that if you create a custom agent like deep code research which has like the way you want to look at a repo like I want to like start broad and but also look at other repos maybe it has like a cross repo awareness as well that you you're enforcing to resolve more of the dependencies right maybe there's like a specific thing like how you want how you would look at your repo to better understand it like look at this dependency folder first and then like maybe it's a monor repo So you could you could bring this into a custom agent and then with sub agents now you have a description in that custom agent use when trying to understand crossreo dependencies like that's that's your that's your um cross repo agent that you can then reuse. So crossreer agent with that description will then be invoked by your main agent the just the agent in VS code once a problem needs cross reper understanding. So you can see basically what happens like oh like explain how off works across these repos then the agent has a list of all the custom sub aents uh that are available and then it can call them and you call them in a sub aent way. You could do the same thing in a skill in an agent skill which we shipped but then you would need to handle that orchestration yourself. Maybe the agent skill says oh like use a sub agent and then query these things and then maybe in that workflow the agent also has other tools available because the skill cannot constrain tools. So suddenly gets it might get confused or distracted by what you're trying to do. So a custom agent is a very singlepurpose thing. All it will return is like the based on its workflow, based on its input and based on what you tell it how its output is. So it's a very that's that's what makes it so um composable and skills are composable too but skills will end up in your main context and when they describe a very strict workflow then there might be less adherence because they're in that in your context with all the other stuff that might be there. So there might be multiple skills. There might be like other custom instructions in the repo. It might just more more noise and less likely. There's some some blog post that got shared a lot from versel on skills versus agents.mmd. So skill still has to be discovered by the by the main agent like oh like I'm I'm working on the user is asking me about like this this kind of file type. Maybe it's like a Jupyter notebook and there's a skill for Jupyter notebooks. So it has to realize like that mapping like oh I need to look at the skill and then it needs to read the skill and then hopefully there's some strict adherence to whatever is in the skill how to work with Jupyter notebooks and then the counterpart how to compare it is like what if you put it into agents.mmd which is always in context if it's in the root of your workspace agent.mmd is always top of mind for uh for the agent when it does any task. So they found a lot more adherence of course because there's like an a context bit that's always injected in the agent versus another file it finds along the way as it works on the task. Um and then the same is with custom agents. Custom agents once you write them that's their persona. That's all they think about. So that's thing if you have something that has to be rock solid and really deter deterministic and a workflow you really want to get down to like the really the the right steps then that would be a custom agent.
If it's something more composable where it's more guidance for the agent then that's that's more skill
>> and maybe over time skills become stronger right we'll always work on making sure the agent follows it. Uh hopefully people write good skills because otherwise that that can like the stronger adherence there is the more likelihood it is to be a foot gun. That's pretty cool. Now one thing also that I want to point out too is like that custom agents can also have specific models assigned to them. So in that file I think that's also really unique is you might say okay these models whether it's Gemini or GPT or a claude model is is how like the speed the performance like the context that it needs might be a little bit different and I've actually found this a little bit I was I did a some a video on the new the plan agent updates where you can actually assign like a default model for the plan agent and then when you go to implement back to agent you can have a different model. For example, you might be doing research and say I want to use something like maybe GBT52, but maybe I want to switch over to an implement model that's like an Opus or a Codeex model for example or a Gemini model. So I can use those small ones. So for example, in these small custom agents, maybe use like a flash model for example because they can run super fast on a specific task that you have. Is that like a a realworld use case there for specific models for specific use cases or how do you see that?
>> Oh, totally. I think that's that's one of the key things like why you want to have a custom agent too is like that how much you control you have over that agentic loop and which model it runs in. And yeah, there's multiple like the three categories of models I think about is like one really fast mini models that are just good at automating tasks where you don't have to reason like here's a workflow like just write a commit like I have like a get commit push like just all the good stuff I do is all in in my in my problems and it's all switching to really fast models they don't want and then they're waiting for CI/CD to finish and then they report back right it's just like simple things like just like something I would probably put in the script in the past, but now they're way more adaptive by just running an agent that that runs the terminal for me. So, that'll be like a really fast one. Then the other ones um we do have more specialized like in in the middle ground where they're faster and but still doing a little bit more reasoning behind it. And that's like for code research is a great one. Like if you want to look at many files and figure out which ones are important for a task like what we talked about before, that's a that's good model. It's also where you could maybe even have some fine-tuned models um running eventually for on our site. Um and then it's like the really heavy planning task. And I for example have I'm experimenting with a workflow that's been really nice where I have a custom agent as an orchestrator. So you can switch to to this custom agent which is called loop because I ran out of names. Um [snorts] didn't give it a cool name. Uh but then loop as an orchestrator will have one really fast sub aent to gather context. So again like offloading that context of the main context loop for better name um to into another agent who just writes it to a file and that file becomes then the the memory for all the other follow-up stuff. Then there's a planning one which uses a larger model because for planning I want to look at kind of the the scratch pad that the first agent created which might have a lot of interesting information that was gathered really fast and then planning will look at that and do some more reasoning about it because that's the larger model with opus or 5.2 to codeex and and then next up is the implementation which runs because the plan is so detailed at this point I can take a really fast model that's really good at writing code um and just churns through it writes everything but once and they're actually running parallel because the plan already is outlined you can run these in parallel then because then the orchestrator then says okay I can run things in parallel here are five implement agents doing the work and then I'm going to run the code review agent which again runs a more expensive model to to look at all the code changes in context. So that's think the what I see right now where it's like and I see it happening I think the review takes a bit more time but then it's it's better at finding the edge cases and sending things back like where things diverge from the plan because as soon as you run things in parallel things might diverge. Um so that's that's been really interesting. So that's something to play around with. Also, you can optimize speed and cost and really balance like that quality because like right now if it's like every hour right everything in opus because it's the best model like it's not the right strategy. You can with customs sub agents you can be more efficient and spend less time waiting especially in moments where you want to iterate fast and that's what I see I do in VS Code. I just want to I'm in this messy headsp space like I don't know what I'm really solving for then I just want to see it happening and I don't want Opus building a beautiful vibe coded UI. I just want to figure out like what is that critical thing I'm missing and iterate fast.
Yeah, that's awesome. I love that sort of use case. I think talking about it, it's about real world about how you're developing and I'm the same way like really changing and thinking about the best model, the best tool, the best ability that you know VS Code has for that job. Harold, this has been awesome. I love going from the beginner all the way to this advanced scenario. We'll put links to everything in the show notes. I really appreciate you come coming on talking about sub agents because people are gonna start seeing them every single day. So, let us know. Give the team feedback on the VS Code GitHub. Um, yeah. and really appreciate it, Harold.
>> Thanks so much, James. Thanks everybody.
>> Awesome. Well, don't forget you can subscribe to the VS Code Insiders podcast on your favorite podcast application and of course you can go to vscodeodcast.com. Check out all the things. Make sure you follow us on YouTube, on Twitter, on your favorite socials for all the updates on VS Code every single day because insiders ships every single day with all goodies for your favorite code editor. That's going to do it for this VS Code Insiders podcast. Until next time, I'm James and happy coding.