Your AI agent should not have merge rights

The industry spent 2026 racing toward the same demo. An agent picks up a failing build, diagnoses it, writes the fix, and ships it. The pipeline goes green. Nobody is in the room.

This is not a hypothetical. GitLab's Duo Agent Platform reached general availability in January with a fix pipeline flow that diagnoses and repairs CI/CD failures automatically. Harness ships an autofix agent. The direction of travel across the category is clear, and it is toward removing the person.

We build the opposite, and not for the sentimental reason people assume. The argument is not that AI writes bad code, or that engineers need protecting from obsolescence. The argument is narrower and, we think, harder to get around.

The merge is not a competence boundary. It is an accountability boundary.

Ask what the approval step is actually for.

It is not there because the reviewer reads every line. Anyone who has approved a four hundred line pull request at 5pm on a Friday knows better. It is not there because the human is a better programmer than the model. Increasingly, on mechanical work, they are not.

It is there because afterwards, someone has to be able to say I approved this.

That sentence has to survive an incident review, a SOC 2 audit, a regulator asking who authorized a change to a system holding cardholder data. It is a claim about responsibility, and responsibility requires a party who can be held to it. An agent cannot be held to anything. It has no license to lose, no performance review, no obligation that outlasts the session.

So when a vendor removes the approval step, they have not automated a bottleneck. They have deleted the only part of the process that was load bearing for accountability, and left the part that was mostly ceremony.

This is why we say the constraint is not a limitation. Everything upstream of the merge is genuinely delegable, and we delegate all of it. The agents read the repository, detect the stack, write the CI workflows, the Dockerfiles, the Helm charts, the Argo manifests. They argue with each other about it. What they cannot do is sign for it.

Delegated to the crew

All of it.

• ✓Read the repository and detect the stack
• ✓Write the CI workflows
• ✓Write the Dockerfiles
• ✓Write the Helm charts
• ✓Write the Argo manifests
• ✓Check every proposal against the rules in force
• ✓Argue with each other about all of it
• ✓Open the pull request

Never delegated

One thing.

✗Sign for it

An agent has no licence to lose, no performance review, and no obligation that outlasts the session. Responsibility requires a party who can be held to it.

The column on the left is long on purpose. Every part of delivery that can be delegated, we delegate. The reserved item is not the hardest work on the page — it is the only one that has to survive an incident review.

“But a human approving is just a rubber stamp”

It is, when the human is the only control.

A reviewer who must personally catch every unpinned base image, every missing scan, every service that quietly acquired a public ingress, is a reviewer who will miss things. Not sometimes. Systematically, at the volume agents now produce.

The shape of the problem makes it worse. In Veracode's Spring 2026 benchmark, syntax correctness for AI-generated code exceeded 95%, while only about 55% of generation tasks produced secure code. Sit with that gap for a second. The code compiles. It reads naturally. It passes the smell test. And roughly half the time it carries a known security flaw anyway.

That is the exact failure mode human review is worst at, because nothing about it looks wrong. You cannot fix it by asking people to read harder.

The answer is not to remove the human. It is to stop spending the human on work a machine does better.

That is what the policy layer is for. Before a proposal reaches a person, it is checked against a signed Rego bundle we call the constitution: the universal rules every proposal must respect, versioned, tested, and cosign signed. On top of that sit packs, and on top of those sit the customer's own overlay rules, written by their architects and SREs. Each layer can only ratchet stricter than the one above it. A rule that tries to loosen a baseline requirement does not get quietly applied. It fails to compile, and a linter says so.

By the time a human sees the pull request, the mechanical questions are already answered. What is left is judgment: does this change make sense for this system, this quarter, this team. That is the thing the person is uniquely good at, and it is the thing the approval was always supposed to be about.

Agents propose. Policy decides. Humans approve. The middle step is what makes the third one meaningful instead of ceremonial.

The market is arriving at this from the other direction

The interesting thing about holding this position in 2026 is that we are no longer alone in it, even among people who started somewhere else.

The guidance now circulating in agentic development is to start agents in assisted mode and promote them through performance gates, to embed enforceable controls directly into the development workflow, and to treat AI coding agents as part of the software supply chain. Berkeley's California Management Review has an entire operating model for governing the agentic enterprise. Read those recommendations closely and they describe a signed, layered, non waivable policy artifact sitting between the agent and production, with a person at the far end.

That is a description of the thing we ship, arrived at independently, by people who were not trying to justify a product decision.

Which suggests the autonomous merge is not the industry's considered position. It is the demo that shows best on stage.

What this costs, honestly

It costs the screenshot. There is no version of our product where you close your laptop and things deploy themselves, and we are not going to build one, because the moment we do we have sold you a system whose audit story is "the vendor's model decided."

What it does not cost is speed, which is the objection we hear most and the one that holds up least. The agents do the drafting, all of it. The policy check runs in seconds and runs on every proposal, not on the ones a reviewer happened to look at closely. The human step is an approval on a pull request that arrives already correct on every mechanical dimension. That is not the slow path. The slow path is the change advisory board you are running today because nobody trusts the pipeline.

Git push. Go home. The merge button is still yours.

The question to ask a vendor

If you are evaluating anything in this category, the useful question is not whether their agents are good. They probably are, and they are all converging on similar model quality anyway.

Ask instead:

• When your agent ships a change, who is accountable? If the answer routes back to a model, or to a configuration setting, that is your answer.
• Can a team weaken a control to get their change through? If policy lives as a setting in the vendor's console rather than as a versioned artifact you can read, the honest answer is yes, quietly, and you will find out during the audit.
• Can you produce the exact rules that were in force on the day of a given merge? If the rules are a prompt, or a toggle, you cannot.

We think those three questions matter more than any benchmark, and we would rather be measured on them.

Your AI agents do not get merge rights. That is not a limitation. It is the product.