Microsoft has added Agent Merge to Visual Studio Code 1.136, turning the final stretch of a pull request into a repeatable agent loop rather than a sequence of manual handoffs. The preview can monitor the pull request attached to an agent session, ask the agent to address review feedback, fix failed required checks, update a branch, resolve merge conflicts, rerun workflows, and keep going until the pull request is ready to merge.
The feature shipped in VS Code 1.136 on September 2, 2026. It is disabled by default behind chat.agentMerge.enabled, and users choose which classes of blocker the agent may address. Automatic merging is separately configurable and defaults to off.
The important change is not code generation
Coding agents already write patches, run tests and respond to review comments. Agent Merge changes the control flow around that work. Instead of waiting for a developer to notice each new blocker and start another turn, VS Code can start additional agent turns as the pull request changes.
Microsoft's documentation says Agent Merge can address unresolved review threads, changes-requested reviews and new maintainer comments; fix failed required CI checks; update branches that are behind and resolve conflicts; and, if configured, merge the pull request or add it to the merge queue after the selected maintenance work is complete.
That makes the pull request state itself an input to the agent loop. A failed check, a new review comment or a conflict can become the trigger for another repair attempt. The agent is no longer only producing a patch. It can remain attached to the lifecycle of the pull request.
Enabling the loop also changes the permission model
This is where the feature becomes more than a convenience improvement. Microsoft explicitly warns that enabling Agent Merge changes the session to Autopilot with Assisted permissions. The feature can start agent turns, change and synchronize the pull request branch, and consume additional model requests without the developer manually initiating every step.
Those permissions are bounded by the surrounding repository and VS Code controls, but the operational boundary has moved. A team that previously reviewed one agent-produced patch now has to reason about a process that may produce several successive patches in response to changing external state.
Automatic merge is not the default. The chat.agentMerge.mergePullRequest setting defaults to never; administrators or users can instead allow automatic merge always or only while the pull request has not been changed by an agent repair turn. Agent Merge also rechecks readiness immediately before merging or entering the merge queue.
Green CI is necessary, but it is not independent assurance
Aipolix's main engineering conclusion is that teams should separate the agent's repair authority from the controls that prove a change is acceptable.
Agent Merge is designed to modify the branch until required checks pass. That is useful, but it means a green result is evidence that the configured checks accepted the resulting branch, not independent evidence that the agent's changes are correct or complete. The stronger the agent's write permissions, the more important it becomes to keep critical acceptance controls outside the same authority boundary.
In practice, organizations can preserve that separation with protected branches, required reviews, CODEOWNERS rules, narrowly scoped credentials, protected CI configuration, and human approval for high-risk repositories. The exact combination will vary, but the design principle is stable: the system that changes code should not be the only system that decides whether the change is safe to ship.
This matters especially when Agent Merge is allowed to respond repeatedly. A poor first repair can create a different failing check, which can trigger another repair. The useful unit of review is therefore not only the final diff. Teams also need the sequence of agent turns, the blockers that triggered them, the commands or workflows rerun, and the permissions active during the session.
The preview exposes a measurable operating model
The feature is unusually explicit about its controls. Teams can enable or disable review handling, CI repair and conflict resolution separately. Automatic merge is a distinct choice. Monitoring turns off if the session starts tracking a different branch or pull request and must be enabled again.
That gives engineering organizations a practical rollout path. A low-risk pilot can start with automatic merge disabled, allow the agent to address review feedback and CI failures on selected repositories, and require a human to inspect the accumulated changes. Teams can then measure repair success, number of autonomous turns, model usage, rollback rate and the kinds of blockers that still need human judgment.
The most useful question is not whether Agent Merge can make more pull requests green. It is whether the organization can prove which actions the agent took, which controls remained independent, and who retained authority over the final merge.
A continuous agent needs continuous governance
VS Code 1.136 moves the coding agent closer to an operational worker that stays attached to a software change until its acceptance conditions are satisfied. That can remove repetitive coordination work from developers, particularly on pull requests with routine review fixes, flaky integration problems or branch drift.
It also makes governance more concrete. Permissions, branch protections, required reviewers and audit trails are no longer background configuration. They define the boundary within which an autonomous repair loop is allowed to operate.
Teams adopting the preview should therefore evaluate Agent Merge as a workflow system, not simply as another coding feature. The value comes from closing the loop around pull-request maintenance. The risk comes from closing that loop without preserving an independent acceptance gate.