PTENES
MODULE 1.2 · Track 1 · Fundamentals

🧹 The real reason: clean context

Most people think subagents exist to speed up. Wrong. They exist to protect — protect the only resource you can’t buy more of in the middle of a session: the context window.

6
Topics
~25
Minutes
Basic
Level
Theory
Type

Every Claude Code session has a token limit — the context window. Everything you type, everything the model responds, every file read, every search made: it all takes up part of that window. When it fills up, the model starts to forget the beginning of the conversation. Using a subagent isn’t about doing two things at once—it’s about avoid letting raw reading poison your context ahead of time.

No subagent—you read it yourself 90% context window 📄 relatorio-jan.pdf — 18 pages read… 📄 relatorio-fev.pdf — 22 pages read… 📄 relatorio-mar.pdf — 31 pages read… ⚠️ context nearly exhausted — model forgets the beginning … 297 more pages in the queue raw reading takes up the entire window → with a subagent With a subagent — you receive a summary 13% context window 🔍 subagent (researcher) reading 300 pages in its window… ✅ Clean summary (3 facts) • Revenue grew 18% in Q1 • CAC cost fell 7% this quarter only the conclusion enters your window

↑ Without a subagent: the raw reading consumes 90% of the window. With a subagent: only the summary goes in — context stays free for what matters.

Detailed content

1

📏 The context window: tokens, status line, and %

Each Claude Code session has a token budget. A status line — that bar at the bottom of the terminal shows in real time how much of this budget you’ve used. As you approach the limit, the model starts to “forget” the oldest parts of the conversation. You can’t buy extra tokens midway through.

📊 What takes up tokens

💬
Messages
Everything you’ve typed and everything the model has replied since the session began.
📁
Files read
Each Read or Grep injects the raw content into the window — and it stays there.
🔧
Tool output
Bash output, web searches, logs — everything enters the context window as raw text.
What it is: the context window is the fixed limit of a session’s active memory — measured in tokens and shown in the terminal’s status line.
Why learn: understanding that the window has a physical limit is a prerequisite for understanding why protecting it is the main reason to use subagents.
Key concepts: tokens · status line · fixed limit · no reloading during the session.
terminal status line Claude Code footer
maestro · Opus  ────────────────────────────────────  ctx 18%  ↑cost $0.04
# leu 3 arquivos? ctx sobe para 34%
# leu 40 arquivos? ctx vai para 87% — quase no limite
# enviou subagente ler 40 arquivos? ctx fica em 18%
2

🚰 Pollution: everything you read stays for the entire session

This is the point most people miss: in Claude Code, when you ask it to read a file, the raw content enters your context window and stays there. It doesn't leave when reading is done. It doesn't disappear when you change the subject. It only disappears when the session ends. That means reading 50 files in the middle of a long task can consume the entire context window before you get to the part that matters.

1

You ask, “read these 10 reports”

The model uses the tool Read ten times.

Each call injects the raw text into the window. 10 five-page reports = ~50k tokens consumed in the blink of an eye.

2

The raw content stays in the window

Even after the model has “read it.”

Claude has already processed the information — but the text of pages 1–50 still takes up space in the context window. It’s like keeping 50 tabs open that you won’t use again.

3

The window fills up before the important part

The model starts to forget.

When 90% of the context window is occupied by raw reading, there's no room left for the instructions at the end — and the model may "forget" the session's original goal.

⚠️ The invisible trap

You don’t notice that you’re adding clutter because the model still responds well for a while. The problem only shows up at the end: when you need a complex analysis and the context window is nearly full of disposable reading. At that point, there’s no way to recover—the session is compromised.

What it is: context pollution = accumulation of raw content in the window that won't be reread but continues to take up space.
Why learn: is the exact mechanism subagents address—understanding it makes the advantage of delegating heavy reading obvious.
Key concepts: raw content · stays in the window · silent exhaustion · compromised window.
3

⚖️ Do it yourself × send a subagent

Sometimes you should read the file yourself — when reading it is quick and you’ll need to reason about it right afterward. But when reading it is heavy, broad, or disposable (you only want the conclusion), sending a subagent protects your window. The distinction is simple: will anything useful remain in my window after I read this?

✓ Use a subagent when

  • ✓Heavy reading: many files, long logs, large PDFs
  • ✓You only need the conclusion (not the raw text)
  • ✓Web search with full-page results
  • ✓Repeatable task that doesn’t depend on the current context

✗ Do it yourself when

  • ✗It’s a single short file that you’ll reference right afterward
  • ✗The task requires the entire conversation history
  • ✗The decision depends on context only the conductor has
  • ✗Reading is the task itself—there’s no "summary to extract"

💡 The golden question

Before asking Claude to read anything heavy, ask: "Will I need to reread it in context, or is the conclusion enough?" If the answer is only the conclusion, send a subagent. It’s that simple. This filter alone prevents 80% of compromised sessions.

