The first post on approval design for high-risk operations argued that a human in the loop is what lets you put an agent on a high-risk action like a refund. The agent proposes, a person commits, and the irreversible step runs from the approved request behind a durable two-person review. This post puts that model on real screens. It follows one refund end to end in Latch: an AI-recommended account credit for a duplicate charge, paused for independent review before any money moves. The credit and the refund run through the same plugin. The walkthrough follows the credit through approval and a contested refund through rejection. The screenshots are the real screens an operator and a reviewer see.
It starts by naming the action. Issuing a credit is one registered plugin action, not something the agent can do on its own. It has an owner, an authentication mode, a health check, and diagnostics, all visible before any approval prompt exists.
The plugin registry. The agent's ability to issue credits is one explicit integration with its own auth mode, health status, and diagnostics. An action you have not named is an action you cannot control.
The risk tier is enforcement, not documentation. The credit and refund actions require two-person review, with a 24-hour approval expiry and per-action overrides. The tier is a property of the action, configured once.
Risk tiers expressed as enforcement, not documentation. The tier is a property of the action, not a label on a wiki, and it decides the enforcement mode.
Watch one credit move through the gate
Once the surface is shrunk and the action tiered, the review is no longer a pop-up. It becomes a sequence inside the case: requested, approved by a different person, executed from the approved request. The case record holds the request, the reviewer, what they saw, what ran, and what the downstream system returned. Four cases carry this story through every control state: a refund awaiting approval, an approved credit ready to resume, a refund rejected for incomplete evidence, and a rejection that itself had to clear a review.
The approval story as a queue of work. The gate is part of the case, not a separate inbox an operator has to monitor.
The agent recommends; it does not act. The support agent proposes a concrete, scoped credit and routes it through the review. The operator sees the recommendation in the case activity, alongside a drafted customer response, and decides what happens next.
The agent recommends. The operator decides. The proposed credit is concrete, but it enters the case as a request, not a completed transaction.
A reviewer's decision is only as good as what sits in front of them. The preview makes the financial impact and the reference identifiers impossible to miss.
The action preview as a reviewable artifact. The amount, the reference identifiers, and the human-readable reason are front and centre, with an explicit prompt to verify the duplicate-charge evidence before proceeding.
The control lives where the work lives: on the case, with the requester and the current state attached. A reviewer never leaves the record to act.
The approval card in context: action identity, current state, requester, and a clear review path, inside the case timeline.
Before approving, the reviewer sees the exact stored request that will execute, field by field. Not a rendering. Not a summary. The canonical payload, with the guarantee that this is exactly what will run. That is the moment most products skip.
The exact stored payload, including the evidence and the customer account it touches, requested by a named operator. The dialog states the rule directly: the payload shown here is the exact request that will be approved or run.
If the preview shows one thing and the runtime sends another, every other control is theatre. Matching the reviewed action to the executed action is a design goal, not an accident. The review dialog and the execution record are the two halves of that guarantee.
The approval survives the wait, and a rejection is an action too
Approval is durable, decoupled from execution. Once approved, the action is tied to the case version and the stored request. It can run later, from the exact approved payload, even after the original session is gone.
Approval is durable and separate from execution. The approved action is tied to the case version and the stored request, ready to resume.
Not every request should be approved. A rejection is a first-class state, not a dead end in an email thread. The control records why the action was rejected and keeps the full trail visible. A reviewer weeks later can reconstruct the decision without archaeology.
Rejection done right. The gate records why the action was rejected and keeps the full trail visible.
Role separation cuts both ways. Rejecting a contested refund is a consequential decision. The denial itself needs a second reviewer. An analyst flags the rejection as a risk decision, and voiding the refund still clears a two-person review before the case treats the rejection as final.
The agent flags the rejection as a risk decision, and voiding the refund still requires a second reviewer. A denial is an action.
The same case, lower in the trail. The void was approved by a second reviewer. Requester and approver are distinct, and the timeline records both.
The execution record is the proof
An approval is only as defensible as the evidence it leaves. The audit trail is separate from operational traces. Traces are high-volume, short-lived. Audit evidence is attributable, long-lived. Every entry is reconstructible: who decided, when, why, what they saw, what actually executed, and what the downstream system returned.
Execution evidence after an approved action runs: status, who ran it, the exact upstream request, the JSON payload, and a byte-counted raw snapshot. This is what turns an approval into an inspectable control.
Six months from now an auditor asks two questions: what did the approver see, and what actually ran. The review dialog answers the first. This execution record answers the second. Together they survive "how do you know."
That is the model on one case. The third post goes deeper, into durable approvals, policy as code, and building gated actions: how durability and revalidation work, how to express role separation as policy, how to build your own plugin actions, and the problems that do not yet have clean answers.