Transcription
What would happen if your coding assistant, Claude code or cursor or something like that, stopped being one clever assistant that you worked with to solve the problem and started acting more like an entire team of engineers that would try to solve the problem that you gave it.
That's exactly what Claude Code, I think, is moving toward with two new features that they released that they did not document. It's in release notes. They're in active cloud code today if you're using it. But I really think it shows a path forward. I don't think it's a told story, but I do think it's really the path forward and I wanted to talk about that and show you what they've released and how you can use it to explore what they're really moving toward. And I really think this shows us really where this is going, but it won't be any surprise to you.
Okay, so what is this all about? Actually, I'm seeing two things that have been released by Anthropic very recently. Two new sub agents. One is a planning sub agent and one is an exploring sub agent. Well, Claude already had the mechanism to do planning and it already has the ability to explore files. So, it's very curious that they've created sub agents out of these things.
First, the planning agent. Planning now can be done basically by Claude. It used to be you had to put the system into planning mode and then ask it to create a plan and then basically execute the plan by moving out of planning mode. Now, Claude Code can choose when to go into planning mode, and it doesn't really need user operation. And that might mean long-term efforts. It can go in and out of planning mode without a user ever needing to get involved. Brilliant. That makes a lot of sense.
The explore system basically saying every time we kind of look around in files, everything it's doing is polluting our context. We don't really need all that exploration. Let's put that into a sub agent. And then I can call that every single time instead of using explore in the way that we have been which is really just cluttering up our own kind of contextual window.
All right, both of these are really smart. But seen together I think that it actually hints at this idea of getting a multi-agent system basically different engineers that are good at different things that can be asked to work asynchronously on a similar project. That's where this I think gets very interesting.
But let's ask Claude what these agents are for. So let's take a look at agents. Here we have a general purpose agent which uses Sonnet, a status line setup agent which also uses Sonnet and the two new ones, the explore using Haiku and the plan agent also using Sonnet.
So what I want to do is I want to ask Claude what these agents are. Can you tell me what the plan agent you have is all about and why it's different than if I entered planning mode? And what Claude says, great question. Based on my available tools, there are actually two different planning concepts. The planning agent, the task tool, autonomous subprocess I can launch using the task tool. Interestingly, the description appears identical to the explore agent, which is interesting because we're talking about both of those here. It's described as a fast agent specialized for exploring code bases that can find files by patterns, search codes for keywords, answer questions about the codebase, support different thoroughness levels, quick, medium, and very thorough. It runs independently and returns results back to me in a single final report. And this is that idea that it has its own context and whatever it finishes with is what comes back to our main context that we're working in.
Introducing something like the planning agent or sub agent allows them to kind of call that midprocess intentionally. That's the intentional point of having this as a subprocess is it can be part of kind of an agentic headless workflow. One that's kind of trying to figure its best path through. It might get stuck at a point and say, "I need a better plan about this. Let me use the sub agent for planning." That's where this really gets exciting. It is interesting that it says the plan agent's description seems to overlap heavily with the explore agent. That's curious.
Okay, so let's do the same thing for the explore agent. Okay. Can you tell me what your explore sub agent is all about and why it might be useful or how it's different from your normal ability to explore and maybe tell me the tools it can use? Okay, it says the explore sub agent is a specialized semiautonomous agent designed for codebase exploration and here's what makes it different. Okay, it says it's specialized for optimized searching and navigating and understanding code bases specifically operates autonomously. Give it a task and explores on its own and it just returns a report. You can use some kind of configurability. You can say do a quick exploration, a medium exploration or a very thorough explanation exploration. That's worth kind of noting. If you're calling it yourself, that's how this might work. If it's calling it, I'm not sure how it will determine which one of those to to use, but that's fine. It has access to all tools, uh, when to use explore versus direct tools. So if you need broad exploration, understanding architecture, open-ended questions, uh multiple related files, those kinds of things you might use the explorer for. But the things that we've been using inside of cloud code and these other systems are better for needle queries, specific file paths, single file searches, and quick lookups. And actually, it says something pretty interesting at the bottom. Says why it's useful. The explore agent prevents me from running multiple rounds of searches manually, missing important related files, using excessive context with repeated tool calls, and incomplete exploration of complex questions. So it goes off, it autonomously explores, consolidates all of those findings and then returns them. And that of course is a sub agent. It's in its own context. So all of that exploration right now when you see it going through all of these tool calls, it's actually it's kind of piling up inside of your context window, which is where all those tokens and your token count and how much and before you compact and these kinds of things get in the way. That's actually really being piled on with all of this extra tool calling from both planning as well as this kind of exploration. Now exploration is always happening within the system. And I would be interested to see if this explore task is kicked off more frequently if we're kind of just exploring the codebase or asking it to do something that is a little bit amorphous.
So I think that's exactly what we should do. You're in an application that kind of shows NFL information to users. The data is kind of cached somewhere so that the users that are viewing the same data will just view the same data again and again. And I feel like maybe we could middle tier a cache layer. Can you use your planning and exploration agents? You have some sub agents that are unique to you and I want to see you use the plan and explore sub agents to solve this problem. And I will say I did name the explore and planning agents here explicitly. I want to make sure that they're called. I don't know that I've seen them get called a bunch on their own. But you can see here both of these, this is kind of Claude Code's mechanism for showing that they're in a task or in a sub agent is this bold uh kind of bullet point that we would be able to go into and see what's being what's being executed inside of each one of those. So that's great. These are the sub agents.
All right. And if I go in and control O to see the thinking in here, you can see what's happening inside of these sub agents themselves. The explore prompt is right here kind of talking about what's needed. Explore and analyze the current caching architecture. So, it's got kind of a big remit to go look through. It goes through and starts exploring a bunch of the different patterns across all of the files. Then, it pops out into the what the planning agent sub agent is thinking and it's got a huge prompt as well that it starts working through uh and also does some of its own exploration which is interesting. So, I would like to see one sub agent calling another sub agent. I think that would be a more efficient methodology here, but I think that's perfectly fine if this is how it's going to work. So, I'm going to let this cook for a bit.
Okay. So, what did we end up with? All right. So, the first instance of the one that you saw me put in, it went and ran 34 tool uses, 75,000 tokens just for the exploration. It took 3 minutes to do that. 17 tool uses, 47,000 tokens, and about 2 minutes to do the design. And then it brought both of those back and said both agents have completed their analysis. Let me synthesize the findings for you. And it went through it. Now the interesting thing is we already implement sophisticated middle tier caching using Firebase Fire Store blah blah blah. Without getting too deep into this architecture to me Firebase is not a middle tier solution. It would be kind of a back-end kind of persistence layer that I have implemented. But at the very least I pay for that layer and that's what I'm trying to protect. And so I went back and told it, I I don't think you're right. I think that we have a misunderstanding of what we call middle tier. Basically, here is what my concerns are. Please, once again, go use those two sub agents. And it says, "Okay, no problem. Let me go look at these problems that you have in regards to it being a back-end service and see what I can come up with." It again did two more minutes of exploration, 17 tool uses and uh 11 tool uses, two more minutes of design or planning and then it came back with the key findings and the analysis of how it might move forward.
Now this is all fantastic. One thing I will say is we can kind of take a look at we have uh 40 50 uh 75 100 may maybe 150 um tokens 150,000 excuse me tokens being used in these two sub agents. So, let's take a look at our context at this point and see what comes up. I have not done this to know uh it says our current context at this point has 24,000 messages in it, which is great. This is really I would expect more of the two reports that it's given back as well as the information that I've given it. That feels reasonable. I can't really prove that specifically, but it's not the 150,000 tokens that we saw the two sub agents take up. Now, admittedly, if I was paying for this per call in that way, I would pay for those calls as well, but they're not disrupting my main uh kind of builder agent that I'm talking to or the coordinator agent is what is actually probably going to become. He didn't necessarily need to worry about all of the work that those sub agents were doing. That's the real value of having these things as self-contained kind of systems themselves or agents themselves.
So, I think this is a very interesting find and an interesting direction to go. uh it just hints to me what we're about to see happen. Okay, so I did ask the system to go and kind of get started with the design that it came back with. Admittedly, I told it to go back into the planning agent that it I thought it had a good solution. Please use the planning agent to create a TDD or test-driven development kind of path so that we would see the tests generate first, start failing, and be able to see them succeed as we moved forward. And it went through and came up with a good plan for all of that. And this is what you're seeing is kind of a resulting plan out of all of its different phases that it's going to build. And I thought this was interesting enough to kind of share that it's actually now coming back and asking me questions. Uh very similar to what the planning mode will do. So you can see it says, "Okay, this is a good approach. Here we go. Prevent regressions. Tests prove they work. Every orchestration will be tracked. Ready to start? I'll implement this using strict TDD. Write all the tests. Shall I begin with phase one? writing the core cache tests." And you can see here's all of its to-dos. So, this I think is quite interesting. And I'm going to tell it just go ahead move forward. And I'm sure it'll come back and ask us, do you want me to move on to phase two as well?
Okay. And I did want to circle back. Last thing I'll show here cuz it doesn't really matter. This is Claude Code building something. We don't need to tell whether or not it did a good job building it. Uh it is worth though mentioning it went from phase one all the way down into the very last set of phases here. So it was not stopping along the way. It was not asking me other questions other than just the verification kind of questions that you might get for for permissions and allowances. So it didn't phase and come back to me like it did after the first or previous to the first phase that we were just looking at. So that's interesting. I don't know what the phases are necessarily for if that's the case, but it is what it is. This planner is a little bit new compared to just the old version of build a plan, get the plan built and then go execute on it. All right.
Okay. So, I think this is a really cool development and it is just kind of uh reading the tea leaves a little bit here. This is available. It's being used in cloud code. So, if you use cloud code, you're already using these potentially agents, but you also might not be. And there are a couple failure points that I can see that I I kind of want to explore a little bit more to understand how they work. For example, I've definitely had troubles with cloud code calling the agents that I would anticipate they call since it's not a direct reference. You're not at naming an agent to call it or something like that. You're hoping that it finds your planning agent or you're hoping that it finds your, you know, logging agent or whatever it might be. And sometimes it doesn't and it just goes off and builds something instead. I've seen that happen. I'm sure that will continue to happen.
Another one is in headless mode like when we use this in Claude on the web or other places that you're calling Claude as kind of a CLI interface or kind of just with a tool at shell that you might then get outputs from. If it starts wandering into a place that it's going to ask you questions or uh try to get more dynamic solutions from it, do we really want those agents being called, can we control that? That's that's the only question in that case is at the very least, can we control it when we know we don't want some of these agents occurring? And that kind of leads into the last one, which is like the ability for it to dynamically choose which model inside of some of these sub agents. Can we tune that? Because I might really want the explore agent to work much harder. I of course can configure that. Maybe that's the definition of how they dynamically choose the model. I'm not really sure. Every time something moves to automation, we lose a little bit of potential control. That's actually good. We do need this high automation that we're going to move away from doing so much. But at an engineering level, there's many, many moments where we really walk into a place that does not have enough controls for us and it really starts to fall apart. So, I'm just cautious about those. I'm not saying they got any of them wrong. Haven't really be been able to evaluate those yet, but those are the things that I look at when we start talking about too much automation, but I actually love the direction this is going.
If the idea is it starts splintering off these concerns that it can reason about, it's going to do explore in one place and plan in another place. Let me say that it sure looked like the planning agent did a lot of the exploration that the explore agent did. And I don't know that they coordinated together all that well. It felt like they came back and coordinated at that main coordinator agent and we didn't really need the explore agent to come back to our main agent and say here's everything I found. We really needed it to talk to the planning agent. So there's this kind of coordination that I think needs to work better as well. Sub agents calling sub agents a lot of other failure points if that starts to happen. Uh but very exciting. I think this is really shows me a direction of where I think we're headed. I hope you saw something in this as well. This was just a simple share to kind of say, "Look, there's some interesting things." They haven't really yelled to the to the masses, this is something we're doing, but I kind of feel like this shows us a direction that we're about to see.
All right, I hope you enjoyed this. Thanks for coming along for a ride on this one and I'll see you in the next.