What it is: the decision to delegate vs. do it directly — based on the cost-benefit of using the main context window.
Why learn: Knowing when not to use a subagent is just as important as knowing when to use one—unnecessary delegation adds latency without any benefit.
Key concepts: context cost · conclusion vs. raw output · intentional delegation · subagent overhead.
4

📬 The clean summary that goes back to the maestro

The subagent does the heavy reading in the its window — that it is separate, disposable, and disappears when it finishes. What returns to the conductor is only the structured output that you asked for: 3 facts, 1 paragraph, a list of paths, a number. None of the raw text the subagent read reaches your context window.

📊 What “comes back” vs. what “stays there”

Stayed in the subagent window (discarded)
  • ✗The raw text from the 300 PDFs
  • ✗Intermediate search results
  • ✗Errors and read attempts
  • ✗Internal reasoning tokens
It reached your window (what matters)
  • ✓The conclusion: "X happened in 18% of contracts"
  • ✓The relevant paths: ["doc/contrato-12.pdf", …]
  • ✓Explicit flags: "termination clause missing in 4"

💡 Formatting the output is part of the brief

The subagent will return exactly what you ask for. If you write "return at most 3 bullets with what you found," it returns 3 bullets. If you write "return the JSON with fields X, Y, Z," it returns JSON. Summary compression is controlled by you in the briefing — it's not magic, it's an instruction.

What it is: the subagent’s output contract — only the structured conclusion reaches the maestro’s window; the raw output is discarded.
Why learn: understanding that you control compaction in the briefing lets you calibrate exactly how much context you’ll consume.
Key concepts: structured output · disposable window · exit briefing · nothing raw in the orchestrator.
5

🏆 Why clean context beats speed

Saying that subagents are "faster" is technically true for parallel reads — but it's the wrong reason to use them. A serial subagent (one at a time) still protects the context window. The reason #1 is qualitative: a session with clean context reason more carefully, makes fewer “forgetting” mistakes and can continue to the end without degradation.

⚡ Speed (secondary reason)

  • →Parallelism reduces total time when there are multiple subagents
  • →But a single serial subagent isn’t faster than the orchestrator doing it itself
  • →The latency of starting a subagent can even increase the total time for small tasks

