Cursor 3.2: Async Agents and Worktrees

The situation

Cursor 3.2 adds three changes that matter for teams already using agents in real work: async multitasking in the Agents Window, a better worktrees flow, and multi-root workspaces for cross-repo sessions. Together, they cut down on queueing, retargeting, and manual stitching across repos.

The release fits teams that already use subagents, skills, custom agents, or an Agents.md-style operating model. If your workflow depends on small tasks with clear handoffs, Cursor is moving closer to that shape. If your workflow is still one chat, one branch, one repo, this is a good time to tighten the surrounding habits.

The official changelog points to parallelism and workspace reuse. That is the useful lens here: split work into smaller chunks so agents can move without blocking each other.

For background on the broader pattern, see Cursor subagents and skills.

Walkthrough

1. Start with /multitask when the queue is the bottleneck. Cursor says it will run async subagents in parallel instead of adding requests to the queue, and it can break larger tasks into smaller chunks for multiple subagents to handle at once. This is most useful when the work is already decomposable: one subagent can inspect tests, another can update a shared helper, and another can draft the follow-up change.

2. Use it on queued work, not just new work. The changelog notes that if messages are already waiting, you can ask Cursor to multitask on them instead of waiting for the current run to finish. For teams that batch requests during review or after planning, the habit is simple: keep requests decomposable so the agent can fan them out without turning the queue into one long dependency chain.

3. Move isolated branches through worktrees. Cursor’s improved worktrees in the Agents Window are meant for background tasks on different branches, with a one-click path to bring a branch into the local foreground when it is ready to test. That fits agent-generated changes that should stay out of your main checkout until they are ready.

4. Use multi-root workspaces for cross-repo edits. Cursor now lets a single agent session target a reusable workspace made of multiple folders. Frontend, backend, and shared libraries can stay in one agent session without retargeting every time the task crosses repo boundaries. For platform teams, this reduces the context reset tax on cross-cutting changes.

5. Put the workflow in writing. If your team uses skills or custom agents, keep the instructions short and reusable. A minimal skill or agent spec should say what the agent may touch, how it should split work, and what it must verify before handing back changes.

---
name: cross-repo-change
summary: Coordinate a small cross-repo change with explicit checks.
---

# Instructions
- Split frontend, backend, and shared-library edits into separate subtasks when possible.
- Use the shared workspace only for the folders needed for this change.
- Verify each branch or worktree before merging back.
- Stop and ask if the change needs a new repo or a new owner.

6. Add a rule stub for the handoff. Cursor’s rules system is the right place for team norms that should apply every time an agent enters a workspace. Keep it narrow: one rule for branch hygiene, one for verification, one for escalation.

# Agent workspace rules
- Prefer one task per worktree when the change is isolated.
- Use multi-root workspaces only for repos that are part of the same release surface.
- Do not merge cross-repo edits until each repo passes its own checks.
- If a task touches ownership boundaries, pause and request review.

A small methodology note: this is a good place to Document the split between what the agent can do and what a human must review. The release makes that boundary more important.

Tradeoffs and limits

Parallel subagents are not free speed. They work best when the task can be decomposed cleanly; they are less useful when the change depends on one shared stateful decision. If the request is ambiguous, more parallelism can produce more partial answers, not better ones.

Worktrees also add operational overhead. They help isolate changes, but they can hide drift if teams do not regularly test the branch they plan to promote. The one-click foreground move is convenient, but it should not replace a deliberate verification step.

Multi-root workspaces solve a real coordination problem, but they can also blur repo boundaries if teams are not careful. A reusable workspace should reflect a real release surface, not just a convenient bundle of folders. If ownership, deployment cadence, or permissions differ across repos, keep the workspace narrow and explicit.

None of these features remove the need for good agent instructions. Cursor can parallelize and retarget more effectively, but it still benefits from clear task boundaries, scoped rules, and a review habit that catches cross-repo side effects before merge.

Further reading

• Cursor Docs
• Cursor Rules
• Cursor changelog
• Cursor subagents and skills
• cursor.directory
• dotcursorrules.com
• Anthropic skills repository
• OpenAI skills repository