How to know when an autonomous merge agent is working

Handing merge decisions to an agent is a harder sell than handing it review comments. A wrong review comment gets ignored. A wrong merge decision ships. So the question every team piloting Merger asks first is not "can it merge PRs," it's "how do we know it's making good calls before we let it make more of them."

Merger Agent Stats is the answer: a dashboard for Merger's track record, not just its existence.

What Merger actually does

Merger evaluates open pull requests for merge readiness and returns one of three verdicts: merge, reject, or escalate. It checks CI state, unresolved Baz findings, PR metadata, diff context, repo impact, git history, auto-approve rules, and org guidelines before deciding. Merger escalates to a human whenever a PR has failed or pending CI, open critical issues, or risk it identifies as high impact, rather than guessing its way to a merge.

That escalation behavior is the safety mechanism. But a safety mechanism you can't measure is just a claim, and claims are not what gets a merge agent trusted with more of the queue.

The metrics that make trust measurable

Evaluated PRs. The volume of pull requests Merger has actually assessed in a given window. This is the denominator for everything else, and it is worth watching on its own: a low number relative to your total PR volume means Merger is not yet in the loop for most of your traffic.

Ready-to-merge rate. The share of evaluated PRs Merger judged safe to merge. Tracked over time, this tells you whether Merger's confidence is stable, rising as it gets more signal from your repos, or dropping in a way that might indicate noisier CI or a shift in what is coming through the queue.

Merged without human input. The share of PRs Merger merged entirely on its own. This is the number that answers "how much manual merge work is actually gone," as opposed to how much Merger merely flagged as ready.

Merge outcome breakdown. How evaluated PRs split across merged, rejected, and escalated. A team that expects Merger to reduce a stale-PR backlog wants to see this shift toward merged over time, and wants to understand where rejections and escalations are concentrated, whether that is a specific repository, a type of change, or a recurring CI flake.

PR throughput. Volume moving through Merger over time, which shows whether the backlog Merger was meant to clear is actually shrinking.

Reading the dashboard as a pilot

If you are piloting Merger, the useful sequence is to watch evaluated PRs and outcome breakdown first, confirm escalations are landing on the PRs you would also have flagged by hand, and only then start paying attention to the merged-without-human-input rate as the number that represents real time saved. Trusting the last number before validating the first two is how teams end up either over-trusting or under-trusting automation that is actually working as designed.

For eng leadership and platform teams evaluating whether an autonomous merge agent belongs in their workflow, Merger Agent Stats is built to answer that with data pulled from your own repositories, not a vendor claim.