Imagine you are a general contractor working on a project. You don't lay every brick: you call the electrician, the plumber, the painter — each one does their part and hands you the finished work. Claude Code works the same way. You talk to the orchestrator (the main chat). When a heavy task comes up, the orchestrator launches subagents: specialists who do the work in a separate window and return only the summary. This is the design you need to remember.
↑ The subagent flow: one launches, many work in parallel, one summary comes back.
Detailed content
🎼 The maestro and the specialist
The chat you’re talking to is orchestrator — the orchestrator. It understands the request, decides what needs to be done, and, when the task is large, delegates to a specialist. You never stop talking to the conductor: it’s your point of contact from beginning to end.
🏗️ The general contractor analogy
The general contractor doesn’t lay bricks, run wires, or paint walls. They coordinates. Each specialist arrives, does their part expertly, and delivers. The contractor brings it all together and hands you the finished work. The Claude Code maestro is that contractor:
- •Maestro = the main chat. Understands, plans, delegates, brings it all together.
- •Subagent = the specialist. Gets a single task and focuses only on it.
- •You = the project owner. Talks only to the orchestrator and sees the result.
The orchestrator is the main agent — the one that leads the conversation and distributes the work. A subagent is a worker it calls on demand for a specific task.
Without this model in mind, you try to “talk” to the subagent or expect it to remember the whole conversation. Understanding who coordinates and who executes avoids 90% of the initial confusion.
Orchestrator × executor · on-demand delegation · single point of contact (you ↔ conductor).
🔁 The cycle: task → its own window → report
The heart of the subagent is the separate context. When the conductor delegates, the subagent opens a own window — a clean session, isolated from your conversation. It does the work there, creates whatever mess it needs, and returns only a report. The maestro reads that report and communicates back to you. Your window never sees the mess.
The task is dispatched
The conductor identifies a heavy task.
It writes a clear brief and hands it to the subagent: "read these 40 files and tell me where the login breaks".
The subagent works in its own window
Dedicated, isolated, disposable session.
It opens files, runs searches, and accumulates hundreds of lines of reading — all within its own context, which disappears when it finishes.
The report comes back clean
The conductor communicates with you.
The subagent returns the conclusion: "the bug is in the auth.js, line 88". The orchestrator passes this to you — without the 40 files along for the ride.
📊 Why its own window matters
The subagent can "burn" 200 thousand tokens reading files, and that no takes up a single token in your session. You keep the conclusion; the raw reading stayed in its disposable window. This is context protection — the topic of the next module.
🎭 The 5-persona demo
The classic example: you ask the conductor to review a book under five different perspectives. Instead of doing five readings in a row, it opens five subagents in parallel — each with one lens own. They run at the same time, each in its own window. And you can enter each session and see exactly the prompt the orchestrator sent to that specialist.
Linda, 58
Retired teacher · beginner in AI
"Does this make sense to someone who’s never heard of the subject? Where did I get stuck?"
Software engineer
Technical perspective
"Are the code examples correct? Is anything lacking rigor?"
Business owner
Return perspective
"What’s the practical value? Does this help me make or save money?"
David, 52
Fortune 500 COO · a scaling perspective
"Does this work with 5,000 employees? Where does it break in a large-scale operation?"
Editor / publisher
Editorial perspective
"Does the text flow well? Does the argument hold up from beginning to end?"
Five in parallel
Five lenses, at the same time, each in its own window. The conductor brings the five reports together.
💡 You can inspect each session
Each subagent runs in a visible session. You can open the “COO” session and read the exact briefing the conductor wrote for it. This demystifies the subagent: it isn’t magic; it’s a focused chat someone opened for a task.
🚫 What a subagent is NOT
This is where the most common confusion lies. The subagent isn't the main chat and you doesn't talk to it directly. It doesn't answer you — it answers to the orchestrator. Thinking of it as "another chat where I type" is the mistake that makes everything seem broken.
✓ What the subagent IS
- ✓A focused worker, triggered by the orchestrator
- ✓Owner of a separate context window
- ✓Who returns a report and disappears
- ✓Answerable to the conductor, not to you
✗ What the subagent is NOT
- ✗It's not your main chat
- ✗It's not someone you type to directly
- ✗Doesn't retain the memory of your conversation
- ✗Doesn't respond to you — responds to the orchestrator
⚠️ The mistake that trips up beginners
Trying to "reply" to a subagent as if it were a chat window. It isn't waiting for your input — it has already received the maestro's briefing and is executing. If you want to change something, you talk to the orchestrator, and the conductor adjusts or launches a new subagent.
🔗 1-to-1 relationship with the orchestrator
Each subagent speaks only with the maestro. Subagents don't talk to each other. It's a star model: the conductor at the center, each specialist connected to it by a direct line, and no lines between the specialists. This keeps everything predictable — no "telephone game" between workers.
✓ How the flow works
- ✓Subagent → conductor (report)
- ✓Maestro → subagent (briefing)
- ✓The conductor combines everyone’s reports
✗ What doesn’t work
- ✗Subagent A → subagent B
- ✗Two subagents “negotiating” an answer
- ✗One subagent reading another’s window
🚀 First contact — invoke a built-in
You don’t need to create anything to get started. Claude Code already comes with subagents built-in
(such as the general-purpose, which researches and reads files). To invoke one, just
natural language: you describe the service and the orchestrator decides whether to delegate. No special command, no difficult syntax.
você > Pesquise a ferramenta "ripgrep" e me traga só
um resumo de 5 bullets, sem encher meu contexto.
# o maestro decide delegar a um subagente built-in,
# que abre a janela dele, faz a pesquisa pesada,
# e devolve ao maestro só os 5 bullets pedidos.
maestro > Pronto — 5 pontos sobre o ripgrep:
1) busca recursiva ultrarrápida em texto …
💡 The triggering phrase
Two clues prompt the orchestrator to delegate: "just give me a summary" (the output is small) and "without filling up my context" (the reading is large and disposable). That's exactly the ideal case for a subagent — and the subject of the "deciding question" back in module 1.5.
Real example: a subagent in a file
A custom subagent is just a file .md: a configuration header
(frontmatter) and a body with the instructions. You’ll examine each field in the
following tracks — for now, read this code-reviewer.md just enough to get a feel for it.
--- # frontmatter: a CONFIGURAÇÃO do subagente
name: code-reviewer # minúsculas e hífens
description: Revisa o diff atual em busca de bugs,
falhas de segurança e testes faltando. Use após
qualquer mudança de código. # isto é o GATILHO
tools: Read, Grep, Glob # só leitura: não edita nada
model: sonnet # bom o bastante para revisar
---
# corpo: o CÉREBRO do subagente
You are a senior code reviewer.
When invoked:
1. Run git diff to see what changed.
2. Read the changed files and understand the intent.
3. Review for correctness, security and missing tests.
Flag: bugs, security holes, and missing tests.
Be concise. Do not rewrite the code — only report.
⚙️ The frontmatter (config)
- name — how the orchestrator calls the agent.
- description — the trigger: lets the orchestrator know when to use it.
- tools — what it can do (here, read only).
- model — which model runs the task.
🧠 The body (brain)
- Role — "you are a senior code reviewer".
- Steps — what to do, numbered.
- Output — what to report.
- Limits — what NOT to do (don't rewrite).
Ready-made prompts (copy and paste)
Two prompts for you to invoke a built-in subagent right now, without configuring anything. Notice the pattern: ask the summary and protect the context.
Abra um subagente pra pesquisar a ferramenta X e me
traga só um resumo de 5 bullets. Não cole o conteúdo
bruto aqui — só a conclusão.
Use o general-purpose pra ler estes arquivos e me
resumir o que importa, sem encher meu contexto.
Devolva no máximo 1 parágrafo + os caminhos relevantes.
Simulated screen: 5 parallel subagents
This is how the demo with the 5 personas appears in the terminal: the lead launched five subagents, and you can see them running side by side, each with its own model and progress. Below, the status line shows how much of the your context is in use — and it barely changes, because the heavy work is happening in their windows.
↑ Illustrative recreation of the terminal (not a real screenshot). Note the 5 subagents working at full speed while your context barely moves.
Exercise
List 3 tasks from your day that would make good subagents. For each one, justify it with the deciding question: "will this dump stuff I'll never reread?"
How to do it
- Think about things you do on the computer that read a lot, generate a lot of output, or if they repeat.
- Write the task in one line (e.g., "search 30 PDFs for a clause").
- For each one, answer the deciding question — and say which criterion it meets.
✅ Verification criteria — how to know you got it right
Each task you listed must meet at least one from these three signals:
- →Reads many files (the raw reading doesn't need to stay in your context).
- →Produces a lot of output that you'll never reread in full (you only want the conclusion).
- →It’s repeatable or parallel (can be run multiple times, or several at once).
If a task is a quick edit or requires the entire conversation, it no is a candidate—and recognizing that also counts as a success.
Solved example
Task: "read 30 contract PDFs and find where the termination clause appears". Good subagent? Yes — it reads many files and generates a lot of output I won't reread; I only want "found on page X of each contract." Meets 2 of the 3 signals.
✅ Module summary
Next module:
1.2 — The real reason: clean context. Why protecting context is the #1 reason for subagents.