One Line in the Rules Ended a Thousand Small Checkpoints

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. 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. We write the plan, list every sub-step, and get a sign off once. That is the contract. For a long time the agent kept re-asking anyway, and the effect was a thousand small checkpoints. The whole operation stalled ten times, waiting on a human who had said yes before the first step ran.

The one-line rule

The fix was a single line and no redesign: once a multi-gate plan is approved, run all of it. Stop only on surprises. The rule never says to stop and confirm before each sub-step, or to check in after the risky part. The agent runs the whole approved scope end to end and breaks stride only 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, or 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, or a commit landing where the plan said it would land are not surprises. Those are the plan working. Re-confirming a step that went exactly as described is noise, and it trains the human to stop reading the confirmations closely, which defeats the point of having them.

Where the boundary sits

Getting the boundary right is harder than it looks from the outside. Too loose, and the agent barrels through a step that diverged from what was approved, and 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 buy 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 it 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 asks whether this was covered, whatever the step feels like in isolation.

What changed once it stuck

Once the rule was 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. There are no status pings in between, and no request to continue on step 4 of 10 when step 4 was explicitly in the plan you already read.

That single question is the only confirmation in the whole operation that carries any information. The human reads it closely, because it is the only one they received.

If your automation re-confirms steps that were already in an approved plan, you are paying for approvals that do not buy unattended work, and people will learn to skim the prompts. Define the gate by scope: run everything the plan described, and stop only for something it did not cover.

dxdev LESSON · paste into your AI coding agent
LESSON: An approval that re-asks at every step is not an approval, it is a slower way to do the same manual work
SOURCE: dxdev.com/blog/one-approval-whole-operation
WHAT HAPPENED: A multi-step approved plan kept stopping to re-confirm at each individual sub-step (cut branch then ask, run tests then ask, push then ask), even though every step was already inside the approved scope. A one-time sign-off turned into death by a thousand checkpoints. The fix was one rule: once a multi-gate plan is approved, run the entire approved scope end to end and stop only for surprises, meaning things outside what the plan described, and not for steps that are consequential but were already covered by the approval.
THE RULE: The boundary for stopping an autonomous multi-step operation should be scope (was this covered by what was approved), not risk (how scary does this step feel in isolation). Re-confirming a step that matches the approved plan exactly is noise that trains the human to stop reading confirmations closely.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any multi-step automated or agent workflow that pauses for re-confirmation on a step explicitly covered by an already-approved plan, rather than only pausing for out-of-scope surprises.
  2. Any approval-gate design that conflates consequential with requires-a-fresh-confirmation, instead of using scope-coverage as the actual criterion for stopping.
  3. Any operation resumed after a stop with no clear, specific statement of exactly what deviated from the approved plan, versus a generic should-I-continue prompt.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.