An agent should open a pull request, not merge one

The question comes up in every evaluation: if the change is proved, the tests pass and the diff is small, why does a person have to merge it? The honest answer is not that the agent is untrustworthy. It is that the merge is the only point in the process where the organisation's existing controls apply, and giving it up costs far more than it saves.

What the merge gate already enforces

• Branch protection, required reviewers and code owners — rules the team already agreed to.
• CI that runs on the organisation's own infrastructure, with its own secrets.
• An audit trail in the system auditors already examine, attributing the change to a named person.
• The ability to revert through a path everybody already knows.

An agent that merges bypasses all four, and has to recreate each of them, worse, inside itself. That is a large amount of engineering spent on removing a step that takes a competent reviewer two minutes.

The asymmetry of being wrong

Automated review saves minutes per change. An automated bad merge into a nightly pipeline costs a day, plus the far more expensive loss of the team's willingness to leave the thing switched on. The expected value is not close, and it does not become close as the model improves, because the saving stays small and the downside does not shrink.

Where the real speed comes from

Not from removing the human, but from making their two minutes sufficient: the diff, the diagnosis, the test output and the queries that were run, on one screen, with no second system to open. Most review time is not spent deciding — it is spent reconstructing enough context to decide. Remove that and you have the speed you were trying to buy, without the gate.