Built-in deep-research workflow fans out to ~100 subagents with no upfront estimate or confirmation

Summary

Invoking the built-in deep-research workflow (via the deep-research skill, which delegates to Workflow({ name: "deep-research" })) fans out to ~100 subagents for a single research question, with no upfront estimate, cap warning, or confirmation step. A run I started reached 47 agents before I manually killed it; the worst-case ceiling is ~97. This is surprising and expensive, and there's no obvious knob exposed at invocation time.

Fan-out breakdown

The workflow's agent count is driven by hard-coded constants:

const VOTES_PER_CLAIM   = 3
const MAX_FETCH         = 15
const MAX_VERIFY_CLAIMS = 25

| Phase | Agents (worst case) |
|---|---|
| Scope | 1 |
| Search | 5 |
| Fetch + extract | up to 15 |
| Verify (25 claims × 3 votes) | up to 75 |
| Synthesize | 1 |
| Total | ~97 |

The Verify phase (MAX_VERIFY_CLAIMS × VOTES_PER_CLAIM) dominates the cost.

Expected behavior

Before launching dozens of subagents, the workflow should either (a) show an estimated agent/token cost and ask for confirmation, or (b) expose the fan-out constants as args so the caller can scale it down without editing the persisted script.

Suggested fixes

• Surface an estimated agent count up front and gate large fan-outs behind a confirmation.
• Make VOTES_PER_CLAIM / MAX_FETCH / MAX_VERIFY_CLAIMS overridable via args.
• Lower the default verify fan-out, or document the expected cost in the skill's whenToUse.

Environment

• Claude Code, macOS
• Built-in deep-research workflow (no editable definition on disk; only a per-run script is persisted under ~/.claude/projects/<project>/workflows/scripts/)