I’m trying to understand what is currently possible in Cursor regarding long-running multi-agent workflows.
Here’s the scenario:
I wrote a markdown document containing 18 tasks.
The document starts with an introduction explaining the motivation, purpose, and expected outcome.
After that, the document contains 18 independent tasks. Each task has:
a definition
implementation details / explanation
acceptance criteria
The important part is that all 18 tasks are completely independent from each other, so they could theoretically be implemented in parallel.
My idea is something like:
a root/main agent responsible for orchestration
multiple sub-agents, where each sub-agent is responsible for implementing one task
each task/sub-agent generating its own Pull Request (working on a isolate worktree & branch)
=>> Is this kind of automation/orchestration currently possible in Cursor editor? <<=
Additional questions:
Is it possible to specify which LLM/model should be used for each individual task/sub-agent?
My initial idea is to use GPT 5.3 Codex for most tasks, since the tasks are mostly low-to-medium complexity and the cost/performance ratio seems very good. But I’m also considering using Composer 2 for the lower-complexity tasks. Can the root agent dynamically decide which model to use for each sub-agent/task? For example, could the recommended model be declared directly inside each task definition in the markdown document?
Is it possible to keep everything running Cursor editor, while still monitoring execution/progress through Cursor Cloud?
I’d also appreciate hearing from people already using Cursor for long-running agentic workflows or multi-agent orchestration setups.
unfortunately Cursor is unable to start a orchestrator to manage multiple instances of subagents (defined in `.cursor/agents` in parallel.
all subagents stuck or running in looping. none finished.
i needed to start new chat for every task manually, instead of the orchestrator agent spawn and managed their lifecycle.
Hey, here’s a breakdown of what works right now and what doesn’t for your setup.
Subagents vs Cloud Agents are different tools
.cursor/agents subagents are meant for delegation inside a single agent session. The parent hits a complex substep, spawns a subagent with a clean context, and the subagent returns results back to the parent. It’s not an orchestrator for N independent long running workers, each with their own PR.
For your case, 18 independent tasks, each in an isolated worktree plus branch plus its own PR, Cloud Agents are a better architectural fit. You can run parallel cloud runs, each one works in its own environment and opens a PR. You can monitor them at cursor.com/agents.
Cloud Agents API | Cursor Docs if you want to start runs programmatically, like parse a markdown list of 18 tasks and launch 18 runs
On your questions:
Per task model: for a subagent you can set the model in the YAML frontmatter in .cursor/agents/.md. For a cloud agent run, you choose the model when you start the run.
Root agent picks the model dynamically: there’s no built in router agent that auto selects a per task model. The practical approach is to declare the model in the task description or encode it in the subagent name or config, then start runs with a script.
Monitoring from the IDE with Cloud: yep, cloud runs show up in the IDE and on cursor.com/agents.
About subagents getting stuck in your attempt
Parallel subagents hanging or looping is a known issue, especially when you start a lot at once. There are a few open issues and there’s no clear ETA yet. If you can share the bcId for a stuck run from the Cloud Agent URL, I can attach it to an existing report.
Related feature request about subagents in Cloud Agents and supporting .cursor/agents files in Cloud:
