---
title: "One Approval Whole Operation"
canonical: https://dxdev.com/blog/2026-04-30_one-approval-whole-operation/
datePublished: 2026-04-30
---
A ten-step plan that had already been approved once turned into ten separate stalls, because the agent re-asked before every sub-step: cut branch, ask, run tests, ask, push, ask. Each pause technically honored the sign off, yet none of them carried any information, since the human had read every one of those steps in the plan and already said yes.

Every big batch job here runs behind an approval gate. I write the plan, list every sub-step, and get a sign off once. That is the contract. But for a long time, the agent kept re-asking. Cut branch, ask. Run tests, ask. Push, ask. Each step technically respected the approval, but the effect was death by a thousand checkpoints. A ten-step plan turned into ten separate moments where the whole operation stalled waiting on a human who had already said yes.

## The rule that fixed it

The fix was one line, not a redesign: once a multi-gate plan is approved, run all of it. Stop only on genuine surprises. Not "stop and confirm before each sub-step," not "check in after the risky part." Run the whole approved scope end to end, and only break that stride when something happens that the plan did not account for.

That distinction matters more than it sounds. A surprise is a merge conflict nobody predicted, a test that fails for a reason outside the plan, a step that turns out to depend on a credential nobody flagged. Those deserve a stop. A branch getting cut cleanly, a test suite passing, a commit landing where the plan said it would land, those are not surprises. Those are the plan working. Re-confirming a step that went exactly as described is not caution, it is noise, and it trains the human to stop reading the confirmations closely, which defeats the point of having them.

## Why this took actual tuning

Getting the boundary right is harder than it looks from the outside. Too loose, and the agent barrels through a step that quietly diverged from what was approved, and now you find out after the fact instead of at the moment it happened. Too tight, and you are back to the original problem: an approval that does not actually buy you an unattended operation, just a slightly longer leash.

The working line ended up being scope, not risk. If a step is inside what was described in the approved plan, it runs without a pause, no matter how consequential that step is. A production push is not automatically a stop point if the plan already said "push to production" and got a yes. What forces a stop is anything outside the described scope. New information, an unplanned branch in the logic, a step nobody wrote down. The gate is about whether this was covered, not about how scary the step feels in isolation.

## What changed once it stuck

Once that rule was actually followed instead of just stated, multi-step operations stopped feeling like a chat where you have to keep the other person company. You approve the plan, you walk away, and you come back to either a finished operation or a specific, concrete question about the one thing that did not match the plan. No status pings in between. No "should I continue" on step 4 of 10 when step 4 was explicitly in the plan you already read.

Step 4 of 10 was in the plan the human had already read, and that is the whole point of the rule: the approved scope is the boundary, so a branch cut cleanly, a passing test suite, or a commit landing where the plan said it would never earns a second question. The one thing worth interrupting for is the thing nobody wrote down, like the unpredicted merge conflict or the credential no one flagged. When the agent runs the approved steps without a ping and then comes back with a single question about the one step that diverged, that question is the only confirmation in the whole operation that carries any information, and the human reads it closely because it is the only one they received.