subagent-engineering

A subagent is a separate context with its own system prompt. It inherits none of the caller's conversation, and everything it reads is discarded when it stops — only what it returns survives. Isolation is the reason to pay for one, and the return value is the entire product.

Delegate only where the isolation pays

• Delegate work whose output is far larger than its conclusion — a wide search, a long file, a verbose test run. The caller pays for the summary instead of the transcript.
• Delegate to restrict, too. A tool allowlist or a cheaper model binds the whole run, which no instruction inside the main conversation achieves.
• Keep the work in the main conversation when it needs back-and-forth, when several phases share the same context, or when the change is small and targeted. A subagent starts cold: it pays in startup latency and in rediscovering what the caller already knows.
• Write a skill instead when the artifact wanted is reusable instruction text that runs in the caller's own context. A skill carries procedure; a subagent carries a context boundary.
• A subagent runs its own system prompt; an output style modifies the main agent's. A style appends its body to the session prompt and, under keep-coding-instructions: false, drops the # Doing tasks section — it never gives the work a context of its own.
• Check the built-ins before writing a definition — Explore for read-only search on Haiku, Plan for read-only research, and general-purpose, which is what an Agent call gets when it names no type.
• A subagent cannot spawn a subagent. Every fan-out is decided by the caller, so an agent that discovers more work reports it rather than delegating it.