Native Dynamic Workflows for subagent orchestration (Claude Code parity)

Ideas Feature Requests
,
1

Describe the request

Native Dynamic Workflows for subagent orchestration (Claude Code parity)

Feature request for product/service

Cursor IDE — Agent / Subagents

Describe the request

Add native Dynamic Workflows to Cursor — the same class of feature Claude Code shipped as Dynamic Workflows: the agent writes a reusable orchestration script that fans out many subagents in a separate runtime, while the main session stays responsive and only receives the final result.

Problem

Cursor today has strong building blocks — Subagents, /multitask, Cloud Agents, and Automations — but no first-class way to:

  1. Codify orchestration as a durable artifact (not ephemeral chat coordination)
  2. Run dozens/hundreds of parallel subagents from an explicit script with loops, branching, barriers, and verification gates
  3. Save and rerun a workflow across repos/sessions (/workflows-style progress view + slash command)
  4. Keep intermediate results out of the parent context — only the final synthesized answer returns to chat

When a session ends, the orchestration recipe disappears. Skills/Rules describe what to do; Subagents delegate one step at a time via LLM tool calls; Automations trigger single cloud runs on external events. None replace a scriptable workflow runtime.

Proposed solution

Introduce a Dynamic Workflows runtime in Cursor Agent sessions:

  • User asks for a workflow (or enables an auto-workflow mode for large tasks)
  • Cursor generates an orchestration script for the task
  • A background runtime executes it: spawn subagents, collect structured outputs, verify/converge, advance phases
  • Parent chat stays usable; user can open a /workflows progress view (watch / pause / resume / save)
  • Completed runs can be saved to .cursor/workflows/ (repo) or ~/.cursor/workflows/ (personal) and rerun as slash commands

Suggested primitives (Claude Code parity is a good reference):

  • phase("name") — segmented progress UI
  • agent(prompt, { label, schema, phase }) — spawn subagent with optional JSON Schema output
  • pipeline(items, ...stages) — staged processing with fan-out
  • parallel([fn, ...]) — concurrent barrier

Example use cases

  • Codebase-wide bug sweep / security audit
  • Large migrations (hundreds of files, per-file isolated agents)
  • Cross-checked research (multiple angles + adversarial verification)
  • Multi-phase plan → implement → test → review with explicit convergence criteria

How this differs from existing Cursor features

Feature What it does Gap
Subagents / /multitask LLM delegates tasks in-session Ephemeral; no saved script/runtime
Automations Triggered Cloud Agent runs Event/schedule automation, not in-session orchestration
Skills / Commands Reusable prompt playbooks Instructions, not executable orchestration
SDK / CLI Build your own orchestrator Possible, but not native IDE UX

Suggested safeguards

  • Confirm before first run on a session (cost/usage transparency)
  • Respect hooks (subagentStart, subagentStop, tool allowlists)
  • Org/admin setting to disable workflows
  • Cap parallelism / token budget controls

Prior art

Related Cursor forum threads (adjacent, not duplicates)

Tags: subagents, multitask, cloud-agents, skills

6

There’s no native saveable orchestration runtime today; the closest path right now is scripting the Cursor CLI / headless agent from your own runner to get the fan-out + rerunnable-recipe behavior.

We’ll be tracking this thread to gauge interest so our product team can prioritize - others who want it, chime in here.