[FEATURE] Expose queued/pending Workflow subagents to SDK / headless clients (only visible via in-process /workflows)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When the Workflow tool spawns N subagents (e.g. via parallel()/pipeline()), the runtime runs up to ~availableParallelism of them concurrently and queues the rest. On a small host (e.g. 2 vCPUs) only ~2 run at a time and the other N−2 wait.

A headless / SDK client (a custom UI built on @anthropic-ai/claude-agent-sdk) has no way to observe the queued, not-yet-started subagents. It can only see a worker once it has started. So a workflow the model describes as "spawning 10 subagents" renders in a custom UI as just the ~2 that currently fit the concurrency cap — the queued 8 are invisible until they begin.

The interactive /workflows command shows the full roster (running and queued) — but only because it runs in-process and reads the workflow engine's live in-memory roster directly. That roster is never exposed to an out-of-process SDK consumer.

What I verified (TypeScript SDK)

With a 15-subagent workflow and a ~68s queued window (sampled on disk every 0.5s), queued workers are absent from every client-accessible surface:

• task_started fires only for the workflow itself (task_type: "local_workflow") and each running worker's internal local_bash — never for a queued worker.
• SubagentStart/SubagentStop hooks fire only when a worker starts.
• background_tasks (on StopHookInput / SubagentStopHookInput) contains a single { type: "workflow" } entry — never the individual workers, running or queued.
• The Query API has stopTask / backgroundTasks / supportedCommands but no listTasks() / getWorkflowState().
• On disk: the run-state summary (wf_*.json) is written at completion; the live journal.jsonl records only started / result events — no queued entries.
• The CLI subprocess's stderr does not carry the roster either.

So the queued roster lives only in the engine's memory and is reachable only by the in-process /workflows TUI.

Proposed Solution

Expose a workflow's queued/pending workers to SDK/headless clients via any one of:

1. Include individual workflow workers in background_tasks with status (pending | running), a stable id, and ideally the agent() label/prompt.
2. Emit task_started for each worker at enqueue time with an initial pending status (then task_updated → running), so clients can render queued rows that transition to running.
3. A control request / Query method to list a workflow's planned + pending workers (id, label, status).

Use Case Example

1. A custom chat UI is built on the Agent SDK; the agent uses the Workflow tool to run 10 subagents in parallel.
2. On a 2-vCPU host, 2 run and 8 queue.
3. The assistant says "I've spawned 10 subagents," but the UI can only render the 2 started ones — it looks like only 2 exist.
4. With any of the above, the UI could show all 10 (2 running + 8 queued), matching what the in-process /workflows view already shows.

Related

• #27916 — "Display active subagent count in the CLI status line" (same visibility need, TUI side).