Cursor Agents: Agent Mode, Plan Mode and Background Agents

Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition. lets Cursor act on your codebase: it reads relevant files, proposes and applies multi-file edits, runs terminal commands (tests, installs) and iterates until the task is done, pausing for you to approve changes. It is the core of how serious work gets done in Cursor.

I would keep approvals on for longer than feels necessary, and not because the model cannot be trusted. Approvals are what keep the diff small enough that you actually read it. Turn them all off on day one and the first thing you review is an hour of work.

Everything else on this page is a variation on that loop, which is worth holding onto as the surfaces multiply. Plan Mode moves the reading earlier, onto a plan instead of a diff. Cloud runs move it later, onto a branch you read after the fact. Agent Review runs a second pass over the same diff, and /automate schedules the whole thing and hands you a pull request.

For anything non-trivial, ask the agent to produce a plan before it edits. Plan Mode turns a vague task into an explicit, reviewable list of steps and files, so you catch a wrong approach in seconds instead of unwinding a bad multi-file change.

Plan Mode helps because the agent farms context aggressively up front. One security engineer who started skeptical became a complete convert: he now defaults to Plan for anything net-new or non-trivial, because in plan the agent finds all the relevant injection points ahead of time. That does two things: it forms context more comprehensively than it would by default, and it keeps the agent on track during execution. For genuinely quick changes he skips it.

Run Plan with a high-reasoning model (GPT-5.x or Opus 4.x); a verbose, even voice-dictated prompt is fine because Plan Mode's job is to interpret the messy explanation into a clear, distinct plan and ask clarifying questions to fill the gaps. The plan it returns shows what the model learned, the proposed design, files to add and a to-do list. Read the to-dos and prune the extras. One presenter removed "build and verify" and "dual check" steps because verification was manual, telling it to just code up the bot. You can edit the plan conversationally in the same chat, and you can preempt it to add downstream needs. Switch to a faster execution model once the plan is right.

Planning everything is its own mistake, though. Cursor puts Plan Mode on work where the approach is not obvious, and the Plan Mode page says as much: a change you have made a dozen times can go straight to Agent. A plan for a one-line copy fix costs a round trip, a read and a decision you did not need to make. If you could hand the change to another engineer in one sentence and expect it back correct, skip the plan.

Current Cursor can run longer work in cloud environments, launch /in-cloud subagents in their own VM and branch and use /babysit to keep iterating on a PR remotely. Treat each cloud run as a self-contained task with clear acceptance criteria so the diff is easy to verify.

• Give each background task a single, well-scoped goal and a way to verify it (a test, a command).
• Don't run parallel agents on overlapping files: you'll get conflicting edits.
• Review each result independently before merging.

The rule everyone quotes from that list is the middle one, keep parallel agents off overlapping files. It is the right instinct and slightly the wrong rule, because file overlap is the easy case and rarely the thing that bites. Two agents can work in entirely separate files and still both reshape the callers of a shared function, or both write a migration. The check that holds up is whether each diff would make sense to a reviewer on its own. If reading one needs the other in your head, run them in sequence.

Wasted tokens are the cheap part of a background run going wrong. What costs you is finding out late, on a branch, with a diff big enough that reading it properly competes with having just done the task yourself. That is the argument for acceptance criteria. A run that can fail its own check tells you near the start instead of at the end.

On a team of three, keeping parallel agents out of each other's way is something you can hold in your head, because you know what everyone is working on. On thirty it is not, and the coordination has to live somewhere. Worktrees give each run an isolated checkout, which is the version of this that needs the least agreement from anybody.

These three commands cover different points on the path from one-off prompt to standing automation. /loop repeats a prompt locally until you stop it, /automate turns a proven workflow into something that runs on a trigger, and /review runs BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. or Security Review over your changes.

Prove a workflow by hand in a local session first, then /loop it while you watch, then /automate it once the output stops surprising you. That order is the useful part of the table. Skipping to the automation is tempting, probably because the trigger list is the interesting bit, and it means the first real test of your prompt happens on a schedule, in a shared repo, in front of the team.

The 'define no-op behavior' line in that last column is the one to read twice. Triggers include a Slack emoji reaction and a review thread being marked resolved, which puts your automation inside activity other people generate all day without thinking about it. The pull-request tool is enabled by default on every automation, so a repo-backed one can open a pull request off a run you never meant to start, without you having turned anything on. Cursor's docs ask you to set a quality bar for when the agent should open a pull request, comment or do nothing, and the cost of skipping that lands on whoever reviews pull requests rather than on you.

/review is where I would start, since it runs before the push and costs almost nothing to try. Local findings are evidence, and nothing about them moves a merge button. When you want the gate rather than the evidence, that lives with BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. on the pull request, and Agent Review covers where the local pass fits around it.

Start with Agent modeCursor's full-capability mode: the AI can read the codebase, write and edit files, move them and run terminal commands. Contrast with Ask mode, which is read-only. Press Enter for the full definition. and approvals on, add Plan Mode for anything you cannot state in a sentence, then run /review before you push. Cloud runs and /automate come after that, once you have a workflow that already works while you are watching it.

Each step in that sequence is what makes the next one readable, which is a different criterion from difficulty. Plan Mode gives you something to read before a diff exists. Local review gives you a second opinion on the diff. A cloud run is only safe to leave alone because you already know what a good result for this task looks like. Run it backwards and you get the familiar version of this failure, a fleet of background agents producing work nobody has a standard for.

When a run goes sideways, the first thing worth checking is whether the agent had any way to know it was finished. A task with a test attached can fail. A task described only in prose ends when the model decides it has said enough, which is why the same prompt can come back at three different scopes on three runs.

Reliable runs come from telling the agent what you want, where to look and how to know it worked.

1. 1State the goal and the constraint ("add X without changing the public API").
2. 2Point at the exact files with @-mentions instead of making it search.
3. 3Ask for a plan on anything that spans more than a couple of files.
4. 4Tell it how to verify (run these tests / this command).
5. 5Start a fresh chat when context gets long (see context hygiene).

Step four is the one that gets skipped. It feels like extra typing at the exact moment you want to hit send, and it is the only one of the five that changes what happens when the agent is wrong, because a run with a check can fail and a run without one can only stop.

@-mentioning everything is the part I would soften. Pointing at the two files that matter beats a blind search. Pointing at eleven fills the context with code the model has to read past, and from the outside that looks identical to a bad prompt. If you are not sure which files matter, that is a Plan Mode task rather than a longer @ list.