Choosing the surface: editor, CLI, multi-agent, Cloud Agent

Cursor is unusual among coding agents in that it is genuinely both a GUI editor and a CLI, with parallel agents layered on top. The reflex is matching the shape of the task to the shape of the surface - and there are four places a task can run (surface names and controls as of September 2026, each linked below):

• The editor (Agent sidebar) - for interactive work where you want to watch the diff form and stay in the loop. This is the default surface, where most work on a project happens. Reach for it when you’ll be reviewing closely and iterating.
• The CLI - for batch and scripted work. The command is agent; cursor-agent is its legacy alias, “a backward-compatible alias” in the CLI changelog’s words (CLI changelog; CLI overview). Install it with curl https://cursor.com/install -fsS | bash (installation docs). When the job is “run this prompt over a list” or “wire a check into the pipeline,” it belongs here, not in a chat window you have to babysit.
• Multi-agent worktrees - for parallel, competing attempts. Fan one prompt across several agents, each in an isolated git worktree, then merge the winner; and the same surface covers the scoped, noisy job you’d rather keep out of your main conversation - delegate that to a subagent, a nested agent with its own context window, with no worktree fan-out needed. Reach for parallelism when an approach is genuinely uncertain and you’d rather see three real attempts than argue one out in your head. (Parallel & remote agents)
• Cloud Agents - for async, unwatched work. Full agents that run in isolated VMs in Cursor’s cloud (or on self-hosted machines you register), clone the repo to a fresh branch, and come back as a PR you review. They’re reachable from the editor, the web, your phone, Slack, GitHub, Bitbucket, Linear, and the API, with @cursor as the mention syntax on the chat hosts, and from Microsoft Teams too (that channel is documented on the Teams integrations page, not the main cloud-agent page; Cloud Agents documentation for the others). Reach for one when the task is well-specified, you don’t need to watch, and you’d rather come back to a branch than sit through the run.

The parallel-agent surfaces in particular have been renamed and reshaped across releases - the fan-out that shipped in Cursor 2.0 as a sidebar of agents now lives in the Agents Window, Cursor’s agent-first workspace (multi-agent overview) - so verify the current controls before treating any historical walkthrough as current.

The pattern underneath: interactive → editor, batch → CLI, parallel/uncertain → multi-agent, async/unwatched → Cloud Agent. Once that mapping is reflex, you stop defaulting everything into the sidebar and start putting work where it runs best.

Posture (how far the agent may go before you look), engine (which model does the reasoning), and surface (where the task runs) are decisions you make fresh on every task. Some of what you’d otherwise re-decide can be parked in the repo instead, where the agent picks it up without being asked. Next: what you write down once.