Workflow script API: no way to continue a previously spawned agent

The Workflow tool's script API has one agent primitive, agent(prompt, opts), which is one-shot. It returns a result and the script can never address that agent again. This forces every multi-pass workflow to re-spawn agents that then rebuild context the previous agent already had.

Measured cost

A delivery pipeline that implements a change, reviews it, then runs fix rounds against the findings. Per-agent, from the run transcripts:

| agent | turns | output | cache read |
|---|---|---|---|
| implementer | 83 | 15.4k | 4.40M |
| fix round 1 | 105 | 28.4k | 6.44M |
| fix round 2 | 39 | 5.5k | 1.34M |

The fix round costs more than the implementation it is fixing, on a one-line change, because it re-reads the diff, the findings and the surrounding code and re-runs the suites before it can start.

A second run of the same pipeline repeats the shape: implementer 103 turns / 7.6M cache read, then three fix rounds at 101 / 8.4M, 101 / 7.1M and 45 / 1.8M. That run moved roughly 46M cache-read tokens against 257k of output, so the spend is context reconstruction, not reasoning.

The runtime already supports what is needed

A main session spawns agents with Agent and continues them with SendMessage, context intact, until stopped. The gap is only in the script surface.

Probing from inside a workflow subagent: its tools are Bash, Edit, ListAgents, Read, ReportFindings, Skill, ToolSearch, StructuredOutput; ToolSearch select:Agent,Task returns no match; SendMessage is reachable through ToolSearch, but ListAgents from a subagent lists sessions, never sibling workflow agents, so a concurrent sibling is invisible and unaddressable. Parking an agent on a no-op and messaging it from another agent is therefore not a workaround.

Request

A way for a script to continue an agent it spawned. Either agent() returns a handle that can be called again, or opts.name makes it addressable and a continue(name, prompt) hook exists.

The hard part, acknowledged

Resume is keyed on (prompt, opts) per agent() call, and a continued agent has no single prompt, so caching a multi-turn agent is a real design question rather than an oversight. A partial answer would still help: even a continuation that is explicitly non-resumable, and forces a re-run of that agent on resume, would be worth it at these numbers.