Switch - match the role to the risk

Anyone can read the three role descriptions (Ask reads and answers; Plan proposes an approach for your approval; Agent edits and runs) and remember them. The skill that separates someone who has Copilot installed from someone who works well with it is glancing at a task and knowing, almost without thinking, how much latitude it should get. This page makes that instinct explicit, because everything later in the course - permissions, model choice, delegation - reuses it.

What decides the choice is not difficulty

The surprising part is what does not decide the role: how hard the task is. A gnarly algorithm contained in one file you own can go straight to Agent, with commands still gated by default, because the worst outcome is a diff you throw away. A trivial signature tweak to a function a dozen services import wants Plan in front of it, because the worst outcome ripples outward to teams you will never meet. Difficulty measures how much work the task takes; what measures the role is how much a wrong answer costs, and how hard it is to undo - the reach of the damage, and the cost of walking it back.

One trap hides inside “hard to undo”: an edit can be trivially recoverable while the action it triggers is not. Deploy configuration is edited in git and applied to production - reverting the file does not un-provision what the apply created. When that split exists, gate the step where the tracked change becomes the outward action, not the edit. (The dial marks cells like this with its stricter postures because, in generic tools, the apply often hides inside a command the agent could choose to run; in Copilot terms the target is the same either way - edits may flow, the apply-command stays gated.)

The running example makes the same point with one engineer and one feature. The service side (orders-service, your squad’s own app, where a mistake is cheap to undo and redo) takes long latitude: hand the goal to Agent and review the whole diff at the end. The library side (shared-lib, imported by roughly a dozen services, breaking changes ripple and stick) takes short latitude: understand in Ask, agree the approach in Plan, keep the edits scoped and reviewed. Same person, same feature, opposite postures - set entirely by what was at stake.

A decision path that fits in your head

When a task lands and you are unsure, walk this path and stop at the first match:

1. Do I actually understand this code yet? No - Ask. You are buying a map before you edit the terrain, with no risk to the code because nothing changes.
2. Is the approach itself the risk - shared surface, many consumers, hard to undo? Yes - Plan. Agree the approach while changing it costs a sentence. And if the worst action is irreversible and reaches beyond your machine - a deploy, a send to customers, a delete in shared territory with no backup - go one stricter still: stay in Ask and have Copilot draft the exact commands while you run them. (Irreversible but purely local - a delete with no backup on your own machine - the dial below keeps in the gated lane instead: every destructive command behind a yes.)
3. Do I know exactly which files change, and want nothing else touched? Yes - Agent with a scoped request: name the files, then review the diff against that list.
4. Is it well-scoped work in code I can afford to iterate on? Yes - Agent. Give the goal, watch the confirmation prompts, review everything at the end. Mechanical work that is entirely local and cheap to undo can go one looser still: Agent inside a sandbox or throwaway worktree, reviewed as one batch.

And if no step matches - the task is too vague to scope and too unfamiliar to delegate - that is the path’s answer: the task is not agent-ready. Go back to step 1 and make it one in Ask.

It reads as a ladder of latitude, and within one task you climb it as confidence grows: understand, agree the approach, build. Switching mid-task keeps you in the same conversation - your questions and its findings are still right there in the chat - and even where a switch starts a fresh session, the worst case is re-pasting your findings, not redoing the work. Either way climbing costs little, which is why starting low is never wasted. You lose a question, not a session. (Steps 2 and 3 combine on shared-surface work: agree the approach in Plan, then take scoped, reviewed edits at the delegated rung - the gate being Plan’s approve-before-build, the leash being the permission level; two controls, not two visits.)

The same judgment, with the stakes made explicit, is what the dial below trains. Pick how hard the worst action would be to undo and how far its consequences would reach, and the dial names a posture. Treat the correspondence to Copilot as approximate, because the dial is tool-agnostic by design and Copilot realizes its rungs through roles and permission levels together:

• Read and propose only is Ask.
• The everything-waits postures - the dial’s ask-before-acting rung - are realized two ways in Copilot: Plan, everything waiting while you approve one approach, or Agent at its strictest permission level, every action pausing for a yes. Same protection, different shape. Pick Plan when the work needs an agreed path before any action; pick the strict Agent level when it needs many individually gated actions.
• The delegated rungs - edits flowing with the consequential commands still gated, and run free inside a fence - are Agent at progressively looser permission levels. The fence itself (a sandbox or a worktree) is configured separately from the permission level.
• The dial’s never-rung - nothing pausing, no fence - has no responsible Copilot setting on a real machine; it belongs to disposable environments only.

Where exactly Copilot draws each line - which edits flow, which commands pause - is a permission-level question; the permissions documentation tracks it (as of September 2026), and the Permissions chapter covers it.

Two questions decide how much leash a task earns - neither of them is “how hard is it.” Set both for the work in front of you and read the rung it lands on.

If the agent’s worst single action went wrong, undoing it would take…

a git checkoutthe change lives in tracked files; the floor holdsreal worka migrated database, regenerated files, a rebased brancha miraclea send, a deploy, a delete with no backup

…and its consequences would reach

your working copyone repo, one machine, nobody downstreamwhat the team sharesa library others consume, common infra, shared databeyond the machineproduction, customers, money, the public

1. Run free, no fencedisposable environments onlyNothing pauses it and nothing contains it. No combination on this dial lands here - it belongs only where the whole environment is disposable: a throwaway container, an already-isolated CI runner.
2. Run free inside a fencethis taskNo prompts; the boundary does the protecting. The agent grinds end to end inside a sandbox, container, or scratch worktree, and you review the whole batch once at the end.
3. Auto-apply edits, gate the rest
4. Ask before acting
5. Read & propose only

A mechanical rename across your own repo is the canonical case: the worst outcome is a git diff you throw away. Prompting on every one of twenty-four identical edits doesn’t add safety - it teaches you to stop reading prompts, which is where real risk starts. Let it run inside the fence and review the batch once.

The rung names are generic on purpose - every tool spells its own versions of them, and most let you set different rungs for different categories of action. The judgment underneath is the same two questions, asked per task, never answered once for all time.

The judgment outlives the tool

Step back and notice what this chapter actually practiced. Not three features of a product - a habit of matching autonomy to stakes: a long leash where mistakes are cheap, a short one where they are expensive. That habit is not Copilot-specific. The Permissions chapter turns it into a setting; every other course on this site turns it into that tool’s equivalent controls; and any capable agent you pick up next year will give you some version of the same dial to set.

There is a piece of unfinished business, though. Whenever you wanted a first draft that already matched a repo’s style, these lessons had you say so by hand, every request. That repetition is a signal: knowledge that never changes between requests is being re-typed into chat. The fix is to write it down once, in files Copilot reads on every request - and, if you have taken another course on this site, you may already have written those files. Next chapter: Rules - teaching Copilot your conventions.