Cursor 3.2: subagents, worktrees, multi-root

Cursor 3.2 lets you run a lot of agent work at once, and the catch is review, not speed. Cursor ships subagents, worktrees, and multi-root workspaces together in this release, and each one is a new place for the intent behind a change to go missing. A worktree is just a second working copy of your repo that an agent can edit on its own branch without touching the one in front of you. The upgrade takes a minute. Teaching your review habits to keep up is the slow part, and it is the part worth getting right.
Decide what to split and what to keep serial
Split work by ownership, not by how impatient you feel. Some work parallelizes cleanly because two people would never argue about it: test expansion, copy, docs, a refactor that stays inside one folder. Other work needs one hand on the wheel, because a single decision there rewrites the contract for every other path. Auth, billing, and anything that can lose data fall in that second group.
Here is the rule of thumb I keep in the PR description for the first few runs.
| Work type | Use subagent? | Use separate worktree? | Review requirement |
|---|---|---|---|
| Test expansion | Yes | Usually | One command proves the suite ran |
| Copy and docs | Yes | Sometimes | Owner confirms public wording |
| Localized refactor | Yes | Yes | Scope must be path-bounded |
| API contract change | Maybe | Rarely | Human plan approved first |
| Auth, billing, data loss | No by default | No by default | Senior reviewer owns the sequence |
Once the pattern settles, move it into a repo rule with Cursor Rules so you stop pasting it by hand.
Give every worktree an owner and a replay command
Worktrees multiply faster than owners. Each new checkout feels free until two of them edit the same module in different directions, and then you have a merge that neither agent can explain. The fix is boring on purpose: a plain markdown ledger that names who owns what, which paths they may touch, and the one command that proves their slice works.
# Cursor 3.2 migration ledger
- Parent goal: split checkout smoke tests from checkout copy cleanup.
- Worktree A owner: frontend engineer
- Worktree A paths: `apps/site/src/app/checkout/**`
- Worktree A proof: `pnpm test checkout-copy`
- Worktree B owner: QA engineer
- Worktree B paths: `tests/checkout/**`
- Worktree B proof: `pnpm test checkout`
- Shared forbidden paths: `apps/site/src/lib/payments/**`, `infra/**`
- Merge rule: no worktree merges until both proof commands are pasted in the PR.
Drop that block in the PR body, in AGENTS.md, or in the planning issue. It is the difference between parallel work and parallel confusion: a reviewer can audit the diff without replaying a single chat transcript.
Keep multi-root workspaces readable
Multi-root workspaces help when one change spans app code, tests, and docs at the same time. They hurt when each root carries its own rules and every root quietly believes it is in charge. A reviewer then has no way to tell which guidance the agent actually followed.
Pick one decision root and review from there. That root holds the rule file, the migration ledger, and the final review notes. The other roots carry evidence, never competing instructions. One source of authority means one place to look when something does not add up.
Catch the false green before it merges
The sneaky failure is the one where every worktree passes locally and the merged branch still breaks, because nobody tested the union. Each green is honest in isolation and wrong together. Run one proof command on the merged branch and paste the output in the PR, and that whole class of surprise goes away.
Here is the short map from symptom to correction.
| Failure | Symptom | Correction |
|---|---|---|
| Worktree drift | Two agents edit the same module differently | Add forbidden paths before the next run |
| Hidden root authority | Rules differ between roots | Name one decision root |
| Review overload | PR body summarizes results but not scope | Paste the migration ledger |
| False green | Each worktree passes locally but the merged branch fails | Add one merged-branch proof command |
The product surfaces themselves are documented under Cursor Agent and Cursor Skills, with connector behavior in Cursor MCP on top of the Model Context Protocol specification. The changelog is where defaults quietly shift, so it is worth a skim before each upgrade. The docs explain the surfaces. Your team still writes the operating contract.
Next move
Run one Cursor 3.2 migration with the ledger above, and if a reviewer cannot explain each worktree in two minutes, the split is still too vague. For the broader patterns behind owners, boundaries, and replay commands, read the subagents and skills topic hub.