general-purpose subagents recursively spawn Agent/Task instead of doing bounded work directly

Summary

A subagent dispatched via the Agent tool (default subagent_type: "general-purpose") will sometimes call the Agent/Task tool itself to spawn ANOTHER subagent for a task it could complete directly with Read/Grep/Bash/Edit, then report something like "I've kicked off a background agent, I'll wait for it to finish" — doing zero real work itself. Observed repeatedly across many independent dispatches in one session, and in parallel across other unrelated sessions on the same machine — not a rare edge case.

Root cause (best diagnosis from the outside, no access to internals)

1. A dispatched subagent's context carries no signal that it is already inside a delegation chain — nothing marks it as "you are a leaf worker," as distinct from the top-level orchestrating session.
2. general-purpose subagents are granted the full tool roster, including the Agent/Task tool itself.
3. Given a task phrased as broad or multi-part ("research X across these files," "investigate Y"), the model falls back to a heuristic that's genuinely correct at the top level — parallelize broad research via sub-agents — without any signal telling it that heuristic is wrong once it's already the dispatched worker.

Impact

• Wasted turns/tokens: the dispatch completes with no real work done. The caller has to notice (often only visible via an unusually low tool-call count, or the literal phrase "waiting for background agent") and manually re-dispatch with an explicit "do this yourself" instruction.
• Looks identical to a legitimately long-running task from the outside — surfaces in the Background Tasks panel as multi-hour "Running" agents with 0-2 tool uses total, easy to miss until directly inspected.

Repro

Dispatch a general-purpose subagent with a prompt like "Research X across these files and report findings" for a task that's actually straightforward for one agent to do directly (a handful of greps/reads). In a non-trivial fraction of dispatches, the subagent's final action is spawning another Agent/Task call and reporting it's waiting on that child, rather than doing the greps/reads itself.

Workaround I'm using (not a real fix)

• subagent_type: "Explore" instead of general-purpose for pure read-only research dispatches — Explore's tool grant excludes Agent/Task entirely, so the failure is structurally impossible for it.
• A local PreToolUse hook that nudges toward Explore for research-shaped dispatches, and injects an explicit "you are the worker, not an orchestrator" instruction for dispatches that need Edit/Write (and therefore can't use Explore).

Suggested fix

Either (a) give every dispatched subagent an explicit signal in its system context that it is a leaf/dispatched worker, so it prefers direct tool use over further delegation for a bounded task, or (b) default general-purpose subagents to exclude the Agent/Task tool unless the dispatching prompt explicitly asks for fan-out to multiple named sub-investigations.