Agent Mode and the Cloud Coding Agent

A ticket asks for a --verbose flag in a command-line tool. You can make the edit yourself. You can also give Copilot the task and watch it inspect the argument parser, propose the change, run tests, and return a diff for your approval.

Agentic coding supports both a local agent that works beside you and a remote agent that returns later with a branch. Either can save time. Either can also touch more than the ticket allows. Keep evidence you can inspect after the run, such as the diff, test output, and any source behind a factual claim.

Agent mode works through a bounded loop

Local agent mode turns a chat into a supervised control loop. You state a goal and its boundaries. The agent inspects the relevant files, proposes work or asks to use a tool, and you approve, reject, or revise before it acts. Your evidence is the files it read, the resulting diff, and the test output, not the agent's own explanation.

VS Code maps that loop to three modes that match three phases of a task. Ask is for orientation: explaining code and finding your way around a repository without changing anything. Plan turns a requested outcome into a reviewable implementation outline. Agent carries out the implementation through a sequence of tool calls. A controlled workflow starts in Ask, moves to Plan, and enters Agent only after you have reviewed the proposed scope.

Agent mode can act: it reads files, edits files, and runs terminal commands. GitHub's guidance names example tools such as read_file, edit_file, and run_in_terminal, and MCP can extend that toolset with external systems (you will meet MCP later in this module). Tool names and how they appear on screen vary between builds, so judge the operation being requested, not its label. A request to read one source file carries far less risk than a request to delete files, run a migration, or publish.

That gap is why the modes matter. Starting in Agent while the request is still fuzzy invites the agent to guess at scope and start editing. Starting in Ask shows you the repository evidence first, and Plan pins down what should change before anything does. The two cheap steps are what make the expensive one reviewable.

Approvals keep the boundary visible

An approval authorizes one proposed operation. Before accepting it, read the operation, file path or working directory, command and arguments, and how the step contributes to the task. Check whether it could delete, overwrite, publish, or expose anything. Approve the smallest action you understand. Reject or revise a step that extends beyond the work in front of you.

You still need to inspect the result. Plans deserve the same treatment because they are review artifacts, not permission slips. A useful plan identifies the files, the behavior that must remain, the order of work, the verification commands, and any open questions. Send it back if it invents a file, adds an unrelated refactor, skips verification, or presents an assumption as fact. Once accepted, the plan defines the current boundary. Work outside it needs a new explanation.

The same caution applies to subagents and memory. A subagent can take a narrow read-only question such as "list the edge cases this parser doesn't test." Its answer is still a set of findings to check against the code. Memory can retain reusable context such as a test command, but repositories change. Confirm remembered details before relying on them, and store durable rules in repository instruction files where the team can inspect them.

Scope drift is the stop signal. If the agent reaches beyond the accepted plan, ask for a file-by-file justification before it continues. A fluent summary is easy to produce. It is weaker evidence than the code and the checks.

When should you delegate to the cloud instead?

Local agent mode keeps you in the loop in real time. The cloud coding agent works differently: you delegate a task, it works in a GitHub Actions-powered environment, and it returns its changes on a copilot/* branch and pull request. A session has a hard ceiling of 59 minutes, so the work has to fit inside one. Picture a relay: issue contract, cloud execution, copilot/* branch, pull request, independent human review. The pull request is a proposal, never proof.

Choose between them by the shape of the work. Reach for local agent mode when the task depends on uncommitted files, local credentials, a desktop tool, or rapid back-and-forth decisions. Reach for the cloud agent when the task can be written down as a stable repository contract and validated with ordinary project commands, and you would rather review a finished branch than supervise each keystroke.

For the cloud agent, the issue is the contract, and a vague one like "fix the API" forces the agent to guess the target and the definition of done. A delegation-ready issue answers six questions: what single outcome is required, what repository context matters, what observable conditions define success, which commands validate the result, what must stay unchanged, and what evidence the pull request must report. The cloud environment is separate from your laptop and may not have your caches, config, secrets, or tool versions, so name the real setup and validation commands, name any required environment variables without their values, and accept that a check needing unavailable infrastructure must come back as unverified rather than passed.

Durable guidance that many tasks share belongs in AGENTS.md, a repository instruction file the coding agent supports (GitHub added that support on August 28, 2025). Task-specific requirements stay in the issue. One licensing note: the cloud agent is included with Copilot Business and Enterprise, while the hands-on GitHub Skills lab specifically calls for Copilot Pro+, so check what your own account and organization grant before you plan around it.

Review the evidence the agent returns

Whether the changes arrive as a local diff or a cloud pull request, the review is the same job, and it hinges on one distinction: every acceptance criterion resolves to pass, fail, or unverified. Pass means direct evidence demonstrates it. Fail means direct evidence contradicts it. Unverified means the available evidence can't establish either: a focused endpoint test can pass while the full suite stays unverified because its database configuration was missing. Unverified is not a synonym for failed, but it is not a pass either, and no unverified check supports a claim that "all tests passed."

Work through the result deliberately. Read the completion report or summary first, then read every changed file, then compare that changed-file set against the scope the task allowed. Run the narrowest relevant validation yourself, in an environment you trust, rather than relying on the agent's reported result. Only after the diff, the evidence, and repository policy all line up do you merge.

A concrete case shows why this catches real bugs. A cloud agent adds a clean GET /health endpoint and its focused test passes, but buried in the changed files is an edit to auth.js that bypasses authentication for the route, even though the issue explicitly forbade authentication changes. The focused behavior passes. The full suite is unverified because its test database wasn't configured. The authentication change is a flat constraint violation. Two of those are fine. One is disqualifying. The correct call is to request changes and re-run validation against the corrected commit, not to merge because the happy-path test went green.

A completed run, an opened pull request, or a confident paragraph is an artifact for you to review, not a verdict you inherit. You give the agent the work. You keep the merge decision, and the evidence that earns it. The same loop moves into the terminal and into reusable rules in The CLI, Custom Instructions, and Prompt Files.