The agent has several modes, and they are chosen not by taste but by the degree of uncertainty in the task. Ask explores and answers, changing nothing. Plan asks questions, studies the code and assembles an editable plan. Agent edits files, runs tools and verifies the result. Debug builds hypotheses, adds temporary instrumentation and analyzes behavior at runtime. The difference between them lies not in the model's intelligence but in the set of permitted actions and in the moment your consent is required: four modes are four different answers to the question of what you are missing right now.
The naive strategy is to always turn on the most powerful mode: it can do more, after all. In practice that produces the worst result exactly where uncertainty is highest. An agent given an ambiguous requirement will not stop to clarify - it will pick an interpretation and start changing code. What you then have to diagnose is not the task but the resulting diff, and that costs more than one pass in question mode. Uncertainty does not disappear because it was handed to a more capable tool: it simply turns into code that looks finished.
The difference between the modes reads most easily through what you should not expect from them. From Ask - a finished change: it explains rather than does. From Plan - automatic implementation: the plan has to be accepted, and that is its value. From Agent - infallibility without review: it acts and verifies, but it does not answer for your agreeing with the result. From Debug - usefulness without reproduction: until the problem reproduces, there is nothing to instrument.
It helps to lay the modes out in a table with that fourth column once. Below is that map: what the mode does, when to choose it and what not to expect from it. You come back to it at the start of a task: the choice of mode is the first decision that either saves you an hour or creates extra work.
| Mode | What it does | When to choose it | What not to expect |
|---|---|---|---|
| Ask | Explores and answers without edits | Unfamiliar code, an architectural question, preparing the scope | A finished change |
| Plan | Asks questions, studies the code and builds an editable plan |
| Several systems, ambiguous requirements, an important agreement |
| Automatic implementation before approval |
| Agent | Edits files, runs tools and verifies | A clear task with a measurable result | Infallibility without review |
|---|
| Debug | Builds hypotheses, instruments and analyzes behavior | A reproducible complex failure, a race, a leak, a regression | Usefulness without an exact reproduction |
|---|
The plan has a subtlety that is easy to forget. By default it is saved in the home directory, that is, it stays your personal draft. A separate action moves it into the project - and only then does it become part of the team's history: it is visible, it can be discussed and it can be referred to. While the plan is personal it sits as a file in the home directory and stays your draft; moved into the workspace, it becomes a document from which people later reconstruct why the work was done this way.
Debug is arranged as a method, not as a button. It asks you to reproduce the problem, gathers data through a local debug server, then makes a narrow fix and removes the temporary instrumentation. Here it is important not to agree to a fix before reproducing again: until a failure reproduces reliably, any edit is a shot in the dark. And check separately that the debug logs are gone: instrumentation forgotten in the code outlives the bug it was added for.
The plan has a price, and it is worth admitting. It spends your time on reading and editing before a single line of code appears, and for an edit in one file that is an unnecessary ritual. The sign that a plan is genuinely needed is simple: you cannot name in advance the list of files that will change. As long as the list can be named off the top of your head, the task is clear without a plan. As soon as it cannot be named, the uncertainty is real, and dealing with it on paper is cheaper than dealing with it in the diff.
Ask and the plan are easy to confuse: neither changes code. They answer different questions. Ask closes a gap in understanding - how things are arranged here, where this logic lives, what breaks if it changes. The plan closes a gap in agreed intent - what exactly we are doing, in what order and how we will verify it. Hence a diagnostic sign: a plan of general phrases with neither files nor checks means understanding was missing, not a plan. In that case you go back to question mode instead of approving what was written.
Switching modes works with a single shortcut, and that invites changing them as the work goes. The practice that saves the most: start with questions when the code is unfamiliar; move to a plan when the task touches several systems; accept the plan and move to the agent; return to debugging if behavior diverges from expectation. If an implementation went the wrong way, it is often faster to restore a snapshot, sharpen the plan and run again than to fix on top.
The typical failures in choosing a mode are predictable. Sending the agent a task that does not yet have an unambiguous reading. Approving a plan of general phrases with neither files nor verification. Agreeing to a fix without reproducing the problem. And leaving debug instrumentation in the code that was added for a single pass.