Allow agents spawned inside a Workflow to spawn their own subagents

Summary

Agents launched from inside a Workflow script (via the agent() hook) are handed a toolset that omits the subagent-spawning tool entirely. This means a workflow agent cannot fan out into its own subagents, whereas a normal subagent (spawned via the Agent/Task tool) can nest freely. I'd like workflow agents to be able to create subagents too.

Evidence

I ran a controlled test — a normal subagent vs. a workflow agent — each asked to spawn a child and get a "PONG" back:

| | Normal subagent (control) | Workflow agent |
|---|---|---|
| Has Agent/Task tool? | Yes (Agent) | No |
| Could load one via ToolSearch? | n/a | No — select:Task,Agent → "No matching deferred tools found" |
| Actually spawned a subagent? | Yes | No |
| Got PONG back? | Yes | No |

The workflow agent's literal toolset was:

Bash, Edit, Read, SendUserFile, Skill, ToolSearch, Write, StructuredOutput

No Agent, no Task — and ToolSearch confirms they aren't even loadable as deferred tools for it.

Analysis

This isn't a recursion-depth limit (the workflow agent is only one level down). It's a deliberate toolset restriction: agents spawned inside a workflow are given a tool set that excludes the subagent-spawning tool. A normal subagent gets Agent and nests fine; a workflow agent never gets it. That's the asymmetry.

Request

Allow agents spawned inside a workflow to spawn subagents (e.g. by including the Agent/Task tool in their toolset, or making it loadable via ToolSearch). This would let workflow stages decompose their own work instead of being limited to a single flat level of fan-out per stage.