Your Yes Shouldn't Follow Every Rewrite

The approval covers the decision presented to the person, under the conditions they saw. It shouldn't become permission for whatever the agent eventually decides is necessary. Record the proposed outcome, the allowed action, the target system and any limit that would change the answer. Keep that record with the work.

Consider a hypothetical request to export active orders into a file kept inside the business. Permission to build that export doesn't authorize including archived orders, sending the file outside the business or changing who can download it. Those choices affect different people and data. A successful build doesn't settle them.

Gunner Technology's position is that every consequential approval needs a reset condition: an explicit description of what would make the decision stop applying. That turns a vague instruction to keep someone informed into a boundary the factory can enforce. It also lets routine work continue without asking the person to repeat an answer that hasn't changed.

A retry can reuse approval when it stays inside the authorized action and its limits, and when repeating the action is safe. Retrying means attempting an operation again after a failure. Before doing that, establish whether the earlier attempt already changed anything. A timeout can leave the outcome unknown.

In the export example, a failed local test can run again within the task's allowance. An uncertain delivery of the file to another system needs a different check: did the destination receive it? Repeating the send without resolving that question could create a duplicate. The word retry doesn't make the consequence routine.

Give the route a bounded retry policy and a way to inspect the result. Stop when it runs out of attempts, cannot establish the earlier outcome or needs broader access. As we argue in The Decision Boundary Is the Real Automation Boundary, the machinery can carry the work while a person retains authority over the consequential choice.

Approving the plan authorizes work toward the agreed result; release needs its own decision about the finished work. Keep those approvals distinct in the record. A person who agrees that an export should exist hasn't yet judged whether the implementation is right or whether its release evidence is sufficient.

For release, attach the decision to the exact revision and the evidence presented with it. A revision is a recorded version of the code. If that code changes after approval, hold the release and present the updated result. An agent shouldn't decide that its last edit was too small to matter and quietly carry the stamp forward.

This doesn't require restarting the whole conversation. Preserve the approved product direction and show what changed in the release candidate. Our post Understanding Cannot Wait for Code Review explains why the design decision belongs earlier. Keeping that decision also makes the final review smaller: the person can judge the changed result without reconstructing its purpose.

Check approval at the point where the consequential action happens, against the work that is about to run. A check made during planning can become stale before release. The release mechanism should compare the approved revision, destination and required evidence with the current request, then refuse a mismatch.

Keep the approval record outside the builder's control. The builder may propose a change and explain why it needs a new decision. It mustn't edit the old approval, substitute a different artifact or declare its own exception. The same rule should hold when the task moves to another agent: changing workers doesn't renew or widen permission.

When a condition changes, ask a precise question. Show what was approved, what is different now and what another yes would permit. Keep valid decisions intact and reopen the one that changed. A person should be judging the new consequence, not hunting through a transcript to discover why the agent stopped.

Start with a release route in a repository you own. Approve a candidate, then deliberately change its revision or destination before the release attempt. The machinery should block it and explain which condition failed. Restore the approved conditions and confirm the route can continue through its remaining checks.

Also test an allowed retry. If unchanged work still demands a fresh decision at every step, the factory hasn't preserved the approval properly. If changed work slips through, it hasn't enforced it. Both failures waste human judgment, though only the first announces itself as waiting.

People decide what gets built and whether the result is right. The factory should remember what they decided, check whether it still applies and bring back the part that needs judgment. Write the reset condition when you ask for the first yes. That's how you remove needless interruptions without letting yesterday's permission authorize tomorrow's surprise.