Branch Discipline for AI Agents
Of all the rules we enforce on our internal AI agents, the simplest one has paid off the most: no agent ever commits to main. Not on trusted repos. Not for trivial changes. Not in emergencies. The rule is absolute, and it is checked before any write operation, not after.
It is a rule we enforce more strictly on agents than we do on human engineers — because an agent that gets the branch wrong cannot be walked through a recovery the same way a person can.
Why branch discipline is different for agents
When a human engineer accidentally commits to main, the recovery is usually straightforward. They notice the mistake, revert, branch correctly, push. The damage is short-lived because the engineer is aware of the error and can explain it.
An agent that commits to the wrong branch has no such awareness. It will continue executing the rest of its task against the wrong branch. It will push the wrong branch to remote. It may open a pull request that is structurally nonsense. By the time a human reviews the output, the mistake is not one wrong commit but a session's worth of work landed in the wrong place.
Worse, an agent that has been trained to be helpful will often try to "fix" the mistake silently — cherry-picking, resetting, rewriting history — which is exactly the wrong response because it destroys the evidence of the original error. What should have been a detectable process failure becomes a confusing series of force-pushes that a reviewer now has to unwind.
The rule we actually use
Our agents operate under a simple invariant: before any write operation, verify the current branch matches the expected branch for the current ticket. If it does not match, stop and report. Do not attempt to correct. Do not commit and then switch. Stop.
This sounds paranoid for tasks where "everyone knows what branch we are on." It is not paranoid. It is the difference between a session that catches a dispatch error at the first checkpoint and a session that writes three hours of work against the wrong context and then force-pushes to try to hide it.
The rule is checked by the agent itself at every write boundary. The human dispatching the work also checks it. The CI pipeline checks it — PRs from branches that do not match their ticket key are flagged. Three layers, because the cost of a miss is high and the cost of a check is zero.
The rule we enforce on ourselves
The same rule applies to human engineers on our team, but we are more forgiving in practice because a human who gets the branch wrong will usually notice within a few minutes. For agents, we have built in the explicit check because we cannot rely on the equivalent awareness.
This is worth stating directly: a control that is optional for humans is mandatory for agents, because the failure modes are different. Treating agents as if they were simply faster engineers and applying the same discipline you apply to engineers is a category error. They fail in different ways, at different speeds, with different recovery characteristics. The controls have to match the failure mode, not the role the agent is playing.
The broader lesson
Branch discipline is a small example of a general pattern: controls that were implicit and informal for human operators have to be explicit and enforced for agent operators. The places where human judgment filled a gap in the process are the places the process has to be tightened when an agent steps into the role.
Every team adopting agents eventually finds these gaps. The question is whether they find them by reading prompts like this one or by finding them in an incident review.