GitHub Copilot Agent Mode: Best Practices for Real Work

Agent mode is Copilot working inside your editor. You choose Agent in the chat view, describe a task, and Copilot decides which files to change, proposes edits and terminal commands, and keeps going until the task is done or it gets stuck. The practices that make it dependable are few: give it one scoped task at a time, plan before it edits anything large, keep approvals meaningful, review before you commit, and record the task somewhere that outlasts the chat.

Agent mode or the coding agent?

GitHub runs two different agents and the names blur. According to About GitHub Copilot cloud agent↗ (opens in a new tab), the cloud agent (formerly the coding agent) works in a GitHub Actions environment on tasks assigned through issues or chat, and hands you a branch or pull request; agent mode makes its edits directly in your local development environment. One is delegation, the other is pairing.

This post is about the editor. If you want to hand Copilot an issue and come back to a pull request, read the GitHub Copilot coding agent instead. The examples below use VS Code, where most people meet agent mode; the ideas carry to the other editors that support it.

1. One task per session, written down

Agent mode will accept “tidy up the settings page” and do something. What it does is its decision, not yours. A session that starts from a written task ends in a change you can check.

• State the outcome as an end state: “the settings form saves on Enter and shows an error when the email is invalid”, not “improve the settings form”.
• Name where it happens: the component, the test file, the API route. Copilot can search, but a path saves it guessing.
• Say how it will be checked: the test command, the page to open, what should appear.
• Say what it must not touch: generated files, migrations, the public API.
• Start a new chat for the next task. A long session carries old context into new work, and one task per session keeps the review small.

For a fuller template, see giving an AI agent a task it can finish.

2. Plan first when the change is not small

In a Local session, picked with the Session Target control, the chat view has three modes: Agent, Plan and Ask; the Copilot harness has its own Autopilot mode instead. In GitHub’s guide to Copilot Chat in the IDE↗ (opens in a new tab), the plan agent makes no code changes until you have reviewed and approved the plan; a button (Start Implementation in that guide, Implement Plan in recent VS Code builds) then switches to agent mode to carry it out. Use Plan whenever a change touches more than a couple of files, and Ask when you only want an explanation.

Read the plan as you would a colleague’s proposal. Wrong file, missing test, an approach you would not take: fix it now, while it costs one message instead of a revert.

3. Keep approvals meaningful

By default agent mode asks before it uses a tool you have not already approved, such as a terminal command or a call to an MCP server. VS Code’s page on approvals and permissions↗ (opens in a new tab) shows you can approve once, for the session, for the workspace or always, and that a permissions picker in the chat input can run every tool without asking.

• Approve reads freely and writes deliberately. Searching files is harmless; running a migration is not.
• Prefer “this session” to “always”. VS Code itself warns that global auto-approval removes confirmation prompts in every workspace.
• Auto-approve terminal commands narrowly with chat.tools.terminal.autoApprove, naming the commands you trust, such as your test runner. VS Code calls terminal auto-approval a best-effort convenience, not a security boundary.
• Treat MCP tools like any other tool. You can approve each one separately, so let the read tools of a server through and keep its write tools asking until you trust how the agent uses them.

4. Review before you keep

In a standard chat session, agent mode’s edits wait for you to keep or undo them, file by file or change by change. VS Code also takes a checkpoint before each request, so you can restore the workspace and the chat to an earlier point. The setting is chat.checkpoints.enabled, on by default.

Know what a checkpoint cannot do. VS Code’s page on reviewing agent edits↗ (opens in a new tab) says a checkpoint restores files and chat history but does not reverse terminal commands, network requests or deployments. A row the agent wrote to a database, a message it sent, a card it moved on a board: those stay done. That is where your approvals should be strictest.

• Read the diff in Source Control before committing, not just the chat summary.
• Run the check yourself: the tests, the page, the build. “Tests pass” in a chat message is a claim; see verifying AI-generated work.
• Commit each finished task on its own, with a message that says what changed.

5. Give it standing instructions, briefly

Anything you would repeat in every prompt belongs in a file Copilot reads on its own: how to build, how to test, what never to touch. .github/copilot-instructions.md applies to the whole repository, .instructions.md files with an applyTo pattern apply to matching files, and VS Code’s agent also reads AGENTS.md. Which Copilot surfaces read which file differs, and does GitHub Copilot read AGENTS.md? has the full list.

Keep the file short and true. Ten lines it follows beat a hundred it skims, and a wrong line is worse than a missing one.

6. Track the task outside the chat

A chat session is a poor record. Close it and the reasoning is gone; your colleagues never saw it. The task, what was decided and whether it was checked should live where the rest of the team looks. If that is a fenbs board, connect it to agent mode once through Copilot in VS Code and add the rhythm to your instructions:

## The board
- Before starting, call fenbs_whoami and fenbs_get_context, then fenbs_get_item for the task I name.
- No task named? Search with fenbs_search; if nothing matches, create one (kind: bug, feature or enhancement) and tell me its ref.
- When you start, move the task to In Progress and write your approach in its plan.
- When you stop, comment what changed and the command you ran to check it, and set testStatus honestly.
- Leave the move to Completed to me.

Two details help. fenbs_create_item holds back a task that looks like one already open and returns the likely matches, so the agent comments on the existing task instead of filing a duplicate. And every change it makes is recorded in the board’s history under its name and yours, so a week later you can see which tasks agent mode touched without opening a single transcript.

7. Know when to hand the task off

Not every task deserves your attention while it runs. Agent mode suits work where you want to steer: an unfamiliar part of the code, a change whose shape you are still deciding, anything that needs your local setup. A well-described, self-contained issue, such as a missing test or a small bug with a clear reproduction, can go to the cloud agent instead, which works on GitHub while you do something else and comes back as a pull request.

Inside a long session, subagents help in a smaller way. With the runSubagent tool enabled, agent mode can hand a research or analysis step to a subagent with its own context window, which returns only the result. The main conversation stays focused on the change instead of filling up with file contents it read along the way.

A short checklist

1. One written task per chat, with an outcome and a check.
2. Plan mode for anything larger than a couple of files.
3. Approvals per session, not always; terminal auto-approval only for commands you named.
4. Read the diff and run the check before keeping and committing.
5. Short instructions file, kept current.
6. The task on the board, moved and commented as the work happens.