Cursor 3.2: subagents, worktrees, multi-root

The situation

Cursor’s April 24 changelog targets a common agentic coding bottleneck: one request turns into a queue of follow-ups. That works for small edits, but it slows teams when the work spans several files, branches, or repositories. Cursor 3.2 reduces that friction by moving work into parallel subagents, isolated worktrees, and multi-root workspaces.

The release matters for teams already using Cursor subagents, custom agents, or Agents.md style instructions to keep agent behavior predictable. If your workflow depends on reviewable changes, branch isolation, and repeatable task boundaries, these updates are about throughput and control.

The practical question is whether agents can do more without forcing humans to retarget the session every time the task crosses a boundary. Cursor’s answer is to make multitasking, worktrees, and multi-root workspaces first-class in the Agents Window.

Walkthrough

1. Start with the new /multitask flow when a request is broad enough to split. Cursor says it will run async subagents instead of adding the work to the queue, and it can break larger tasks into smaller chunks for multiple subagents to handle at once. Use it for tasks that are separable by file, feature slice, or verification step.

2. Use it on queued messages when waiting is the problem. The changelog says you can ask Cursor to multitask on messages already in the queue rather than waiting for the current run to finish. That helps when one agent is blocked on a long edit and another request is ready.

3. Treat worktrees as the isolation layer for background changes. Cursor’s improved worktrees in the Agents Window are meant for isolated tasks on different branches. Keep exploratory or risky edits in a worktree until they are ready to test, then move the branch into the local foreground with one click.

4. Use multi-root workspaces when the change spans repos. Cursor says a single agent session can now target a reusable workspace made of multiple folders. That matters for frontend-backend-shared-library changes, where the agent needs to move across codebases without being retargeted each time.

5. Pair these features with explicit task boundaries. The release does not remove the need for instructions; it raises the value of them. A short AGENTS.md or skill file can tell the agent what counts as done, which folders are in scope, and when to stop and ask for review.

# AGENTS.md

## Scope
- frontend/
- backend/
- shared/

## Rules
- Make one branch per isolated change.
- Do not edit generated files unless the task asks for it.
- Stop after tests pass and summarize the diff.

6. Keep rules close to the work. Cursor’s docs and rules system are the right place to encode repeatable behavior, especially when multiple subagents are working in parallel. A small rule stub is often enough to prevent drift.

---
description: Cross-repo change guardrails
---

- Prefer isolated edits in worktrees.
- If a task touches more than one root, list the roots before editing.
- Ask before changing build or deployment config.

7. Review the output as a set of branches, not a single monolith. That is the workflow shift implied by this release. When agents work in parallel, the review step becomes about reconciling several smaller diffs, not untangling one oversized patch.

A small methodology note: this is a good place to apply the Review step more deliberately. Parallel agent work is only useful if the review gate stays strict enough to catch cross-root conflicts, duplicated edits, and mismatched assumptions.

Tradeoffs and limits

Parallel subagents are not free. If the task is tightly coupled, splitting it can create more merge friction than it saves. A single refactor that changes a shared interface may be slower when broken into too many chunks.

Worktrees help only if your team already has a clean branch discipline. If branches are used casually, isolated background work can multiply stale diffs and make it harder to know which branch is safe to test.

Multi-root workspaces are powerful, but they can blur ownership. A session that can see frontend, backend, and shared code still needs clear rules about what it may change. Without that, the agent may produce technically valid edits that are awkward for review or release.

There is also a governance cost. More parallelism means more need for naming conventions, scope notes, and stop conditions. The release rewards teams that already document their agent workflows, rather than teams hoping the tool will replace them.

Further reading

• Cursor Docs
• Cursor rules documentation
• Cursor changelog
• Cursor directory
• dotcursorrules
• Anthropic skills README
• OpenAI skills README
• Related training topic