AATB: our agent merges its own pull requests

Part 2 of 5 in a series on autonomous software delivery. Part 1 introduced Ralph, our autonomous development agent. This part covers AATB, the delivery flow that lets an agent ship to a shared environment safely. Part 3 covers how it tests.

Here is a sentence that makes most engineering leads flinch: our AI agent opens a pull request, waits for CI, and then merges it. Itself. Nobody reviews the diff first. The branch protection on that repository literally requires zero approvals.

We did this on purpose, we would do it again, and by the end of this post I hope you will at least see why it is not madness. We call the flow AATB: Aggressive Autonomous Trunk-Based delivery.

The queue problem

Start with the naive setup everyone tries first. The agent implements a feature, opens a PR, and a human reviews it before merge. Safe, familiar, comfortable. But it’s not sustainable for an AI future where agents will be the better engineers eventually.

An agent produces changes faster than any team reviews them. Within a week you have a queue of agent PRs waiting for human eyes, each one a wall of diff produced by something that types faster than you read. Reviewers skim, approve on vibes, and the “human gate” degrades into theater. You have not added safety. You have added latency and a false sense of it.

There is a deeper problem than the queue. A diff is useful for understanding how a change was implemented, but it is not sufficient for product acceptance. The question a product owner ultimately needs answered is: does the running feature do what I asked? Answering that requires evaluating the deployed application, not only reading the code.

So AATB moves the human gate to where that question is answerable: after integration, against the running feature. The ultimate test.

The flow

1. The agent implements on a feature branch off dev (our integration branch, the trunk in this story), opens a PR, and merges it itself once CI is green. As a merge commit, not a squash. That detail matters in a minute.
2. CI auto-deploys dev to the integration environment.
3. The agent assembles evidence that the deployed feature satisfies the request. This is not a dump of test output; it connects the acceptance criteria to what was tested and observed, with screenshots where the surface matters.
4. The human evaluates the running feature, using that evidence to focus the review. Approval is an action on the work item, not a click on a merge button.
5. If the human rejects the feature, the agent creates and merges a revert PR, and the auto-deploy removes the feature from the environment. The item goes back to the backlog. Done.

The PR does not disappear from this story. It changes role. It stops being a gate and becomes a record: every change in and out of dev is a merged PR with CI evidence attached. Full audit trail, zero bottleneck. Nothing merges unseen; it merges un-waited-for.

That evidence is not a decorative test report, and AATB does not work without it. Before Ralph can merge, it must demonstrate that it tested the behavior it changed and record what it actually observed. ARBT gives Ralph explicit rules for deriving tests, gathering evidence, and resisting the temptation to quietly narrow a test until it passes. Part 3 covers how those rules work. For now, the important point is that self-merge sits inside a larger system: Ralph follows a disciplined testing process, the repository blocks unsafe delivery paths, and a human evaluates the running result.

Reversibility beats gatekeeping

The whole flow stands on one boring Git mechanic: a merge commit makes the revert a one-liner. Revert the merge commit and the entire feature, however many commits it took, comes out as one clean change. Most repository platforms already provide a PR revert mechanism, and we trust the agent to revert its own work when a feature is rejected.

That changes the economics of a mistake. In a traditional workflow, every human mistake that slips past the gate tends to produce stricter gates, slowing delivery for everything that follows. In AATB, a bad change costs one comment and one CI cycle to remove. When undoing is that cheap, there is less need to predict every problem before integration.

It also holds up with several features in flight: merge commits revert independently, so five items on the board can be in five states of approval without blocking each other. One genuinely interesting edge exists: if feature B built on top of rejected feature A, the revert conflicts. Ralph does not guess its way through that. It reports the conflict on the work item and hands the decision to a human, because untangling intent is exactly what humans are still for.

In Guardrails We Trust

Zero required approvals does not mean zero protection. It means the protection moved into mechanisms that do not require human intervention:

• Pull requests only. Nobody pushes directly to the integration branch. Not the agent, not humans. Every change has a PR-shaped paper trail.
• Required status checks. CI must be green before any merge, so the agent cannot land a red build on the shared environment. The machine gate stays; only the human gate moved.
• No force pushes, no branch deletion. History is append-only, which keeps the revert trick trustworthy.

Next to these hard policies, ARBT governs how Ralph exercises judgment: what to test, when a skip is justified, and what evidence must be shown. More on ARBT in the next post.

A human gate remains at release. dev is the integration branch, never production. Promotion to main is a release-train PR carrying the accumulated, human-approved state of dev, opened and merged by humans as a release decision. The agent always delivers to the integration branch. Production remains a human act in our case.

The alternative we rejected

We seriously considered the pattern the Git project itself uses for its next branch: keep every feature PR open against dev as the approval gate, and maintain a second integration branch where all in-flight features are combined and deployed for evaluation. It preserves the comfortable merge-button-as-approval feeling, and we wanted to like it.

It fails because it creates a second integration path beside the one the team already has. Now dev is nominally the integration branch, but another branch holds the state people actually evaluate. Which one is deployed, which one is authoritative, and what exactly has been integrated? These questions become more confusing than helpful. The simpler model is for Ralph to act like any other developer: branch from the existing integration branch, merge back into it, and let the environment reflect that shared state.

There is also a legitimate advanced variant of AATB for a different shape of project: per-feature preview deployments, approve-before-merge, for stateless user-facing apps where several stakeholders review in parallel and features make sense in isolation. It costs per-branch infrastructure and moves integration surprises to the merge moment. We run it where it fits. But every project starts on the simple flow, and the simple flow is the default for a reason: it is one environment, zero extra branches, and an audit trail made entirely of merged PRs.

What this actually bought us

The honest summary of AATB is a trade: we gave up pre-merge human review of diffs nobody was going to read carefully anyway, and got back a delivery loop where a one-sentence work-item comment turns into a deployed, evaluatable, reversible feature in under an hour, with a paper trail better than most human teams produce.

The human attention that used to be spread thin across diffs is now concentrated where it discriminates: on the running feature, with evidence in hand. But AATB only works on top of a robust test strategy: the agent must decide what to test, disclose what it skipped, and produce evidence a human can verify. Our answer is Part 3: ARBT.

The agents write the code. Engineering the loop is the job now.

Ralph is built at Rubicon, part of BBTG. AATB and ARBT are our working answers, not industry standards. Yet.