Imagine feeding a single book draft into an AI.
Instantly, you get five completely different
reviews back. One review is from Linda. She's
a retired teacher, brand new to AI. Another is
from David, a corporate executive. Right. It's
the exact same text draft, but you get completely
distinct parallel perspectives. It feels like
actual magic, but it's really just smart engineering.
It really is. It's a fascinating shift in how
we interact. Okay, let's unpack this. Welcome
to our deep dive today. We're exploring the hidden
power of Claude Code's sub -agents. We're going
to look at what they actually are. We'll see
why they save massive time and money. Then we'll
help you build a custom plan roaster. We'll also
set up vital safety guardrails you need. And
finally, we'll scale up to dynamic workflows.
I'm joined by our expert guide today. Let's dive
right in. Hey there. I'm incredibly excited to
get into this topic. That opening scenario with
the book reviews sounds incredible, but I want
to understand the mechanics here first. How does
that parallel work actually happen behind the
scenes? Well, it's a beautifully simple system
of delegation. You can think of the main chat
as your boss. The sub -agents are the workers.
You only ever talk directly to the boss. Sub
-agents don't talk to you directly either. They
don't even talk to each other. They just do their
job and report back. So it's kind of like a bustling
restaurant kitchen. The main session is the head
chef talking to customers. The sub -agents are
prep cooks chopping onions in the back. Yeah,
that's a perfect analogy. And setting up your
kitchen this way gives four massive benefits.
The very first one is keeping a pristine context
window. Long AI chats get polluted incredibly
fast. Yeah, because you make the AI read up on
stuff. Like reading about Firefly's AI, just
for a quick summary, that junk stays in its memory
forever. Nobody wants that useless noise clogging
up the conversation. Exactly. Every single token
matters. The second benefit is a drastically
lower overall cost. You use the really smart
Opus model for planning, but you spin up cheaper
Haiku models for heavy reading. That makes perfect
financial sense right there. You don't pay a
head chef to peel potatoes. Spot on. The third
benefit is pure parallel work. You can review
15 book chapters at the exact same time. You
could research five different competitors all
at once. That speed is just incredible. I know
trying 15 chapters normally makes the AI hallucinate,
so parallel work clearly fixes that issue. But
what about the actual quality of the feedback?
That brings us right to the fourth huge benefit.
You get a truly fresh review every time. Subagents
always start with completely blank memories.
They give you honest and unbiased feedback. They
aren't trying to be agreeable. Is context pollution
really that big of a deal in normal workflows?
Yes. It's a massive problem. Forcing one model
to hold every file degrades its focus. It loses
its logic over time. So crowded memory makes
the AI lose focus and logic. Exactly. The kitchen
analogy makes total sense to me. I definitely
want those prep cooks saving me time. But if
I'm the head chef here. How do we actually hire
them? How are they given their specific instructions?
It's surprisingly simple under the hood. A custom
subagent is literally just a single markdown
file. You usually store it in a hidden .clodagents
folder. Wait, hold on. Just a standard text file?
I assumed we were talking about complex Python
scripts here. Nope. Just a standard markdown
file. It has two completely distinct parts. The
top part is the YAML front matter. Let's pause
for a second. Define YAML front matter for us.
A small... settings block at the top of a file.
Got it. It holds the name and the trigger description.
It also holds the model you want to use. Just
basic configuration then. So what is the second
part of the file? The second part is the main
body. That's the actual workflow. It tells the
agent exactly how to think. It lists the exact
steps and the required output format. I read
that Claude uses progressive disclosure here.
Why is that specific feature so important? Think
about it like RAM on your computer. If Claude
loaded massive instruction sets every time you
said hello, it would just grind to a total halt.
Progressive disclosure means it only reads that
tiny trigger description first. Ah, I see. So
if the trigger matches, it loads the full body.
That saves a massive amount of processing power.
It's exactly right. Let's look at a concrete
example to make this real. We call it the plan
roaster. I really love that name. It's a phenomenal
tool. The trigger description is kept remarkably
simple. It just says to use this agent to critique
a plan. I have a confession to make here. I still
wrestle with prompt drift and misfires myself.
Beat. It's frustrating when the AI just ignores
your tools. Here's where it gets really interesting,
though. People fall into a psychological trap
when building these. They make those trigger
descriptions way too long. They really do. It's
a very classic mistake. A long description confuses
the whole routing system. You must keep it remarkably
short and punchy. Put the real heavy lifting
down on the body instead. Right. The body is
where you get highly specific. You tell the agent
to find the absolute weakest points. Yeah, and
you tell it to explain what could go wrong. You
want it to be totally ruthless. What happens
if the sub -agent just doesn't fire when I want
it to? Well, that's called a misfire. It usually
means your description is too vague. You fix
it by trimming the description down. If it ignores
you, make the trigger description shorter and
sharper. Precisely. Okay, we know how to build
one now. But once we write this text file down,
where do we actually put it? We don't want these
prep cooks getting lost. You need to understand
skills versus subagents first. Skills run directly
inside your main session context. Subagents run
in a separate, fresh session entirely. But they
aren't totally isolated from each other, right?
They can actually work together. Absolutely.
A subagent can actually invoke a skill. Right.
Imagine spinning up five subagents at once. They
all use a LinkedIn research skill simultaneously.
That is an incredibly powerful combination. It's
like giving your prep cooks power tools. It really
is. Now, for storing these files, you have two
main choices. You have project -level folders
and global -level folders. Let's break down why
you'd use one over the other. Project -level
agents live inside your specific code repository.
They're best for dedicated team workflows. Think
about a strict security reviewer agent. That
makes total sense. Because when you push the
code to GitHub, your entire team gets that specific
agent automatically. It stays directly with the
project it belongs to. Exactly. Global agents
live in your personal user directory instead.
You use those across all your different projects.
A personal writing reviewer is a great example.
If I put an agent in the wrong folder, am I stuck?
Not at all. Since they're literally just standard
markdown files, you can just drag and drop them
to a new folder later. They are just text files.
You can move them anywhere, anytime. Exactly
right. It's highly flexible. Midroll sponsor
read placeholder. All right, let's get back to
it. Okay, we have an army of cheap parallel workers
now. We know how to build them and store them.
But if we let them run wild, they could completely
break our systems. We need to talk about security
guardrails. Security is absolutely non -negotiable
here. You have to adopt a zero -trust mindset.
If an AI can touch something, assume it might.
That is a slightly terrifying but deeply realistic
rule. How do we actually enforce that zero trust
policy? You must use strict tool restrictions.
Always use read -only tools for your review agents.
Our plan roaster doesn't need permission to write
files. It only needs to read your plan and return
feedback. So you only give edit access when strictly
necessary. Never do it by default. Exactly. You
also have to carefully limit your MCP access.
Let's define MCP servers for the listener really
quickly. Tools letting AI talk to your private
databases and apps. Got it. So you don't give
a writing critic database access. Please don't.
That's a recipe for absolute disaster. Imagine
a rogue subagent accidentally dropping your user
tables. You also need to enforce max turns in
your settings. What does the max turn setting
actually do? It firmly caps how long an agent
works. It prevents them from getting stuck in
infinite loops. And it stops them from burning
through your wallet. What about downloading community
agents from public repositories? People really
love sharing their custom setups online. Be incredibly
careful with those. They're still just basic
instruction files. They can easily contain malicious
prompt injection or data leaks. You know what
I think is a brilliant idea here? Building an
AI agent specifically to act as a bouncer? Its
entire job is just to inspect third -party agents.
That's a fantastic safety practice. Build a read
-only verifier subagent just for that exact purpose.
It reviews the code before the boss ever sees
it. Why isn't a prompt like, do not edit files
enough to keep an agent safe? Because text instructions
can be ignored or hallucinated away. Real permission
limits physically block the AI from taking dangerous
action. Never trust a polite request. Use hard
permission blocks instead. That is the golden
rule of agent security. So our system is safely
locked down and isolated now. How far can we
actually push this boss -worker relationship?
What is the true ceiling here? We can push it
remarkably far. Your main session can spin up
massive numbers of sub -agents. We're not just
talking about three or five agents. We're talking
about serious dynamic scale. You can deploy 40.
100 or even 200 agents. And they all run in perfect
parallel simultaneously. I've seen developers
trigger this by typing ultra code. It's kind
of become a meme online. Yeah, that's a dramatic
trigger phrase people use. The use cases for
this scale are completely wild. You can review
a massive legacy code base instantly. You can
test dozens of experimental bug fixes all at
once. Or review a massive thousand page book
chapter by chapter. Two sec silence. Whoa, imagine
scaling to 200 agents testing code -based fixes
at once. That's a whole tech company inside your
laptop. It really is. It fundamentally changes
how fast you can iterate. But there's a very
serious warning here. This burns through your
session limits incredibly fast. It eats through
your API tokens like crazy. Yeah, I can see how
that gets expensive quickly. If you aren't paying
attention, that's a massive bill. Exactly. Don't
use dynamic workflows for small, trivial edits.
Save this incredible power for the truly massive
parallel tasks. When should I absolutely avoid
using a subagent or dynamic workflow? Avoid them
when the task is tiny, or if it depends heavily
on previous chat history, or if it requires constant
back -and -forth conversation with you. Keep
small, highly conversational tasks in the main
chat window. Exactly. Don't overcomplicate the
simple stuff. So... Stepping back from all the
technical execution, what does this all mean
for us? If we connect this to the bigger picture,
the core philosophy here is delegation. You have
to change how you think. Ask yourself a simple
question. Is this task going to dump a huge pile
of text into my chat window? Stuff that I'll
never actually read again. If the answer is yes,
you delegate it immediately. Exactly. Keep the
boss smart on Opus. Make the workers cheap on
Haiku. Keep your context completely clean. And
start small by building highly specific narrow
specialists. We're moving into a really strange
new era. You're no longer just an AI user typing
prompts. You're an actual AI middle manager right
now. Think about the implications of that for
a second. What happens when your subagents eventually
get the ability to hire their own subagents?
At what point do we lose track of the bureaucracy?
There's going to be this massive invisible bureaucracy
happening inside our own computers. Beat. That
is a mildly terrifying but utterly fascinating
thought. It changes the whole definition of personal
computing. It really does. I want to challenge
you, the listener, go into your .cloud agents
folder today. Just write one simple read -only
subagent. See what happens when you delegate
a tiny piece of your workflow. Thanks for joining
us on this deep dive. Let those prep cooks get
to work.