The three-flavour taxonomy

Put the three flavours side by side, because the whole point of the chapter is knowing which one a given job wants. They are not interchangeable - they trade along different axes:

	Local fan-out (sidebar)	Subagents	Cloud Agents
Where it runs	Your machine, parallel worktrees	Your machine, isolated context	Remote cloud VM
How you reach it	Multi-agent sidebar, one prompt	Auto-delegate, /name, or NL mention	Desktop / web / Slack / GitHub / Linear / REST API
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.

By the end of this chapter the question to ask before any heavy or parallel task is 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 sidebar 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 sidebar 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 mode. 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 - the live systems, the repeatable procedures, and the rules that have to hold whatever the model decides. Those all live outside the repo, and each needs a different surface. Next: extending Cursor with MCP, skills, commands and hooks.