On April 2, 2026, Cursor shipped version 3 — codenamed "Glass" — and quietly demoted its own text editor. The default surface is now the Agents Window: a sidebar listing every active agent session, local or cloud, across every repo you have open, all running at once. The file you were editing is still there, one panel over. It is just no longer where the work happens. That reversal is the whole story. The thing you stare at all day stopped being code and became a queue of agents.
I've spent the last few weeks running four to eight of these at a time, and the honest lesson is that the hard part is not the models. It's me. Generation stopped being the bottleneck the moment a single prompt could produce a working diff. The constraint moved to how fast you can scope, isolate, review, and integrate what several agents hand back. That's an orchestration problem, and most of us have zero training in it.
What "parallel" actually buys you
Cursor lets you run up to eight agents against one codebase simultaneously, and it does the one thing that makes that safe by default: each agent gets its own isolated git worktree. An agent restructuring your logging and another rewriting a serializer never trip over the same working directory, because they don't share one. Each lands on its own branch.
Some of those agents run locally on the Composer model with direct filesystem and language-server access — fast round trips, good for short work you want to watch. Others run in the cloud, persisting on Cursor's infrastructure after you close the laptop, generating screenshots and demo recordings, better suited to long refactors and multi-repo jobs. From the Agents Window you dispatch both kinds and review their collective output from one place.
The pitch is that you become a multiplier: three or four independent tasks in flight while you think about the fifth. And for genuinely independent work, it delivers. The trouble starts the moment the work is not as independent as it looked.
Isolation is not coordination
Worktrees stop filesystem conflicts. They do nothing about semantic ones. Two agents on separate branches can both edit the same function, each perfectly self-consistent, and neither notices the other exists. The Agents Window does not merge their output and does not stop them from colliding in the abstract — it only stops them from corrupting each other's working tree on disk. That distinction is the single most important thing to internalize before you scale past two agents.
So the isolation Cursor gives you is real but shallow. It buys you safe parallel execution. It does not buy you safe integration. Integration is still your job, and it is where the parallelism you gained gets spent back.
The three limits nobody puts on the marketing page
Review capacity. You can dispatch eight agents in under a minute. You cannot review eight diffs in under a minute. Diffs queue up faster than a human clears them, and an unreviewed agent diff is not progress — it's inventory. The real cap on how many agents help you is how many results you can actually read and reason about per hour.
Merge order. While your agents run, main keeps moving. Every long job drifts further behind the branch it forked from. If you merge all of them at the end in a batch, a failure gives you no idea which change caused it. Merge one, run the suite, rebase the rest, repeat. Test between merges, not once at the finish.
Cost. Running things in parallel trades money for wall-clock time — roughly three agents burn three times the tokens of doing the work sequentially. Cursor shows no per-session cost in the window, so a wall of green checkmarks hides how much the run actually cost. Track it yourself or it will surprise you at the end of the month.
A discipline that holds up
The mental model that made this workable for me is deliberately unglamorous:
Treat each agent like a pull-request reviewer who will only ever read the files you hand it. If it isn't in the prompt, it doesn't exist to that agent.
That framing forces the two habits that matter. First, scope in tightly: name the files, the function, the contract, the definition of done. Second, scope out explicitly — list what the agent must not touch. Shared modules are where semantic collisions breed, so the fastest way to avoid a merge nightmare is to keep two agents out of the same file in the first place, not to untangle them afterward.
Then treat integration as its own step, with worktrees per task and a merge loop that refuses to move forward on red:
# one worktree per agent-task, each on its own branch
git worktree add ../wt-logging feat/structured-logging
git worktree add ../wt-serializer feat/rewrite-serializer
git worktree add ../wt-flags feat/remove-dead-flags
# integrate one at a time, testing between every merge
for wt in logging serializer flags; do
git merge --no-ff "feat/${wt}" || { echo "conflict in ${wt} — stop and resolve"; break; }
npm test || { echo "tests red after ${wt} — reverting"; git reset --hard HEAD~1; break; }
done
Nothing here is exotic. That's the point. The leverage in a parallel setup does not come from a cleverer prompt; it comes from a boring, repeatable integration ritual that catches a bad diff at merge N instead of merge N-plus-three.
The takeaway
Cursor's product bet — the editor as a background detail, the agent queue as the main event — is probably correct about where the work is going. But it exposes a skill nobody hired us for. The tool went from something you type into to something you dispatch and account for, and dispatching is the easy half.
So here is the rule I'd give anyone spinning up more than two agents: never run more agents than you can review in the time it takes them to finish. Eight agents you can't keep up with is slower than three you can, because unread diffs pile up, branches rot behind main, and you pay full token price for output you'll eventually throw away. The orchestrator's job isn't maximizing how many agents are running. It's maximizing how many land.
Sources: Cursor Blog, Cursor Changelog