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 aents. one is a planning sub

agent and one is an exploring sub aent.

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 aents

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- aent 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 thoroughess 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 agents 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 auton 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 aents.

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

aents 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 aent calling

another sub aent. 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 aigens

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

aents. 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 aents 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