Cursor Agent vs Ask vs Plan Mode: Which to Use When
Cursor’s agent has four built-in modes: Agent changes things, Ask answers, Plan proposes, and Debug investigates. Choose by how big the task is and what a wrong first attempt would cost, and know what happens to the context when you switch.
7 min read
Use Ask when you want to understand code and change nothing, Plan when the task is big or risky enough that you want to agree the approach before any file moves, and Agent when the task is clear and you are ready for edits and commands. Cursor adds a fourth built-in mode, Debug, for a bug you can reproduce but cannot explain. Two questions decide it: how many files and decisions will this touch, and what does it cost if the first attempt is wrong? A one-file fix with a test goes straight to Agent. A migration, or a change across a dozen files, goes through Plan. Anything you do not yet understand starts in Ask.
The same choice in VS Code is covered in Copilot agent vs ask vs plan. This post is about Cursor only.
The modes as Cursor documents them now
Open the agent panel with Cmd+I, or Ctrl+I on Windows and Linux, then press Shift+Tab to cycle through the modes or use the mode picker. Cursor’s help page on Agent mode (opens in a new tab) sums them up in one table:
- Agent: building features, refactoring, fixing bugs. Edits files.
- Ask: understanding code and exploring the architecture. Read-only.
- Plan: complex features where you want to review the approach first. Edits files only after you approve the plan.
- Debug: tricky bugs that need runtime evidence. Edits files.
Your project rules, user rules and team rules apply in all four, so switching mode does not switch off your conventions. The command-line agent offers Agent, Plan and Ask: /plan or --mode=plan, /ask or --mode=ask, and Shift+Tab to rotate. Design Mode, which you may have seen in the docs, is different in kind: it lives in the browser inside the Agents Window and lets you click an element on the running page and prompt against it, rather than being a chat mode you pick for a task.
Agent: do the work
Agent is the default. It searches the codebase, edits several files, runs terminal commands, reads the errors and tries again, with no limit on the number of tool calls. How often it stops to ask depends on your run mode, not on the mode picker: an allowlist, an automatic review of riskier calls, or no review at all. It takes a checkpoint before significant changes, so you can restore files if it takes a wrong turn; restoring reverts files only, not commands it ran or anything it changed outside your workspace.
While it works you can queue your next message for when it finishes, or send one that steers the current turn. Both help you stay on one task rather than starting a second one in the same chat.
Ask: understand before you change anything
Ask is read-only. The agent searches and reads your code and answers, without making edits. It is the cheapest mode to be wrong in, because nothing moves. Cursor’s Ask mode help page (opens in a new tab) suggests questions like these:
- “How does the authentication flow work?”
- “Where is the database connection configured?”
- “Explain the relationship between these two modules.”
- “What would break if this function returned null?”
Reach for Ask whenever you would otherwise let Agent loose on code you do not understand. A good answer in Ask turns a vague request into a precise task, and a precise task is what Plan and Agent need.
Plan: agree the approach first
In Plan, the agent asks clarifying questions, researches the codebase, and writes an implementation plan you can edit before anything is built. Cursor’s Plan Mode documentation (opens in a new tab) recommends it for complex features with several valid approaches, tasks that touch many files or systems, unclear requirements, and architectural decisions. For quick changes, or tasks you have done many times, it says to go straight to Agent. Cursor also suggests Plan on its own when your request reads like a large task.
The plan opens as a Markdown file. Read it as you would a colleague’s proposal: a wrong file, a missing test or an unexpected migration costs one edit now and a revert later. When it is right, press Build and the agent starts on it.
Debug: find the cause before the fix
Debug is for the bug that Agent keeps “fixing” without fixing. According to Cursor’s Debug Mode documentation (opens in a new tab), the agent explores the code and writes several hypotheses, adds log statements that report to a local debug server running in a Cursor extension, and then asks you to reproduce the bug with specific steps. It reads the logs, makes a targeted fix, often a few lines, and removes the instrumentation once you have confirmed the fix.
- Good fits: a bug you can reproduce but cannot explain, race conditions, performance problems and memory leaks, and regressions where something used to work.
- Give it the error message, the stack trace, the steps, and what should happen against what does.
- Follow its reproduction steps exactly, more than once for a timing bug. The logs are only as good as the run that produced them.
Custom modes are now built from skills
If the four are not enough, make a mode from a skill. Cursor’s guide to prompting the agent (opens in a new tab) explains the difference: pick a skill from the / menu and press Enter to attach it to one message, or press Option+Enter on a Mac, Alt+Enter on Windows, or choose Use as Mode, to keep it in context on every turn until you leave the mode. Custom modes are available in the Agents Window and the CLI, and any skill with valid frontmatter can back one.
Modes suit skills that describe how to work rather than a single job: a review checklist you keep on while you go through several files, or a test-first playbook held for a whole feature. A one-off procedure, such as a release checklist, is better called once as a skill.
Choosing by size and risk
- Small and low risk, such as a renamed variable or a missing test: Agent, directly. Planning costs more than the change.
- Small but risky, such as one line in authentication or a config value that reaches production: Ask what the line does, then Agent under a strict run mode.
- Large and low risk, such as a refactor across many files with good tests: Plan, then Build.
- Large and risky, such as a schema change or anything that deletes: Plan, save the plan, and split it into separate tasks before Agent touches any of them. Long, well-specified pieces can then go to Cursor cloud agents.
- Something is broken and you do not know why: Debug, not Agent.
- You cannot yet say what the task is: Ask.
A rule of thumb: if you could not write the acceptance check in one sentence, you are not ready for Agent. How to write a task for an AI agent has a template for that sentence.
Switching partway through
The common path through a medium task is Ask, then Plan, then Agent. One detail changes how you do it: Cursor’s help says each mode uses its own context, so switching modes starts a fresh context window. What Ask found out does not follow you automatically. Carry it deliberately: paste the conclusion into your next message, or bring the earlier conversation in with @Chats.
- Plan to Agent is handled for you: Build hands the approved plan over, so the plan file is the context.
- Agent going the wrong way: stop it, revert to an earlier checkpoint, refine the plan and run it again. Cursor’s own advice is that this is often faster than a string of corrections.
- Agent fixes the same bug twice: switch to Debug and give it the reproduction steps.
- The task changes: start a new chat. Cursor recommends it for the best results.
Plan files, and where they should end up
Plans are saved in your home directory by default. Save to workspace moves one into the project, where it can be committed, shared and read by a later chat. That is worth doing for anything larger than an afternoon: a plan in your home folder is invisible to the colleague who picks the work up, and to a cloud agent, which starts from the repository alone.
The plan also belongs with the task. On a fenbs board, every task has a note for the problem and a separate plan for how it will be done, which is the shape of a Plan-mode session. Connect Cursor over MCP and add a rule: when I approve a plan, write it into the task’s plan with fenbs_update_item; if it is size xl, propose how to split it first; when you finish in Agent, set testStatus and testNotes to what you actually ran. Decisions made along the way, such as which library won, go on the board’s Decisions page with who decided and why. Cursor rules examples has rule files you can put that line in.
Related
Connecting the board: Connect Cursor. The rule types behind those lines: Cursor rules for AI projects. The same idea in Claude Code: Claude Code plan mode. Planning, approval and checkpoints across two editors: GitHub Copilot agent vs Cursor agent.