Skip to content
agents.cli

Parallel & remote agents

The last chapter was about a single agent working a single thread. This one is about more than one at once - and the three different shapes that takes in Cursor, because they are not the same primitive wearing three hats. The move that anchors the chapter is the loudest of them: Cursor 2.0’s multi-agent sidebar, where one prompt fans out to a fleet of parallel agents, each in its own isolated copy of your repo, and you pick the winner.

Hold onto the core idea, because it carries the whole chapter. 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. The cost is more compute and a review step at the end; the payoff is that you stop betting the whole task on a single agent’s first instinct. That trade is the spine of this chapter, and everything below is learning the three machines Cursor gives you to make it - and which machine fits which job.

The job in front of you

Section titled “The job in front of you”

You’ve inherited budgetcli - a small self-hosted budgeting API plus a thin web client - and you don’t fully trust it yet. Two things now need doing, and neither is a clean fit for a single agent grinding through one thread:

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 materialised 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 - but for different reasons, and that difference is the whole chapter. The first wants competing agents you compare. The second wants cooperating agents you keep walled apart. Cursor’s multi-agent sidebar does both, and it does them with the same isolation mechanism, so we start there.

The four moves of this chapter

Section titled “The four moves of this chapter”

The arc runs outward and then back to judgment. The first lesson is the loudest instrument and the one that carries both jobs above: a fleet of agents kept apart by worktrees, handing you a slate to compare instead of one answer to trust. The second shrinks the radius to a single defined worker and isolates context rather than files - the move that keeps a hundred-file scan out of your main thread. The third pushes the radius past your laptop altogether. The fourth lays all three side by side, because the skill this chapter is really teaching isn’t running agents in parallel; it’s knowing which of the three a job wanted before you spent the compute finding out. The person who’s merely installed Cursor runs everything in one thread and waits on it. By the end of this chapter you’ll be the other kind of user - the one who asks how isolated a piece of work needs to be, and picks the radius on purpose.