PTENES
MODULE 1.1 · Track 1 · Fundamentals

🤖 What is a subagent

Before creating anything, you need to understand the right mental model. The main chat is a orchestrator that delegates tasks to specialists — and gets back a clean report without carrying all the dirty work.

6
Topics
~25
Minutes
Basic
Level
Theory
Type

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.

Maestro the main chat subagent subagent subagent subagent subagent … Summary comes back to you

↑ The subagent flow: one launches, many work in parallel, one summary comes back.

Detailed content

1

🎼 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.
What it is:

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.

Why learn:

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.

Key concepts:

Orchestrator × executor · on-demand delegation · single point of contact (you ↔ conductor).

🎼
Maestro
coordinates
🔧
Specialist
runs
📦
Delivery
summary
👤
You
sees the big picture
2

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

1

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

2

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.

3

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.

What it is: the three-beat cycle — dispatch, isolated work, report back.
Why learn: is what makes delegating different from "doing it yourself in the same chat": the mess stays outside your window.
Key concepts: own window · disposable session · report (not the entire conversation).
3

🎭 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 it is: multiple subagents in parallel, each with a different perspective on the same material.
Why learn: shows parallelism in practice and reveals that each subagent gets its own briefing from the conductor.
Key concepts: parallelism · diverse perspectives · subagent briefings · inspectable sessions.
4

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

What it is: the boundary of the concept — what the subagent deliberately does not do.
Why learn: eliminates the wrong expectation of "talking" to it and shows who it actually answers to.
Key concepts: isn't the chat · no direct dialogue · no memory of your session · responds to the maestro.
5

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

Star (correct) Mesh (doesn’t happen) sub sub sub sub orchestrator sub sub sub sub subagents don't talk to each other

✓ 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
What it is: star topology — every subagent connected only to the maestro, never to each other.
Why learn: explains why the system is predictable and why "subagents that would need to talk to each other" are a sign to avoid using subagents.
Key concepts: 1-to-1 relationship · no side communication · conductor as hub.
6

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

in your chat natural language
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.

What it is: trigger an existing subagent just by describing the task in Portuguese.
Why learn: takes the fear out of the concept: you can use subagents today without configuring anything.
Key concepts: built-in · natural language invocation · general-purpose · automatic delegation.
📄

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.

.claude/agents/code-reviewer.md Markdown + YAML
--- # 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.

Prompt 1 — research and summarize delegates heavy research
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.
Prompt 2 — read files without clutter protects the context
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.

claude code · revisar-livro · 5 subagents ⏱ 00:48
● beginner (Linda)Haiku
96k tok
● engineerSonnet
142k tok
● business ownerHaiku
73k tok
● COO (David)Sonnet
118k tok
● editorHaiku
81k tok
5 active subagents · final synthesis waiting for all 5 reports
orchestrator · Opus
your context
12%

↑ 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

  1. Think about things you do on the computer that read a lot, generate a lot of output, or if they repeat.
  2. Write the task in one line (e.g., "search 30 PDFs for a clause").
  3. 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

✓
Maestro × specialist — the main chat coordinates (general contractor); the subagent handles a task.
✓
The cycle — task → subagent’s own window → clean report that the orchestrator passes on to you.
✓
5 personas — several subagents in parallel, each with a different perspective and its own brief.
✓
What it is NOT — it's not the chat; you don't type to it; it responds to the orchestrator.
✓
One-to-one relationship — star topology: each subagent only talks to the orchestrator; they don't talk to one another.
✓
First contact — invoke a built-in using natural language: "research X and give me only the summary".

Next module:

1.2 — The real reason: clean context. Why protecting context is the #1 reason for subagents.