Cursor 3.2 : Parallel AI Agents Finally Make Agentic Coding Real

Cursor 3.2 : Parallel AI Agents Finally Make Agentic Coding Real
Cursor shipped 3.2, and I think this is the first time agentic coding actually feels like agentic coding.
For the longest time, working with AI agents in an IDE felt like standing in line at a coffee shop. You'd type a request, watch it work, wait, type the next one, watch it work, wait. The agent was smart, but the workflow was dumb. One thing at a time. Always.
Cursor 3.2 breaks that.
Three features dropped in the Agents window, and they all point at the same idea. Stop queuing. Start parallelizing.
/multitask
This is the headline feature. You type /multitask or hit the button, and Cursor spawns async subagents called workers. Each one picks up a request and runs in the background while you keep working.
The part that surprised me is that it works on already queued messages. So if you've stacked up four prompts thinking they'll run one after another, you can flip them into parallel mid-flight. Live counters show what's working, what's queued, and what's still being sent. You can ask "what's the status" and get a real progress report.
It's the difference between a to-do list and a team.
Worktrees in the Agents Window
Worktrees aren't new in Git. But having them properly integrated into an agent workflow is.
You can spin up isolated branches and let agents work on them in the background. Your main workspace stays clean. When you're ready to look at what an agent did, one click pulls that branch into your local foreground. Review, test, commit, PR, all from inside Cursor.
This solves the thing I was most worried about with parallel agents. Branch isolation means two workers can't step on each other's toes by accident.
Multi-Root Workspaces
This one is quietly the biggest deal for anyone working on real projects.
A single agent session can now operate on a workspace containing multiple folders or repos. Frontend and backend together. Monorepo across services. One prompt, coordinated changes across all of it.
The demo showed an agent adding a "Paused" project status across a frontend and backend repo. TypeScript updates on one side, API changes on the other, tests, README updates, all consistent, all in one go. With a clean summary at the end of what changed and what was deliberately left alone.
That last part matters. A good agent should know what not to touch.
What I'm Still Thinking About
Parallel agents are powerful, but they introduce real questions.
What happens when two workers edit the same file? How does the system reason about task dependencies? Does it know when task B should wait for task A? What's the merge story when worktrees diverge?
Cursor hasn't fully answered all of this in public yet. Some of it probably gets solved in practice. Some of it probably bites people. That's fine. This is the messy part of any new paradigm.
The Bigger Picture
We keep talking about agents like they're going to replace developers. That framing misses what's actually happening.
What's happening is that the unit of work is changing. It used to be a function. Then a feature. Now it's a parallelized batch of intent, dispatched, executed, reviewed.
The developer doesn't disappear. The developer becomes an orchestrator.
Cursor 3.2 is the cleanest expression of that shift I've seen so far. Running on Opus 4.7 with a million tokens of context, on a clean UI, with proper isolation and proper review steps.
Sequential was the bottleneck. Now it's not.
And that changes how much one person can ship in a day.
Explore More Articles
Discover other insightful articles and stories from our blog.