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, Anysphere's AI code editor, 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.

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.

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.

Common questions

• What does Cursor 3.2 change for engineering teams?

  Cursor 3.2 makes parallel agent work normal: subagents, worktrees, and multi-root workspaces arrive together. Treat it as a workflow migration rather than a feature toggle, because each surface is a fresh place for intent to disappear unless every worktree carries an owner, a path boundary, and a replay command a reviewer can run.

• When should a subagent get its own worktree?

  Give a subagent its own worktree when the work splits cleanly by ownership: test expansion, copy and docs, or a path-bounded refactor. Keep API contract changes mostly serial, and keep auth, billing, and data-loss paths out of parallel runs by default. Those need one controlling hand until the plan is stable.

• How do you review a multi-root workspace?

  Name one decision root and review from there. That root holds the rule file, the migration ledger, and the final review notes, while other roots contain evidence but never competing instructions. Without a decision root, rules differ between roots and reviewers cannot tell which guidance the agent actually followed.

• Why does parallel agent work fail in review?

  It fails when coordination cost grows faster than capacity: each worktree passes locally, the merged branch breaks, and the PR body reports results instead of scope. The corrections are mechanical. Add forbidden paths so agents stop colliding, paste the migration ledger so scope is visible, and run one merged-branch proof command before anything merges.

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.