Copilot Agent vs Ask vs Plan: Which Mode for Which Task?

Use Ask when you want an answer and no change, Plan when the change is big enough or risky enough that you want to agree the approach first, and Agent when the task is clear and you are ready for Copilot to edit files and run commands. The deciding questions are two: how many places 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 change across a dozen files, a migration or anything you cannot easily undo goes through Plan. Anything you do not yet understand starts in Ask.

The three modes, as they stand today

Copilot’s chat modes have changed names and number more than once, so check the picker in your own editor. In VS Code’s documentation on agent harnesses↗ (opens in a new tab), local sessions offer three built-in roles: Ask “asks questions and provides guidance without making changes to the code”, Agent “autonomously plans and performs complex coding tasks, edits files, runs commands, and iterates on results”, and Plan “researches a task and creates a structured implementation plan before code changes”. You switch between them from the agent picker, even in the middle of a session.

If you remember a fourth mode called Edit, it has gone. The VS Code 1.110 release notes↗ (opens in a new tab) deprecated Edit mode, with a setting to bring it back only until version 1.126. Its job, targeted edits to files you name, is now something you ask Agent to do. The same three names appear in GitHub’s guide to Copilot Chat in the IDE↗ (opens in a new tab), which describes Ask as optimised for questions about your codebase and coding concepts.

One caveat: the picker shows what the selected session type supports. Local sessions have all three; other harnesses, such as a cloud session or a third-party agent running inside VS Code, may offer a different set. What follows is about the local chat most people use every day.

Ask: understand before you change anything

Ask is for questions whose answer is words, not a diff. It is the cheapest mode to be wrong in, because nothing in your workspace moves.

• “Where is the session timeout set, and what reads it?”
• “Why would this test pass locally and fail in CI?”
• “What does this regular expression actually match?”
• “Which of these two libraries does the project already use for dates?”

Reach for Ask whenever you would otherwise let Agent loose on something you do not understand yet. An answer in Ask often turns a vague task into a precise one, and a precise task is what the other two modes need.

Plan: agree the approach before the edits

Plan researches the code and asks you questions before it proposes anything. VS Code’s page on planning with agents↗ (opens in a new tab) says the agent “researches your project, asks clarifying questions, and creates a plan for you to review before implementation”, using read-only tools while it does. You can pick Plan from the picker or type /plan followed by the task.

When the plan is ready you have three ways out: Implement Plan, which approves it and starts the work in the same session; Approve Plan Only, which approves it without running it, so you can change model first; or save a copy of the plan and attach it to a new session later. The last one matters more than it looks, because it means the plan can outlive the chat that produced it.

Read a plan the way you would read a colleague’s proposal. A wrong file, a missing test, a migration you did not expect: all of them cost one message to fix now and a revert to fix later.

Agent: do the work

Agent is the only one of the three that changes your workspace. It decides which files to edit, proposes terminal commands, runs them, reads the errors and tries again. How much it asks you first depends on the permission level in the chat input. VS Code’s page on approvals and permissions↗ (opens in a new tab) lists the default, where actions that are not auto-approved need your confirmation, and Allow all, which runs every tool call without asking.

The habits that keep agent sessions reviewable, one task per chat, meaningful approvals, reading the diff before you keep it, are covered in GitHub Copilot agent mode best practices. This post is only about the choice of mode.

Matching the mode to size and risk

Size is how many files and decisions the task involves. Risk is what happens if the first attempt is wrong: an annoyance you undo in seconds, or data changed, a command run, a contract broken. Put the two together and the choice mostly makes itself.

• Small and low risk: a typo, a renamed variable, a missing test for one function. Agent, directly. Planning costs more than the change.
• Small but risky: a one-line change to authentication, a config value that reaches production, a command that writes to a database. Ask first to confirm what the line does, then Agent with every approval read.
• Large and low risk: a refactor across many files with good test coverage. Plan, then Implement Plan. The plan is where you catch the file it should not touch.
• Large and risky: a schema change, a new payment flow, anything that deletes. Plan, save the plan, and break it into separate tasks before Agent touches any of them.
• Not sure what it is yet: Ask. You cannot size a task you do not understand.

A useful rule of thumb: if you could not write the acceptance check for the task in one sentence, you are not ready for Agent. Ask until you can write it, or Plan until the plan contains it. Giving an AI agent a task it can finish has a template for that sentence.

Switching mid-task

Because you can change role in the same session, a common path through a medium-sized task is Ask, then Plan, then Agent: understand the code, agree the approach, carry it out. Switching back is just as useful. If Agent starts making changes you did not expect, stop it, switch to Ask and ask why it chose that approach. If a plan turns out wrong halfway through implementation, return to Plan rather than steering Agent one correction at a time.

Start a fresh chat when the task changes. A session that began as an explanation of the billing code and drifted into a refactor carries the whole conversation into every later request, and the review at the end is harder than it needs to be.

When the built-in three are not enough

If you keep typing the same instructions into one of the modes, make a custom agent. VS Code’s documentation on custom agents↗ (opens in a new tab) describes them as role-specific configurations in .agent.md files, kept in .github/agents for a workspace, and notes they were previously called custom chat modes. A custom agent can also offer a handoff, such as from a planning agent to an implementation agent once the plan is reviewed. A “reviewer” with read-only tools or a “migrations” agent that always plans first are typical examples.

Keep the plan somewhere other than the chat

The weakness all three modes share is that their output lives in a chat. A plan you approved on Tuesday is hard to find on Friday, and the colleague who picks up the work never saw it. The fix is to put the task and its plan where the team already looks.

On a fenbs board, each task has a note for the problem and a separate plan for how it will be done, which is exactly the shape of a Plan-mode session. Tasks also carry a size from xs to xl, where xl means split it: a useful check before a large, risky task goes to Agent. Connected over Copilot in VS Code, the assistant can write the approved plan into the task itself:

## Plans and the board
- In Plan mode, once I approve the plan, write it into the task's plan with fenbs_update_item.
- If the plan is size xl, propose how to split it into separate tasks instead of implementing it.
- In Agent mode, move the task to In Progress when you start and keep the plan current as you learn.
- When you stop, set testStatus and testNotes: how it was checked, and what was not.

Choices that outlast the task, such as which library you settled on or why the migration runs in two steps, belong on the board’s Decisions page, where each one records what was decided, why and by whom. An assistant can write a decision down; the person who decided is always a person.