Delegate with subagents

Subagents run an independent task in their own context window and report back a conclusion. They suit broad searches, multi-file audits, and anything you would otherwise grind through serially in your main session.

When PromptConduit flags this

PromptConduit counts a subagent each time the agent calls the Agent or Task tool, and records the subagent type (Explore, Plan, general-purpose, or a custom name) and duration.

The “Delegate with subagents” tip fires when there are zero subagents and a lot of tool activity:

• Editor extension (live session): at least 40 tool calls and no subagents, in a session with at least 3 prompts.
• Web Trends view: at least 200 tool calls and no subagents across the selected period, with at least 5 prompts.

The tool-call bar is there on purpose. A short session with no subagents is fine. The tip only appears when the volume of work suggests some of it could have been delegated.

Why it matters

Two mechanisms:

1. Context hygiene. Every file read and search result in your main session stays in its context and is resent with every later request. A subagent does its reading in a separate context and returns only the findings. Anthropic’s cost guide recommends delegating verbose operations (running tests, fetching docs, processing logs) for exactly this reason. A smaller main context is cheaper per turn and less likely to hit auto-compaction.
2. Parallelism. Independent pieces of work can run concurrently instead of one after another. Three exploration tasks that don’t depend on each other don’t need to wait on each other.

Subagents are not free. Each one makes its own requests and starts its own cache rather than reading the parent’s. The win comes from keeping bulky, throwaway reading out of the conversation you keep paying to resend.

What to do

Ask for delegation explicitly. In Claude Code:

Use a subagent to investigate how our auth system handles token refresh.
Report the files involved and the refresh flow, not the file contents.

Fan out independent work. When a task splits into pieces that don’t depend on each other, ask for them in parallel:

Research the auth, billing, and notifications modules in parallel using
separate subagents. For each, list the public entry points and any TODOs.

Give each subagent a self-contained brief. It starts with fresh context and does not see your conversation history, so include the paths, the question, and the shape of the answer you want.

Define recurring roles once. If you keep asking for the same kind of review or audit, save it as a custom subagent in .claude/agents/ (project) or ~/.claude/agents/ (personal):

---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
---

You are a code reviewer. Analyze the code and give specific, actionable
feedback on quality, security, and best practices.

Restricting tools keeps a read-only role read-only. For simple tasks you can also set a smaller model in the frontmatter to lower its cost.

Keep synthesis in the main session. Use subagents for “go find out” work and make the decisions yourself, with the conclusions in front of you. For parallel edits, give each subagent its own worktree so they don’t collide; see isolate risky work in a worktree.

How to check it worked

In the editor extension’s coaching tab, the Subagents cell shows the count and average duration for the live session, and notes “up to N in parallel” when several were spawned in the same batch. The Skills & subagents and Subagents sections break usage down by type. The Subagents / day sparkline tracks the trend.

Two side effects should also show. The batching score in the same tab tends to rise when independent work runs together (see batch your tool calls). And your main session’s context stays smaller, which you can watch with Claude Code’s /context command. To watch the session graph of turns and subagents live, run promptconduit graph. Setup is in /docs/editor-extension.