---
title: "Merge Automation"
description: "Merger, its approvals, and auto resolve: how Baz acts on merge readiness instead of only reporting it."
canonical: "https://baz.ai/docs/capabilities/merge-automation"
---
# Merge Automation
Merger, its approvals, and auto resolve: how Baz acts on merge readiness instead of only reporting it.
Merge automation covers everything Baz does once a review is finished: the Merger agent that judges whether a pull request is ready and can approve it, and the review threads Baz can close. Each part is configured separately, so a team can adopt merge readiness as a signal first and let Baz act on it later.
## Merger
Merger is an agent that evaluates open pull requests for merge readiness and returns one verdict per pull request: merge, reject, or escalate. It exists to clear stale queues without asking a human to re-check the same signals on every pull request.
### What Merger weighs
| Signal | Description |
| ------------------------ | ----------------------------------------------------------------- |
| CI state | Whether required checks have passed, failed, or are still pending |
| Unresolved Baz findings | Open review comments that have not been addressed |
| PR metadata | Title, description, labels, and linked tickets |
| Diff context | The actual change, not just its metadata |
| Repo impact | How broad or risky the change is within the repository |
| Git history | Prior commits and related changes in the same area of the codebase |
| Merge rules | The deterministic bars and written guideline you configured |
| Org guidelines | Team-specific review and merge conventions |
### Verdicts
A **merge** verdict means the required signals are satisfied and the change is safe to move forward. A **reject** verdict means the change has issues that should block it, such as failing CI or unresolved critical findings. An **escalate** verdict means the change carries enough risk, ambiguity, or business impact that a human should decide, which is what Merger returns for failed or pending CI, open critical findings, and changes it identifies as high impact.
Merger labels the pull request with its verdict and, when the rule enables it, posts a comment explaining the decision and approves the pull request. Escalation is the safety valve: Merger acts on its own only when the standard signals clear the change, and defers to a human reviewer otherwise.
### Configuring merge rules
Merger is an agent in the **Deploy** stage of the [Software Factory](/docs/agents/baz-agents#the-software-factory). Turn it on and select its row under **Agents → Baz Agents → Deploy** to edit its rules. Turning Merger on with no rules adds a default rule covering all repositories and all authors, so it starts working right away; narrow it from there. A rule scopes Merger to repositories and sets the bars a pull request has to clear before Merger will call it ready. Each rule reads top to bottom: **If repo** picks the repositories, **Contains** holds the PR authors and any conditions added with **Add condition**, **Guideline** takes the free text, and the switches below it decide what Merger does with its verdict.
A Merger rule: repositories, conditions, guideline, and the Then: Auto approve switch
| Rule setting | Description |
| -------------------------------- | -------------------------------------------------------------------------------------------- |
| Repositories | Which repositories the rule applies to, or all of them. Individual repositories can be selected only for GitHub |
| PR authors | Limit the rule to specific authors, or leave it open to all |
| Excluded paths | Paths that disqualify a pull request from the rule |
| Max lines changed | An upper bound on diff size |
| Max files changed | An upper bound on the number of touched files |
| Findings | A severity bar (high, medium, low) per agent, so an open finding of that severity blocks the verdict |
| Guideline | Free text telling the agent how to judge the changes this rule covers |
| Explanation as a PR comment | Whether Merger posts the rationale behind its decision on the pull request |
| Then: Auto approve | Whether Baz approves the pull request when Merger decides it is ready to merge. Requires write access |
Once a rule is in place, merge readiness is evaluated automatically for every new pull request and every new commit in the repositories it covers.
### Label-only mode
A rule with **Then: Auto approve** off runs Merger in label-only mode. Merger evaluates every pull request and applies its verdict label, and posts its explanation if the rule enables it, but never approves. Use it to measure Merger in [Merger Agent Stats](#merger-agent-stats) before letting it approve.
### Merger Agent Stats
Merger's track record is tracked in **Insights → Evaluation → Deploy**, so trust in the agent rests on outcomes rather than a one-time impression.
Merger Agent Stats: evaluated pull requests, ready-to-merge share, breakdown, and throughput
| Metric | Description |
| ----------------------------- | ---------------------------------------------------------------------------------- |
| Evaluated PRs | How many pull requests Merger assessed |
| Marked as Ready to Merge | The share of evaluated pull requests where Merger recommended merging |
| Merged Without Human Input | The share of those that merged with no follow-up commits after the recommendation |
| Ready to Merge PR Breakdown | How the recommended pull requests split across their current status: merged, open, or closed |
| PR Throughput | Pull requests opened against pull requests merged over time |
If Merger is off, the tab shows nothing for it. Turn it on from the Deploy page.
## Approval
Approval is part of Merger. The same rule that judges merge readiness decides whether Baz approves, so the deterministic gates, the written guideline, and Merger's own reasoning all feed one decision. There are two ways to use it, depending on the access you grant Baz.
### Auto approve in a Merger rule
Turn on **Then: Auto approve** in a Merger rule and Baz approves the pull request whenever Merger decides it is ready to merge. Baz is added as a reviewer and submits an approving review.
The approval only happens when everything in the rule lines up:
| Gate | Description |
| -------------------- | ------------------------------------------------------------------------------- |
| Repositories | The pull request is in a repository the rule covers |
| PR authors | The author matches the rule, or the rule is open to all users |
| Conditions | Excluded paths, line limit, file limit, and findings severity bars all pass |
| Guideline | Merger's reasoning over the diff, the guideline, and the blast radius ends in a merge verdict |
Auto approve requires write access, which comes with the [Baz-app](/docs/basics/configure-with-github#permission-model). The switch is disabled when any selected repository lacks write access, and it turns off if you change the rule to include such a repository. A reject or escalate verdict never adds an approval.
### When new commits are pushed
An approval is tied to the commit Merger evaluated. When new commits are pushed, Baz withdraws its approval while CI and review run on the new head, and approves again only if Merger's verdict is still merge. Baz does this itself, so it does not depend on your branch protection dismissing stale approvals.
### Required approvals
Baz approves with a standard approving review from the Baz app. Whether that review counts toward your branch protection's required approvals depends on your repository settings. It never satisfies a code owner or specific team requirement.
### Baz approved label
For teams that only want a marker, the Merger rules on the Deploy page have an **Add "Baz Approved" label** switch. When it is on, Baz adds a "baz approved" label to a pull request once all Baz findings on it are resolved. It does not submit a review and does not approve the pull request, so it needs read access only.
The label applies only to repositories that no Merger rule covers. Repositories with a rule get Merger's verdict label instead.
## Auto resolve
Auto resolve is configured in **Baz → Settings → Configurations → Auto resolve**.
**Reply to resolved discussions** controls how Baz marks addressed comments. It can reply to all relevant threads or only to Baz threads, and it can reply either as a comment stating which commit addressed the discussion or as a 👍 reaction on the original message.
**Auto resolve rules** decide when Baz closes a thread outright, scoped to repositories and discussion authors. One condition is always enforced and needs no configuration: Baz resolves a thread only if a later commit already addressed the comment, or if the feedback was explicitly rejected.
## FAQ
Does Merger merge pull requests on its own?
No. Merger labels the pull request, can explain its verdict in a comment, and can approve it when the rule turns on auto approve. A human, or your repository's own auto-merge, performs the merge. Failed or pending CI, open critical findings, and changes Merger reads as high impact are escalated to a human.
What is the difference between the "baz approved" label and auto approve?
The label is a marker Baz adds once all Baz findings are resolved, on repositories with no Merger rule. It does not submit a review and needs read access only. Auto approve is a switch on a Merger rule: Baz submits a real approving review when Merger decides the pull request is ready to merge, which requires write access.
Can Baz resolve a thread that was never addressed?
No. Resolution always requires either a later commit that addressed the comment or feedback that was explicitly rejected. Your rules narrow that further by repository and discussion author.
Why does Merger show no data in Insights?
Merger has to be on before the Deploy tab has anything to report. Turn it on from **Agents → Baz Agents → Deploy**.
