The three-flavor taxonomy

Cursor’s three flavors of more-than-one-agent, side by side. They are not interchangeable - they trade along different axes:

	Local fan-out (worktrees)	Subagents	Cloud Agents
Where it runs	Your machine, parallel worktrees	Your machine, isolated context	Remote cloud VM (Cursor-hosted or self-hosted machines)
How you reach it	Multi-agent fan-out, one prompt	Auto-delegate, /name, or a natural-language mention	Desktop, web, iOS; Slack, GitHub, Bitbucket, Linear, and @Cursor in Teams (Teams integration); the API (launch channels as of September 2026: Cloud Agents documentation, subagents documentation)
Shape	One-shot, broadcast-and-compare	Delegated, defined ahead of time	Detached, fire-and-review
Isolates	The filesystem (worktrees)	The context window	The whole machine
Best for	Competing approaches or parallel slices you’ll review together	A scoped, noisy, or repeatable job you don’t want in your main thread	Work that shouldn’t tie up your laptop and doesn’t need your eyes mid-flight

Read it as one question asked three ways - where should this work happen, and how isolated does it need to be? The local fan-out isolates files so a fleet of agents can edit at once without corrupting each other. A subagent isolates context so a noisy job doesn’t bury your main thread. A Cloud Agent isolates the whole machine so the work leaves your laptop entirely. Same instinct - push work somewhere isolated and review what comes back - at three different radii. (The channel lists above are as of September 2026; the Cloud Agents documentation owns the current set.)

So before any heavy or parallel task, ask which radius it wants: fan it out locally to compare, delegate it to a subagent to keep your thread clean, or send it to the cloud to get it off your machine. Pick the wrong radius and you’ll feel it - a Cloud Agent for a thirty-second scan is overkill, a local fan-out for a job with one obvious approach is just spending compute to feel busy.

A note on Composer-the-model

“Composer” names two different things in Cursor, and this chapter is deliberately about only one of them. The multi-agent surface and its parallel worktrees are the subject here. Composer the model - Anysphere’s own agentic coding model - is a model-roster concern, and it’s covered in the models chapter alongside the rest of the picker and Auto routing. They share a name and shipped in the same release; they are not the same feature, and the model details live there to avoid duplicating them here.

Parallelism settles how many agents work and where they run. It changes nothing about what any single one of them can reach - and note the machine boundary: a Cloud Agent reaches your repository in its cloud environment, not your laptop’s local services, while a local agent reaches exactly your machine. What all of them reach for is the live systems, the repeatable procedures, and the rules that have to hold whatever the model decides - MCP, skills, commands, and hooks in the next chapter’s terms. Those all live outside the repo, and each needs a different surface. Next: extending Cursor with MCP, skills, commands and hooks.