Approval gates are a systems primitive, not a button
The engineering behind approval gates: suspension, evidence, expiry, revalidation, revocation, and safe continuation.
Key takeaways
- An approval must bind one decision to a specific proposal, evidence set, policy version, and expiry.
- Waiting work should release compute and credentials while preserving enough durable state to resume safely.
- Approval improves user experience when it explains consequence, changed assumptions, and the exact next action.
An AI agent approval gate is a durable execution boundary, not a button inserted into an otherwise autonomous workflow.
The button is the least interesting part. The system has to freeze an exact proposal, preserve the evidence and policy that produced it, release resources while it waits, accept a decision from an authorized person, detect whether reality changed, consume the approval once, and resume without repeating earlier effects.
If any of those semantics are missing, “human in the loop” becomes a visual reassurance rather than an enforceable control.
We have previously written about designing human checkpoints from a product perspective. This article goes underneath the interaction and treats approval as a protocol between a running agent, a human authority, and a changing external world.
Separate proposal from effect
The most important boundary is between preparing an action and committing it.
An agent may read data, calculate options, assemble evidence, and draft a payload before approval. It must not perform the protected external effect until the approval record authorizes that exact payload.
Diagram 1: approval as a state machine
Approval is a versioned state transition between a prepared proposal and a protected external effect.
┌──────────────┐ propose ┌───────────────────┐
│ PREPARING ├───────────────►│ AWAITING_APPROVAL │
└──────┬───────┘ └──┬──────┬──────┬──┘
│ │ │ │
│ failure approve reject expire/revoke
▼ │ │ │
┌──────────────┐ ▼ ▼ ▼
│ FAILED │ ┌─────────┐ ┌────────┐
└──────────────┘ │APPROVED │ │ CLOSED │
└────┬────┘ └────────┘
│ revalidate
┌────────┴─────────┐
│ │
valid stale
│ │
▼ ▼
┌──────────┐ ┌─────────────┐
│EXECUTING │ │ REPREPARE │
└────┬─────┘ └─────────────┘
▼
┌──────────┐
│ VERIFIED │
└──────────┘The user should see these distinctions. “Waiting for approval,” “approved and queued,” “refreshing because the invoice changed,” and “executed” are different states with different consequences. Collapsing them into a green check creates false confidence.
Bind the decision to a decision packet
An approval that stores only a yes-or-no flag is dangerously under-specified. What was approved?
A decision packet should contain:
- a stable approval identifier tied to one work item;
- the requester, executing agent, and authority required from the approver;
- the normalized action type and the exact resource version it would affect;
- digests of the proposed payload and evidence set;
- the policy version and reason that caused the gate;
- a plain-language explanation of consequence;
- creation and expiration times;
- a lifecycle state such as pending, approved, rejected, expired, revoked, or consumed.
The payload and evidence digests bind the human’s decision to what was shown. The readable explanation is not a substitute for the structured action; it is a projection of it.
Keeping these elements separate also improves review. The interface can summarize the action for a business user while the platform retains stable identifiers for concurrency checks, audit reconstruction, and exact matching at execution time. Both views describe the same decision packet.
For a payment, the interface might show:
- pay ₹485,000 to Vendor V-1187;
- against invoice I-991 and purchase order PO-441;
- bank account ending 2048;
- two-way match passed, tax discrepancy flagged;
- required because the amount exceeds the autonomous threshold;
- approval expires at 18:00.
That is a decision, not a generic prompt to “continue.”
Suspend work without suspending a process
Human decisions may take minutes or days. Keeping a worker, model session, database transaction, or broad credential alive while waiting is expensive and unsafe.
The run should commit a checkpoint and terminate. Approval later schedules a new continuation.
Diagram 2: durable suspension and resumption
The decision survives process termination because the checkpoint and approval are durable platform records.
Agent worker Durable stores Approver
│ │ │
│ prepare proposal │ │
│ append ApprovalRequested │ │
├──────────────────────────────►│ │
│ save checkpoint C-17 │ │
├──────────────────────────────►│ │
│ release tool credentials │ │
│ terminate │──── notification ────────►│
X │ │
│◄──── decision + version ──┤
│ commit ApprovalGranted │
│ enqueue continuation C-17 │
▼
New agent worker
│ reload + revalidate
│ execute or reprepareThis design has a direct user benefit: approval queues can survive deploys, outages, and long delays. The user does not need to keep a tab open, and the system does not lose context when the original runtime disappears.
The continuation path should be deliberately defensive.
- Load the approval, current work state, and durable checkpoint independently of the worker that prepared them.
- Confirm that the approval is still approved, unexpired, and attached to the expected work version.
- Recheck that the approver still holds the required authority and that the agent remains authorized.
- Compare the current resource, proposal, evidence, and policy with the versions bound to the decision.
- If a material fact changed, expire the decision and schedule preparation of a fresh proposal.
- If the decision remains valid, consume it and authorize the protected action in one atomic transition.
Approval consumption should be atomic with the transition that authorizes execution. Otherwise two workers can observe the same approved record and both proceed.
The user experience follows directly from this protocol. A valid decision resumes without asking the person to repeat work. A stale decision produces a precise explanation and a refreshed review request. A duplicate click reports that the approval was already consumed rather than creating a second execution.
Revalidate what can change
The world does not pause with the workflow. A vendor may update bank details. A purchase order may be cancelled. The approver may change roles. A policy threshold may be lowered. The user may revoke the agent.
Diagram 3: the freshness barrier
Execution proceeds only when the facts and authority bound to the approval remain materially valid.
At proposal time At execution time
┌────────────────────┐ ┌────────────────────┐
│ Resource version 8 │──────────────►│ Resource version 9 │ changed?
│ Payload digest P1 │──────────────►│ Payload digest P1 │ same?
│ Evidence digest E4 │──────────────►│ Evidence digest E5 │ changed?
│ Policy version 12 │──────────────►│ Policy version 13 │ stricter?
│ Agent active │──────────────►│ Agent suspended │ revoked?
│ Approver role=AP │──────────────►│ Approver role=AP │ valid?
└────────────────────┘ └──────────┬─────────┘
│
┌───────────────────┴──────────────────┐
▼ ▼
safe to execute reprepare / reapproveNot every change invalidates a decision. Updating an unrelated note should not force reapproval. Changing amount, recipient, destination, contractual term, risk classification, or evidence quality usually should.
This requires domain-aware freshness rules. A generic “any row changed” check creates unnecessary friction; no check creates unsafe approvals. The architecture should identify the fields on which the decision depends.
The interface must then explain the result: “A new bank account was added after you approved this payment, so the approval was cancelled.” Clear explanation turns a safety interruption into understandable behaviour.
Design for more than approve and reject
Real decisions have richer outcomes:
- approve as proposed;
- reject with a reason;
- request more evidence;
- revise a bounded field;
- delegate to another authorized person;
- approve once;
- approve a recurring policy exception until a date.
Each outcome should become an explicit decision record rather than free-form commentary. If an approver changes the maximum discount from 15% to 10%, the system needs to know whether that is a revised proposal requiring agent re-planning or a constrained approval the execution layer can enforce.
The record should distinguish approval of the exact proposal, rejection with a reason, a request for named evidence, a bounded amendment, and delegation to another authorized person. The conversation can carry nuance and comments, but the state machine must understand which transition occurred, which constraints changed, and what the agent may do next.
Route authority, not just notifications
Sending an approval request to a channel does not establish that the person clicking it has authority.
Routing should resolve:
- required role or policy attribute;
- separation-of-duties constraints;
- amount, geography, data class, and business unit;
- substitution and out-of-office rules;
- escalation deadline;
- whether the requester or agent owner is prohibited from approving.
Authorization must be rechecked at decision time, not only when the link is generated. Approval URLs should be single-purpose and short-lived, and opening a notification should never count as approving it.
The user experience should display why the request came to them. “You are the cost-centre owner for CC-410” is more actionable than “Approval required.”
Make the waiting state useful
An approval gate should not turn the whole work item into an opaque pause. While one protected action waits, the system may be able to perform independent, read-only preparation. The work graph should make the dependency explicit rather than freezing everything.
At the same time, speculative work must not create pressure to approve. The platform should not send customer-facing material, reserve scarce resources, or make assumptions irreversible before the decision.
Useful waiting-state UX includes:
- named approver and deadline;
- consequence of approval and rejection;
- completed preparation and remaining steps;
- a way to add evidence or correct the proposal;
- escalation path;
- notification when assumptions become stale.
Approval is where trust becomes executable
The product argument that approvals are a feature, not friction is only true when the underlying protocol is sound. Otherwise the interface transfers anxiety to a person while leaving the system ambiguous.
The previous part explains why multiplayer AI is a distributed systems problem. The next covers agent identity and delegated authority. The broader buyer view is in how to evaluate an AI agent collaboration platform.
Put the gate at the exact risk boundary
SoftworkerAI places approval requests inside the work thread, next to the proposal, evidence, consequence, and run history. Underneath, the gate is a durable, versioned transition that the runtime must consume safely.
If your workflows involve money, external communication, sensitive records, or contractual changes, join the early-access program. We want to learn where your real approval boundary sits and what an approver must see to make the decision quickly.
