KeelenAnswer · trust and control
Is there an AI coding agent that waits for my approval to merge?
Updated 2 October 2026
Yes. The pattern has a name: an approval gate with a human in the loop. Cloud coding agents usually stop at a pull request. A person takes the last step. How firmly that holds varies by product. Some vendors say their agent cannot approve or merge its own pull request. Others expect you to enforce it yourself. So rely on your own branch protection. A rule on the branch binds every author the same way, person or machine. Keelen treats the gate as a setting for each project. You can require plan approval before any code is written, merge by hand, or push a branch and open nothing. Or you can allow gated auto-merge after five verification gates pass.
Decide this per project. One answer does not fit both cases. A prototype rarely needs the same gate as a payments repository.
What to do, in order
Decide what the gate is actually protecting
Approval costs attention. Spend it where a mistake costs more. Money, user data, login details and access rules deserve a human. So do records that get deleted or moved. A copy change on a marketing page often does not.
Turn on branch protection, whatever agent you use
Protect the branch you plan to ship to. Require a pull request and the checks that really run. Check who can bypass those rules. GitHub admin and bypass settings decide whom the rules bind.
Require the checks that actually run your tests
A required status check makes a red build block the merge button. Without it, a build only turns the button red. Then an approval gate only measures who clicked. It says nothing about whether the code works.
Require a review, and decide whose
A required review turns approval into a rule. If you are the only reviewer, say so and plan the time. A gate nobody has time to run becomes a queue.
Then choose how much the agent may do on its own
Once the branch is protected, the agent's autonomy setting is a convenience. It is no longer the boundary that keeps you safe. Move it up or down per project as your confidence changes. Keep the branch rules where they are.
What a human-in-the-loop approval gate is
It is a control that stops generated code from reaching your main branch until a person approves it. The boundary is the merge. The agent stays free to plan, write, and push to a branch. A human decides whether that work lands. Deployment is a separate step. Merging to the default branch does not by itself show what users are running.
Do not rely on the vendor's promise, rely on the branch rule
Products differ in how they handle the merge boundary. For some it is a fixed property of the agent. For others it is a default you can switch off. Others expect you to arrange it yourself. Some say in their docs that the agent cannot approve or merge its own work. Others say the opposite for related actions. Some say nothing at all. Two things follow. Check the vendor's own current docs instead of a comparison article, because these designs change often. Put the guarantee where you control it, on the branch. Then changing tools later does not quietly change what is enforced.
On Keelen the gate is a setting
Autonomy is a setting you pick for each project. Plan review makes a human approve the plan before any code is written. Manual merge means Keelen opens the pull request and you click merge. Branch-only means it pushes a branch and never opens a pull request at all. Pause one project or the whole fleet whenever you want the keyboard back. For one change, pick manual merge in the project's merge policy. Do that before you submit the Request. Check the PR's exact revision and its checks. Look at any failed or skipped checks. Then check the expected behavior before you merge it.
Check the repository's enforcement settings
Look at the required checks and required reviews. Check the admin behavior and the bypass permissions for the branch you plan to protect. GitHub's own docs describe how these rules apply.
What stands in front of an auto-merge
A separate adversarial reviewer reads the diff. It does not see the conversation that wrote the code. The review model comes from your project settings. Red first proof and clean checkout tests need a verified project test command. Gated auto-merge needs the repository checks and a review window you set up. Plan review, manual merge, and branch-only mode each pick where a person must decide. Check the real evidence before you accept the result.
What the test checks can catch
Fail first and clean checkout tests need a verified project test command. Gated auto-merge needs the repository's required checks to be set up. The red first proof gate applies new tests without the code change. They must fail first. Tests that pass at that point are rejected. When the assertion guards are on and can check a change, they block detected net removal of assertions. They also block deletion of existing test files that contain detected assertions. They can detect smaller expected sets or lowered numeric floors. They can also detect contentless matchers and newly disabled tests. Each guard has a supported scope. Supported exceptions can let those changes through.
What still needs a person
Declared exceptions use an Assertion-removal: or Assertion-relaxation: commit trailer with a reason. The agent can add these trailers itself. The gates do not check human approval. The guards can be turned off. They can skip a check if the comparison base is missing or the Git diff fails. Some changes and patterns fall outside detection. A passing or skipped guard does not prove that no checks were weakened. The tests and code still need human review. With manual merge, Keelen opens the PR and you click merge.
When Keelen is not the answer
- You want an assistant that suggests code while you type. That is an editor tool, and the merge question does not arise there.
- You want nothing autonomous to touch the repository. Even a branch you never merge is too much. No setting can do that. The one answer left is to not connect it.
- You want a system that ships with no human in the path and no gate of any kind. Keelen can auto-merge, but only behind verification gates. So it will hold work back instead of forcing it through.
Hand the work to a loop
Connect a repository and write what you want in plain language. Review the tested pull requests that come back.
FAQ
How do I stop my AI agent from changing or deleting tests?
Fail first and clean checkout tests need a verified project test command. Gated auto-merge needs the repository's required checks to be set up. The red first proof gate checks that new tests fail without the code change. Tests that pass at that point are rejected. When the assertion guards are on and can check the change, they block detected assertion removal or weakening within their supported scope. Supported exceptions can let changes through. The agent can declare an exception itself. That does not prove human approval. Guards can be turned off or skip checks when inputs are missing. They do not catch every way a test can lose meaning. The tests and code still need human review. Manual merge keeps the merge click with you.
What is a human-in-the-loop approval gate?
It is a checkpoint where an autonomous agent pauses. It waits for a person to confirm before it takes an action. For coding agents the checkpoint that matters most is the merge. The agent may plan, write, and open a pull request on its own. A human decides whether that work reaches the main branch. People also call it a code generation review gate.
Can an AI coding agent merge its own pull request?
Some can, if you set them up that way. The safer approach is to let your repository decide. With branch protection and a required review on the default branch, nothing merges without the approval you set. That holds no matter who or what opened the pull request.
Is branch protection enough on its own?
It is the enforcement, but it is not the judgement. Branch protection guarantees that somebody approved and that the required checks were green. It cannot tell you whether the tests were any good. Pair it with tests that fail before a change and pass after it, and with a review that did not come from the author.
Can I set different approval levels for different projects?
On Keelen, yes. Autonomy is set for each project. One repository can require you to approve the plan before any code is written. Another can allow gated auto-merge. You can also pause one project, or every project, at any time.