GitHub has integrated Agent Merge into pull requests on GitHub, extending a capability already available in the Copilot app and Visual Studio Code. Announced on October 28, 2026, the integration lets Copilot respond to failing GitHub Actions workflows and merge conflicts from the pull request itself. GitHub's announcement describes a cloud development environment that starts work when a selected blocker appears.
For teams already using coding agents, the change moves another part of the development loop into delegated work: keeping an open pull request ready for a decision. The useful question is what the agent may repair, what a reviewer must inspect afterward, and who remains responsible for merging the result.
What the integration changes
The pull request's Watch and fix control lets a user select failed workflows, conflicts, or both. Access requires a paid Copilot plan and the relevant organizational policies. GitHub also requires the repository's automations policy to be enabled; fork-based and stacked pull requests are unsupported in the current documentation.
The execution environment matters. GitHub says these fixes run in an environment based on GitHub Actions, using repository setup steps, instructions and agent skills. AI credit usage is charged to the person who enables Agent Merge for the pull request, who may differ from its author. These are documented product conditions, not results from our own trial. Agent Merge documentation.
Repairing a blocker and authorizing a merge
Enabling Agent Merge does not turn on auto-merge. GitHub's separate auto-merge feature waits for the repository's required reviews and status checks before merging. The two features can work together, but they control different transitions.
That distinction should shape a team's review. A workflow can become green because the application was repaired, because the test was corrected, or because a check was weakened. The result needs to be traced through the diff. A resolved conflict likewise needs a behavioral review: producing a mergeable file does not establish that both branches' requirements survived.
Our guide to reviewing AI-generated pull requests develops this point through a concrete example: passing checks are evidence about what ran, while the reviewer still has to assess whether those checks cover the requested behavior.
A focused first evaluation
A useful evaluation would start with one bounded pull request and record the blocker, the agent's changes, the checks rerun and the review effort that remains. Inspect changes to tests and workflow definitions alongside application code. Also identify who can enable the feature and whose usage allowance will be consumed.
The announcement makes the capability available in another part of the GitHub workflow. Whether it saves a particular team time depends on the quality of the repairs and the work required to review them. We have not measured that outcome or tested Agent Merge in a repository.
