Agent Merge Moves Copilot Into the Final Stretch of a Pull Request

GitHub announced on September 4, 2026 that Agent Merge is now in public preview as part of the VS Code 1.136 release updates. The feature is designed to help get a pull request ready to merge by resolving review feedback, failed checks, and merge conflicts. That is a meaningful expansion of the coding-agent workflow because the work does not stop when code is generated. Copilot is being pushed further into the stage where changes are reviewed, validated, repaired, and prepared for the final merge.

The Goal Is a Merge-Ready Pull Request

The new feature is centered on a simple outcome: take a pull request that still has blockers and help move it toward a state where it can be merged. GitHub’s changelog names three common blockers directly: review feedback, failed checks, and merge conflicts. These are exactly the kinds of issues that often appear after the main implementation is already finished. Agent Merge gives Copilot a role in that follow-through instead of leaving every cleanup step as a separate manual task.

Review Feedback Can Become an Agent Task

GitHub’s Copilot app documentation already shows the broader workflow behind this idea. When a pull request has review comments, a developer can ask an agent to resolve a comment with a Fix action. The agent can inspect the requested change, update the code, and continue the pull request workflow. Agent Merge builds on that direction by making review feedback part of a larger merge-readiness process rather than a disconnected step.

Copilot Can Work on Failing CI Checks

GitHub also documents Copilot workflows for failing CI checks. In the Copilot app, developers can ask an agent to fix failing checks from the pull request view. In Copilot CLI, the /pr fix ci command lets Copilot inspect failing CI jobs, analyze the logs, apply targeted fixes, push the changes, and re-check the CI status. This makes automated validation part of the same agentic loop as code changes.

Merge Conflicts Are Now Part of the Agent Workflow

Merge conflicts are another important part of the new flow. GitHub already lets Copilot cloud agent help resolve conflicts from a pull request. The agent can analyze the conflicting changes, resolve them, and verify that the build, tests, and linter still pass before requesting review. Agent Merge brings that capability into a broader workflow whose goal is to move the entire pull request toward merge-ready status.

Copilot CLI Shows the Full Pull Request Lifecycle

GitHub’s /pr command in Copilot CLI makes the direction especially clear. Developers can view pull request status, create a pull request, address review feedback, resolve merge conflicts, fix CI failures, or run the entire sequence. The /pr fix command handles feedback, conflicts, and CI in order, while /pr auto can continue looping through those phases until the pull request is fully green. Agent Merge fits directly into this larger move toward end-to-end pull request automation.

One Command Can Address the Main Pull Request Blockers

The /pr fix workflow is a useful preview of how GitHub is thinking about agentic pull request work. It runs three phases: review feedback, conflicts, and CI failures. Those are the same categories highlighted in the Agent Merge announcement. Instead of requiring the developer to jump between several tools and manually coordinate each repair, Copilot can work through the sequence as one connected task.

Agent Merge Can Keep Working in the Background

GitHub’s Copilot app documentation describes Agent Merge as a background workflow. When enabled, it prompts the workspace’s Copilot session to read the pull request, fix what is blocking it, and merge it as soon as GitHub allows. The workflow survives app restarts and turns itself off once the pull request is merged. That makes the feature feel less like a one-shot command and more like an ongoing agent watching the state of the pull request until the job is complete.

The Human Still Owns the Final Development Workflow

The strongest version of this workflow is not about removing developers from the process. GitHub’s own documentation keeps review and repository rules in the loop. Copilot can make changes, resolve blockers, and request review, while normal branch protections, approvals, and repository settings continue to determine when a merge is allowed. That keeps the agent focused on execution while the project’s existing collaboration model remains intact.

Copilot Was Already Moving Into Pull Request Repair

GitHub has been expanding Copilot cloud agent beyond code generation for months. In an official GitHub Checkout demonstration, the company showed Copilot working on pull requests, resolving merge conflicts, and handling development tasks around CI and review. Agent Merge turns that broader direction into a more explicit merge-readiness feature inside the current VS Code release cycle.

The Agent Can Read the Pull Request as a Working Context

A pull request contains much more than a diff. It includes review comments, CI status, branch relationships, code changes, and project history. GitHub’s Copilot app lets an agent operate with this pull request context and start a session directly from the PR. That gives the model a richer working surface than a generic code prompt because the agent can act on the state of the actual change that is moving through review.

This Changes What a Coding Agent Is Expected to Finish

Early coding assistants were mainly judged by how well they generated code. Agent Merge points toward a broader definition of completion. A useful coding agent is increasingly expected to help with the full path from implementation to review, validation, conflict resolution, and merge readiness. The result is a workflow where the agent is responsible for more of the delivery process, not just the first draft of the code.

Pull Request Automation Is Becoming More Continuous

The combination of Agent Merge, Copilot CLI pull request commands, cloud-agent conflict resolution, and CI repair shows a clear pattern. GitHub is connecting individual Copilot actions into continuous workflows. A developer can ask for a change, move it into a pull request, respond to feedback, repair checks, resolve conflicts, and continue until the repository’s merge conditions are satisfied. The boundaries between coding, review, and release preparation are becoming much more connected.

VS Code Is Becoming a Home for Agent Sessions

The same VS Code 1.136 update also adds new ways to manage agent sessions. GitHub’s changelog notes multi-root workspace experiments, chat-session organization, and indicators for sessions that need attention. These additions matter because long-running agents need a place where developers can see what is happening, return to a task, and understand which sessions require input. Agent Merge fits naturally into that environment.

The Pull Request Becomes an Active Agent Workspace

With Agent Merge, the pull request is no longer just a review artifact at the end of coding. It becomes an active workspace where an agent can keep contributing after the initial implementation. Review feedback can lead to new edits, CI results can trigger repair work, and merge conflicts can become another step in the same ongoing session. That turns the PR into a live coordination point between the developer, reviewers, repository rules, and Copilot.

GitHub Is Connecting Copilot Across App, CLI, Cloud Agent and VS Code

One of the most important aspects of this update is that the same pull request lifecycle is appearing across several GitHub surfaces. The Copilot app can respond to reviews and failing checks. Copilot CLI exposes /pr commands for the full workflow. Copilot cloud agent can resolve conflicts directly from GitHub. VS Code now adds Agent Merge. The pieces are converging around one idea: Copilot should be able to participate wherever the pull request is being worked on.

The Upgrade Feeling

Agent Merge is a strong example of coding agents moving from code creation into software delivery. GitHub is giving Copilot a larger role after the first implementation is done: read the pull request, respond to review feedback, work through failing checks, resolve merge conflicts, and keep moving toward merge-ready status. For developers, that means the agent is becoming less like an autocomplete layer and more like a collaborator that can stay with a change through the final stages of the pull request.