Parallel & remote agents

One agent working one thread is Cursor’s default shape: you brief it, it reads, edits, and runs, and you review the diff. Some work does not fit that shape. A decision with several defensible answers is better settled by comparing real implementations than by arguing about them in the abstract. A mechanical change with independent slices is finished sooner when the slices move at once. And some work should not occupy your laptop or your attention at all. Cursor has three distinct flavors of more-than-one-agent work, and they are not the same mechanism wearing three hats - knowing which one a job wants is what this chapter teaches.

Widening from one agent to several also has a precondition. The controls that make one agent safe - a sandbox under it, approvals in front of the risky moves, a review gate on what comes back, as the permissions chapter covers in full - are what make it sane to multiply the agent count. Parallel agents multiply the confident-but-wrong diffs that can come back; bounded damage and deliberate review are what you multiply instead of risk. The trade that justifies the whole move is simple: when a task has more than one reasonable approach or more than one independent slice, running it once gives you one answer and no way to know if it was the best one. Running it several ways at once, in isolation, gives you a slate to compare - at the cost of more compute and a review step at the end.

The two jobs this chapter runs on

Both jobs come from the course’s illustrative budgetcli scenario - a small self-hosted personal-finance API that tracks accounts, imports bank statements from CSV files, and flags overspend:

Pick the right caching layer for the reports endpoint - there are three defensible approaches and you can’t tell which wins from reading alone. And separately, migrate every money field across the codebase from floats to integer cents without the workers reading each other’s half-written files.

The first is a decision under uncertainty: in-process LRU, Redis, or a materialized view - each has a different shape, and the honest answer is you won’t know which is cleanest until you see all three implemented against your actual code. The second is genuinely parallel but write-heavy: the same mechanical change applied across many files at once, where the danger isn’t the change itself but several agents editing one working tree and tripping over each other mid-edit. Both jobs want parallelism, for different reasons - the first wants competing agents you compare, the second cooperating agents you keep walled apart - and that difference runs through everything below.

Where this chapter goes

• Local fan-out - one prompt across a small fleet, each agent in its own git worktree, either competing on the same brief or dividing slices of one job - Flavor one - local fan-out across parallel worktrees
• Subagents - a worker you define ahead of time with its own context window, so a scoped, noisy job never lands in your main thread - Flavor two - delegated Subagents
• Cloud Agents - full agents in isolated cloud VMs, fired from your desktop, the web, your phone, Slack, GitHub, or Linear, and reviewed as a branch - Flavor three - remote Cloud Agents
• The taxonomy - the three side by side, and the single question (where should this work happen, and how isolated does it need to be?) that tells you which one a given job wanted - The three-flavor taxonomy

The arc runs outward and then back to judgment: the widest local radius first - a fleet kept apart by worktrees, handing you a slate to compare instead of one answer to trust - then a single delegated worker that isolates context rather than files, then work that leaves your machine entirely, and finally the three side by side. One naming note so version history doesn’t trip you: the parallel fan-out shipped in Cursor 2.0 as a sidebar of agents and now lives in the Agents Window, Cursor’s agent-first workspace for running agents across local and cloud environments (generally available with Cursor 3, April 2026; as of September 2026 - multi-agent overview, Agents Window reference). The surface has been renamed along the way; the three isolation mechanisms underneath have not, and they are the chapter’s real subject.