Opening a pull request is only part of the job. Someone still has to chase the failed check, address the review and untangle the conflict.
VS Code Agent Merge targets that follow-up work. Microsoft introduced the preview in VS Code 1.136 on September 2. The release notes describe an iterative process that addresses reviewer feedback, failed checks and merge conflicts, then reruns workflows until the pull request is ready to merge. Readiness is the stated endpoint, not a promise of unconditional final merging.
How to enable the preview
Enable chat.agentMerge.enabled in VS Code settings. Session activation currently happens in the Agents window: run Enable Agent Merge for Active Session or use the Agent Merge title-bar button. These steps come from Microsoft’s release notes; this article is a documentation-based guide, not a hands-on review.
Check the Agents window documentation for the current session setup. If the control is absent, first confirm your installed version and whether you are in the documented window. Do not assume that enabling a setting also activated it for the session you meant to use.
Keep repair, approval and release separate
I would use three explicit states in a team trial. Repair means changes are still being made. Ready means the agreed checks can be inspected. Release means the repository’s authorized decision-maker has accepted the result. An assistant announcing completion should not silently move a change through all three states.
This distinction becomes especially important alongside Copilot’s approval controls. Configure the review policy deliberately before experimenting with a tool that keeps making changes in response to feedback.
Build a three-case trial
| Trial case | Controlled setup | What the reviewer checks |
|---|---|---|
| Failed check | Use a disposable branch with one known failing test. | The implementation fixes the cause without weakening the assertion. |
| Review request | Ask for one narrow change with written acceptance criteria. | The diff addresses that request without unrelated cleanup. |
| Merge conflict | Create a small, understood conflict between two test branches. | Both intended behaviors survive the resolution. |
Run the cases separately first. Combining them immediately makes a failure hard to diagnose. Keep the original branch or commit available, and use a repository without production credentials. Include a reviewer who understands the expected behavior rather than asking the agent alone whether its repair is correct.
Write the stop conditions before starting
Choose a trial budget and an intervention rule you can actually enforce. For example, stop after the same check fails repeatedly without a new explanation, or when the proposed fix touches a file outside the agreed scope. Those are suggested operating rules, not documented built-in Agent Merge limits.
Do not solve an inconvenient permission prompt by granting every available permission. Identify the specific operation, decide whether it belongs in the trial, and preserve the refusal as a useful observation if it does not. Workflow convenience is not a reason to expose deployment secrets.
Measure total review burden
Record elapsed time, human intervention minutes, reruns and the final diff. Track quota or provider charges using the usage records actually available to your account. Do not invent a fixed per-merge price from the feature name.
The result I would care about is accepted work with less follow-up effort. A fast repair that creates an unrelated change may cost more review time than it saves. A slower repair can be useful if the reviewer receives a small diff, a clear explanation and reproducible checks.
Our agent spend-control guide can help structure that accounting. Keep failed trials in the total rather than publishing only the cleanest example.
What to check when the loop gets stuck
- Classify the failure: code defect, unavailable dependency, missing access or an unclear review request. Each needs a different response.
- Compare the newest diff with the original request. Watch for changes to tests, fixtures or configuration that alter the meaning of a passing result.
- Confirm that workflow results correspond to the latest change, not an earlier commit.
- When the next step requires a product decision, stop the repair loop and ask the responsible person.
My take: try it on tedious, reviewable work
The sensible first use is a small pull request with good tests and a clear owner. Avoid using the preview as the first experiment on an authentication rewrite or production migration. Once the team has evidence from repeated low-consequence cases, it can decide whether broader use is justified.
Use the official release notes to confirm preview behavior as it changes. What consumes more time in your pull requests today: failed checks, review follow-ups or conflicts? Start the trial there.