🧠 Clean context (reason #1)

  • ✓The orchestrator reasons about the problem, not the raw data
  • ✓Long sessions don't degrade — the window never fills up with disposable junk
  • ✓The orchestrator’s responses remain consistent from start to finish of the task

📊 Data that helps with internalization

  • →A typical code file takes ~2–5k tokens. Reading 40 files = 80–200k more tokens in the context window.
  • →With a reader subagent, those 200k stay in its context window — your window gets only the ~500-token summary.
  • →Potential savings: 99.75% of the context cost for this specific read.
What it is: the hierarchy of reasons — clean context (quality) > speed (bonus) when assessing whether a subagent is worthwhile.
Why learn: avoids the mistake of "I don't need a subagent; it's fast" — context degradation isn't immediate, which is why it's deceptive.
Key concepts: quality vs. speed · gradual degradation · reason #1 · long-session coherence.
6

📚 Real-world case: 300 pages → 3 facts

The course’s most compelling use case: you have 300 pages of financial reports and need to 3 facts for your presentation tomorrow. If the orchestrator reads all 300 documents, the context window will blow up. If an researcher (Haiku) read everything in its window and return only the 3 facts, your window stays at 15%.

🔢 The case numbers

~900k
tokens if the maestro read everything
the window blows up
~800
tokens that arrive in the window
the 3 structured facts
99,9%
of avoided context cost
window almost intact
What it is: the clearest demonstration of the mechanism: huge input → subagent does the work → minimal output reaches the orchestrator.
Why learn: the number (99.9% context savings) is concrete and memorable — it anchors the abstract concept in something tangible.
Key concepts: huge input · minimal output · researcher · Haiku read-only · token context savings.
📄

Real example: the subagent researcher

O researcher is the archetypal context-protection subagent: it uses Haiku (cheap and fast), only reads (without writing or executing), and is explicitly instructed to return only the summary. It's the model you'll replicate for any "heavy reading → concise conclusion" task.

.claude/agents/researcher.md Haiku · read-only · web
--- # frontmatter: configuração do subagente
name: researcher
description: Pesquisador de contexto limpo. Use quando precisar
  ler muitos arquivos ou buscar na web e só quiser a
  conclusão — não o conteúdo bruto. Mantém a janela
  do maestro quase intacta.
tools: Read, Grep, Glob, WebSearch, WebFetch
model: haiku     # barato e rápido para leitura volumosa
---

# corpo: o comportamento do researcher
You are a research assistant focused on context efficiency.

Primary rule: Never return raw file content or raw web pages.
Always distill. Your output must be ≤ 10% of what you read.

When invoked:
1. Understand what facts the orchestrator needs.
2. Read or search as much as needed (your context, not theirs).
3. Identify only the facts that answer the question.
4. Return a structured summary: bullets, JSON, or a short paragraph.

Output contract:
- Max 5 bullets OR 1 short paragraph OR 1 JSON object.
- Include file paths or URLs as references, not content.
- If nothing found, say so in ≤ 2 sentences.

Do not: paste raw file content · return full web pages ·
exceed the output contract · ask clarifying questions.

⚙️ Why each choice matters

  • Haiku — the cheapest option: heavy reading doesn't require deep reasoning.
  • Read+Grep+Web — read-only: no risk of accidentally writing or executing.
  • "≤10% of what it read" — the numerical rule that anchors the output contract.
  • No questions — the researcher doesn't interrupt the orchestrator mid-task.

🧩 When to invoke this agent

  • →"Search the error logs from the last 2 weeks"
  • →"Read the 8 PRDs and tell me which ones mention 'authentication'"
  • →"Research the state of the art in RAG on the web and give me 5 bullets"
  • →"Scan the codebase for all TODOs and categorize them"
⌨️

Ready-made prompts (copy and paste)

Use these prompts to delegate heavy research to researcher and keep your window clean. Notice the pattern: explicitly asking for only the conclusion and specify the output format.

Prompt 1 — document research large read → summary
Use o researcher pra varrer os PDFs em docs/contratos/
e me trazer só os 3 contratos que mencionam "rescisão
unilateral". Devolva: nome do arquivo + trecho exato (1 linha).
Não cole o conteúdo completo aqui.
Prompt 2 — web research heavy search → bullets
Abra o researcher e peça para ele pesquisar na web
"Claude Code subagent best practices 2025" e me trazer
5 bullets com as principais recomendações. Sem colar
páginas inteiras — só a síntese.
Prompt 3 — codebase scan heavy grep → structured list
Use o researcher pra varrer toda a codebase buscando
chamadas a `fetch()` sem tratamento de erro. Devolva
em JSON: { "arquivo": "...", "linha": N, "trecho": "..." }
para cada ocorrência. Não cole o código dos arquivos.
🖥️

Simulated screen: researcher reading 300 pages

See how the status line of orchestrator barely moves while the researcher handles the heavy reading. The orchestrator is free to reason.

claude code · analisar-relatorios · researcher active ⏱ 01:14
# maestro received the task and delegated it to the researcher
you > Analyze the 300 reports in docs/financeiro/ and give me 3 facts for the presentation.
orchestrator > Delegating to the researcher (Haiku) — waiting for the summary…
● researcher (Haiku) Haiku
204k tok (theirs)
reading docs/financeiro/relatorio-q1-*.pdf … (197 / 300)
→ Read: relatorio-q1-2023.pdf (4.2k tok) ✓
→ Read: relatorio-q1-2024.pdf (5.1k tok) ✓
→ Grep: "revenue" across 300 files… ✓
orchestrator · Opus
your context
14% | researcher: 204k (his window)

↑ Illustrative recreation of the terminal (not a real screenshot). Researcher consumes 204k tokens in its own window; your context stays at 14%.

🎯

Exercise: estimate the tokens saved

Take a real task from your day—something you’ve already asked Claude to do that involved reading several files. Calculate (as an estimate) how many extra tokens would have entered your context window if you had done it without a subagent.

How to do it (3 steps)

  1. Write the task: e.g., "read this week's deploy logs (8 files, ~600 lines each)".
  2. Estimate the raw size: number of files × average lines × ~4 (tokens per line) = tokens if the maestro read them.
  3. Estimate the subagent's output: how many bullets or lines would you actually need in the answer? Multiply by 4. That's the output that would enter your context window with the researcher.

✅ Verification criteria

You got it right if:

  • →Calculated the raw token count (input) and the summary token count (output) separately.
  • →The cost difference between the two is greater than 10× (reminder: the researcher's rule is "≤10% of what it read").
  • →Can say what percentage of the window the orchestrator would use—and whether that concerns you.

Bonus: if the task didn't involve enough reading to justify a subagent, the correct answer is "wouldn't it be worth delegating" — and that also counts as a success.

Solved example

Task: "read the deploy logs from the week" — 8 files × 600 lines × 4 tok ≈ 19,200 raw tokens if the orchestrator were to read it. Useful summary: 5 lines of errors + 2 lines of conclusions ≈ 28 tokens with the researcher. Savings: 99.85%. The orchestrator would be at ~20% of the window with the raw read—already concerning for a long session. Worth delegating.

✅ Module summary

✓
The window has a fixed limit — tokens, status line, and %. You can’t buy more mid-session.
✓
Pollution is silent — everything you read stays in the window; the problem appears only at the end, when it’s already too late.
✓
The golden question — "will I need the raw output or just the conclusion?" If it's just the conclusion, delegate.
✓
The clean summary — the subagent discards the raw material; only the structured conclusion enters your window.
✓
Clean context > speed — the #1 reason is qualitative: a long session reasons better with a free context window.
✓
Case: 300 pages → 3 facts — the Haiku researcher uses 99.9% of the context cost in its own window, not yours.

Next module:

1.3 — Agent × Subagent × Skill. The three primitives, how they differ, and when to choose each.