Put approval in front of a production agent's irreversible boundary, not at the end of a long chain of hidden work. Define the exact action, preview its effect, require the evidence that matters, set a time and scope limit, and write the rollback or reconciliation step before the agent runs. If a reviewer cannot understand what will happen and how to undo it, the agent is not ready to act.
Approval Is Not a Button
A production agent may be able to open a pull request, change configuration, update customer records, call an external API, or initiate a deployment. Those actions do not carry the same risk. Treating them all as "human in the loop" because they share one approval button creates a false sense of control.
The useful question is not "did a human approve?" It is "what exactly did the human approve, based on which evidence, and what happens if the result is wrong?" A good gate makes those answers visible before an action crosses a boundary that is hard to reverse.
Asking for approval after the agent has already prepared a broad, opaque sequence of changes. The reviewer is then pushed to approve momentum rather than inspect a decision. Move the gate earlier and reduce the action to a reviewable unit.
Find the Irreversible Boundary
Most agent workflows have harmless preparation steps and one or two consequential steps. Reading a repository, assembling a plan, or generating a dry-run diff is usually reversible. Sending an email, deleting data, changing permissions, merging code, running a migration, or triggering a payment is not.
Put the approval gate immediately before the consequential step. The agent can gather context and prepare a proposal first, but it should not carry out the action until the gate has a narrow decision to evaluate.
| Action type | Useful agent behavior before approval | Gate decision |
|---|---|---|
| Code or configuration change | Produce a scoped diff, tests, and affected services. | Approve the exact diff and rollout condition. |
| Data mutation | Show a dry-run count, sample records, invariant checks, and recovery plan. | Approve the bounded batch and reconciliation path. |
| External side effect | Preview recipients, payload, idempotency key, and cancellation window. | Approve one send, request, or controlled batch. |
| Deployment or rollout | Show version, target, health checks, and disable switch. | Approve the release scope and rollback trigger. |
The Five Parts of an Approval Packet
Make every production approval look roughly the same. Consistency makes gaps obvious and keeps a reviewer from having to rediscover what matters for each new tool.
State one outcome, the systems affected, and explicit non-goals. "Fix the invoice retry job" is not enough; name the job, the failure mode, the files or records in scope, and what the agent must not touch.
Show the diff, dry run, sample, test result, or request payload that lets the reviewer evaluate the proposed action. A prose summary helps, but it cannot replace the concrete artifact that will drive the change.
Bind the approval to a small scope: a commit hash, a record query, a deployment version, a maximum batch size, or an expiry time. An approval that remains valid after the underlying plan changes is an authorization bug.
Name the success signal and the negative signal. That can be a focused test, an invariant query, a health check, a metric, or a manual path. "Monitor it" is not a verification plan.
Document the first recovery move before execution: disable a flag, revert a version, cancel a queued request, restore a snapshot, or run a compensating operation. When a true rollback is impossible, say so and require a reconciliation plan instead.
Use a Gate That Can Expire
An agent plan can become stale quickly. A new commit lands, input data changes, a feature flag is flipped, or another operator starts the same task. Do not allow a reviewer to approve a plan once and let the agent execute it later against changed state.
Tie the approval to a specific version of the evidence and give it a short validity period. If the diff, target set, or environment changes, invalidate the approval and ask the agent to prepare a new packet. This is not bureaucracy; it prevents a correct decision from being applied to a different action.
An approval should identify a target, an evidence version, a maximum scope, and an expiry. Missing any one of those means the agent has room to turn a narrow decision into a broader action.
A Copy-Paste Approval Record
Keep the record near the code or operational runbook. It should be short enough to use under pressure and specific enough that someone else can reconstruct why the action was allowed.
## Production Agent Approval
Action: <one concrete action>
Target: <service, environment, record set, or release>
Evidence version: <commit, dry-run ID, payload hash, or timestamp>
Scope limit: <maximum files, records, recipients, or rollout percentage>
Expires: <time and timezone>
Required evidence:
- [ ] Expected before/after behavior is stated
- [ ] Preview or dry run matches the requested scope
- [ ] Focused validation passed or is named
- [ ] Owner is named for the first verification window
Recovery:
- Disable or stop step: <flag, queue, job, or version>
- Rollback or reconciliation step: <exact command or runbook link>
- Escalate when: <specific failure signal>
Decision: approve / reject / request revision
Reviewer and time: <name, timestamp>The record is deliberately not a generic "agent completed task" log. It captures the decision before the side effect, while the reviewer can still narrow scope or reject the plan.
Design Recovery Before You Need It
A rollback plan is more than a command that reverses a deploy. Production agents often touch systems where the state has moved on: a customer may have acted on an email, a worker may have processed a message, or another service may have read the changed data. In those cases, the right recovery is a compensating action plus a review of what happened.
- Disable first. Stop the agent from creating more side effects before investigating the ones already made.
- Preserve evidence. Keep the approval packet, request IDs, changed-record list, and validation output so recovery is based on facts.
- Reverse only what is known. Revert a bounded version or batch; do not ask an agent to "undo everything" without a verified target set.
- Reconcile external state. Check downstream systems, notifications, and customer-visible effects when a technical rollback cannot make them disappear.
- Turn the failure into a new gate. Add the missing invariant, preview, or stop condition before authorizing the next run.
When an agent has already made an unexpected production change, do not give it an open-ended instruction to repair the system. Freeze new actions, establish the changed boundary, and approve a small recovery plan exactly as you would for the original action.
When the Correct Answer Is No
Some work should stay advisory until the system has better controls. Reject automation when the agent cannot produce a reliable preview, the target set is unknown, the recovery path is untested, or the action combines several independent risks into one approval.
That is not a failure to adopt agents. It is how you keep an agent useful while the surrounding system becomes observable enough to automate safely. Start with read-only analysis or a reversible staging action, then widen authority only after the evidence and recovery loop are real.
Use The AI Change Budget to decide how much work an agent may take on at once, AI Merge Readiness Checklist for pre-merge evidence, and Run a Model Fallback Drill to rehearse recovery when a model path fails.