Four ideas, one per screen. Each is a thing to point at while you explain. The drama is in the watching, so take the silences.
Four moves: understand what a subagent is, build one, design it well, then judge when to reach for it at all.
/agentsIt gets a role and a task, does the messy work out of sight, and hands back only the answer.
Built in already: a general-purpose agent, Explore for fast search, and Plan for plan-mode research. The tradeoff: you lose sight of how it got there.
/agents: Claude writes the fileDescribe what you want; Claude generates the name, description and system prompt. It's a markdown file with a short YAML header.
Scope it project-level (this repo) or user-level (everywhere). Put the word "proactively" in the description and Claude will delegate without being asked.
A good subagent is steered by its description, knows when to stop, reports what it hit, and touches only what it must.
The description does double duty: it decides when the subagent launches and shapes the task prompt the main agent writes for it. Vague in, vague out.
That one question decides it. If you don't need to watch the journey, delegate. If you do, keep it in your main thread.
Why code review makes the list: Claude critiques code more honestly when it didn't write it. A fresh-context reviewer beats asking the thread that built the feature.
A subagent runs in its own context and returns a summary. Build it with /agents, steer it with a sharp description and an output format, and reach for it only when the journey doesn't matter.
tutto.one/praxis · daniel@tutto.one