Tom Hundley
We published this in December 2025, when Cursor's multi-agent was a race between identical prompts. Cursor has since shipped real orchestration. Here's what changed, what didn't, and which one you actually want.
If you tried Cursor's multi-agent feature and found yourself staring at five competing implementations wondering how to merge them, you discovered something real: that feature was never collaborative orchestration. It was competitive selection.
That distinction still matters, because Cursor now offers both, and they solve completely different problems. Choosing the wrong one is how you end up in merge-conflict hell.
| Best-of-N | Orchestration | |
|---|---|---|
| What runs | The same prompt, N times | Different subtasks, N agents |
| Agents can see each other | No | Yes, through shared context |
| Your job at the end | Pick the winner | Review the merged result |
| Good for | Uncertain approach, one hard problem | Large work that decomposes cleanly |
| Failure mode | Trying to merge all N | Bad task decomposition |
Both are now available in Cursor. The original version of this article said orchestration was something you had to leave Cursor for. That is no longer true, and the correction is the most important update on this page.
When you set Agent Count to 3x or 5x, Cursor runs the same prompt in parallel across isolated environments. Each agent operates in its own git worktree, a separate working directory attached to your repository. They can't see each other. They don't collaborate. They race.
Your job is to pick the winner.
According to Cursor's own writeup, having multiple models attempt the same problem and picking the best result significantly improves the final output, especially on harder tasks.
This is powerful, but it isn't orchestration. It's an audition.
The nightmare scenario: you run five agents on "refactor the authentication module." Each one works. Each one is different. You accept all five. Now what?
You've just created five parallel universes of your codebase. They share the same repository object database, because git worktrees are efficient that way, but they hold incompatible changes. Merging them is like combining five different answers to an essay question into one coherent response.
The rule: if you ran N agents on the same problem and they all touched the same core files, pick one implementation to apply. Cherry-pick small independent pieces from the others if you like, things like tests, docs, or utilities. Don't try to combine N full implementations.
Three changes turned Cursor into an orchestration tool. All three are recent enough that most teams' mental model hasn't caught up.
Subagents on their own machines (August 19, 2026). Subagents can now run on their own virtual machines, each with an isolated copy of the project and clean context in its own cloud environment. That makes genuinely independent parallel work possible. The example Cursor gives is running a swarm of subagents to test an app for bugs, each in its own environment. The same release added Custom Modes, which keep an agent focused on a single skill, and a /goal command for long-lived objectives that survive across sessions.
Agents inside code review (August 17, 2026). With Origin code hosting, agents are part of the pull request workflow rather than something that happens before it.
Coordinators (September 10, 2026). This is the big one. Coordinators create and manage agents on your behalf, running as many in parallel as the work needs, delegating to subagents and maintaining shared context that accumulates knowledge over time.
That last sentence is the definition of orchestration, and it's the thing this article originally said you had to go elsewhere for.
This section is the reason many of you found this page, and the underlying model has not changed.
These appear in the diff editor when reviewing changes, and they work within the current workspace:
If you're reviewing an agent's worktree, accepting a change keeps it in that agent's isolated workspace. It does not merge anything into your main branch.
Alternative wording for the same two actions. Keep equals Accept, Undo equals Reject.
The confusion comes from deletions. "Keep" a deletion sounds backwards, because you're keeping the act of deleting, not the deleted code. Community feedback has been consistently vocal about this friction.
This is the critical action. Apply takes changes from an agent's worktree and merges them into your main working tree. It is the "merge to main" step. Everything else is workspace-local review.
Do I know how I want this solved?
├─ No, and it's one hard problem ......... Best-of-N, then judge
└─ Yes, and it splits into real subtasks .. Coordinator + subagents
Does the work split cleanly?
├─ Independent files or services ......... Orchestration
└─ All agents touch the same core files ... Best-of-N (orchestration will collide)The trap is using orchestration on work that doesn't decompose. If three subagents all need to edit the same module, isolation doesn't help you; it just moves the conflict to the end.
Worth keeping even now that orchestration exists, because it's cheap and it works:
One agent builds, others review. You get multiple perspectives without the merge nightmare, and you don't need a coordinator to set it up.
The comparison that made this article useful has narrowed considerably. Claude Code has had orchestrated delegation for a while: a lead agent breaks work down, subagents work in parallel with their own context windows, and results get consolidated. Cursor has now built its own version of the same idea.
| Aspect | Cursor, 2025 | Cursor, now | Claude Code |
|---|---|---|---|
| Parallel model | Best-of-N only | Best-of-N and coordinated subagents | Orchestrated delegation |
| Subagent isolation | Git worktrees | Worktrees, or a dedicated VM each | Separate context windows |
| Synthesis | Manual, pick a winner | Coordinator merges | Lead agent consolidates |
| Shared memory across agents | None | Accumulating shared context | Session context and memory |
Neither tool is wrong. The honest 2026 answer is that the gap is now about where you want to work rather than what the tool can do. If you live in an editor, Cursor's orchestration is real. If you live in a terminal or want to script the whole thing, see our complete guide to Claude Code's surfaces.
This article is part of our Vibe Coding series. Have questions? Get in touch.
This article is a live example of the AI-enabled content workflow we build for clients.
This is a refresh. The original published in December 2025 and made a prediction in its closing section: that Cursor was heading toward true orchestration. That turned out to be right, which meant the rest of the article had gone wrong. Rather than publish a new URL and split the audience, we rewrote in place.
| Stage | Who | What |
|---|---|---|
| Audit | Tom Hundley | Flagged the page from search data as a top performer whose central claim had been overtaken by the product |
| Research | Claude Opus 5 | Read Cursor's official changelog for what actually shipped, rather than trusting secondary coverage |
| Drafting | Claude Opus 5 | Rewrote against the changelog, preserving the parts that are still correct |
| Fact-Check | Human + AI | Feature names and dates taken from the vendor changelog; version numbers that only appeared in third-party blogs were deliberately left out |
| Editorial | Tom Hundley | Final review for accuracy, tone, and value |
What the refresh corrected: the central best-of-N claim, which the August and September 2026 releases overtook; the comparison table; and quoting that an import bug had stripped from the original text.
We're an AI enablement company. It would be strange if we didn't use AI to create content. But more importantly, we believe the future of professional content isn't AI versus human. It's AI amplifying human expertise.
Every article we publish demonstrates the same workflow we help clients implement: AI handles the heavy lifting of research and drafting, humans provide direction, judgment, and accountability. Including the part nobody enjoys, which is going back and correcting yourself in public.
Want to build this capability for your team? Let's talk about AI enablement →
Discover more content: