Human Approval as a Control

Some actions need a person, and the design of that moment decides whether the control is real. An approval that arrives as one more notification among two hundred is rubber-stamping with an audit trail attached, and it is worse than no gate at all, because everyone downstream now believes a human checked.

This is the control that finally let Sundry's agent move money unattended, and it works for three reasons that have nothing to do with the model: it is narrow, it is informative, and it is rare. Getting those three right is product and interface work, done by the same engineers who wrote the dispatcher.

What Requires a Human

Four categories, and the list is short on purpose. Irreversible actions above a threshold — at Sundry, any refund over the $150 ceiling. Anything justified only by untrusted content, which is Topic 66's rule arriving in the queue as a decision rather than as a refusal. Anything outside policy, meaning the agent found no clause that settles the case or found one that says no while the buyer is asking for an exception. And anything the agent itself flags as uncertain, which is worth having and worth watching, because a model's own uncertainty is a weak signal that drifts with the prompt.

Everything else runs unattended, and that is a deliberate statement rather than an omission. A gate that covers many categories is a gate reviewers stop reading; each category you add has to earn its place against the attention it consumes from the ones already there. Sundry's list has been four items for a year, and the argument for adding a fifth has been rejected twice on exactly that basis.

Designing the Approval Moment

The reviewer needs to make a correct decision in about fifteen seconds. That number is not an aspiration; it is what a support lead can spend per item while working a queue, and everything about the screen follows from it. Four things go on it: what the customer asked for, what the agent proposes to do and for how much, the policy passage the proposal rests on, and what the agent could not verify. The item below is in the queue on the fourth category rather than the first — $118.00 is under the ceiling and the clause was retrieved this run, but the agent flagged its own uncertainty, and that is enough.

{
  "ticket":    "cracked shelf, duplicate delivery charge",
  "order":     "SU-88421", "customer_since": "2023-11",
  "proposal":  {"action": "issue_refund", "amount": "$118.00",
                 "reason": "damage_in_transit"},
  "policy":    {"ref": "returns/damage#3.2", "retrieved_this_run": true,
                 "quote": "Damage reported within 14 days is refunded in full."},
  "unverified": ["no carrier damage scan on this parcel",
                  "seller has not responded to the damage query"],
  "actions":   ["approve", "approve_at", "decline", "open_run"]
}

Read the fifth field, because it is the one teams leave out. The unverified list is what the agent tried to establish and could not, written by the code rather than by the model — no carrier scan exists, the seller has not replied — and it is the difference between a reviewer rubber-stamping and a reviewer deciding. It also tells you what to build next: when the same two lines appear on every item for a month, the fix is a better tool or a better retrieval path, not a better reviewer.

What is not on the screen is the twelve-turn transcript. Nobody reads it, its presence makes the item look expensive to review, and a reviewer who does read it inherits the model's own account of its reasoning — which Chapter 7 was blunt about being a plausible narrative rather than a log. The full run is one click away for the cases that need it, and about 3% of items get that click.

Approval Fatigue Is the Failure Mode

Sundry's first gate asked for approval on every refund and every reply the agent was unsure about: 41% of tickets. Within nine days the median time an item spent open was 4 seconds, approvals ran at 99.4%, and two of the four wrong refunds that month had been approved by a person who saw them. The control existed, the audit trail was complete, and it stopped nothing. A queue nobody can read is not a slower version of a control — it is a different thing that produces the same paperwork.

Getting from 41% to 6% was almost entirely two changes, and neither was a prompt edit. The $150 ceiling, enforced in the dispatcher, let the large majority of legitimate refunds complete unattended, because Sundry's refunds are small and the exceptional ones are exactly the ones worth a person. And better retrieval removed most of the uncertainty flags: Chapter 6's work took the 32-ticket policy slice from 63% to 81% policy-correct, and an agent that finds the clause stops asking a human whether the clause exists. The 6% that remains is Chapter 7's escalated bucket — approvals and escalations arrive in the same queue, staffed by the same people — and each item there gets read.

Treat the approval rate as a design metric with a target and a chart, next to resolution and cost. Rising, it means the agent has lost ground somewhere — a policy changed, retrieval degraded, a new ticket type arrived — and the queue is absorbing the damage silently until someone notices the staffing. Falling to zero is not a triumph either: a gate that never fires is either unnecessary or broken, and both deserve five minutes of investigation.

Interrupting a Loop Cleanly

A gate that holds a worker open while a person decides is a design error, and it fails in the ordinary way: at 40 items a day and a median wait of 20 minutes, the pool is full of processes doing nothing by mid-morning. The run pauses instead. Chapter 11's worker already checkpoints at every turn boundary, so the pause is a state transition rather than a new mechanism — persist the messages, the task state and the proposed action, mark the run awaiting_approval, release the worker.

Resumption is where Chapter 8's intent record earns its place. The proposed action is written as an intent before the pause, so the run that resumes four hours later settles that intent exactly once — approved and executed, or declined and compensated — and cannot issue the refund a second time because a retry delivered the decision twice. Two more behaviours matter. A decision that never arrives must expire into a defined state, and it must expire into declined with the ticket handed to a person: a timeout that auto-approves converts a safety control into a delay, which is worse than having no gate because the audit trail still says a human was in the loop. And the customer gets told, because a ticket sitting silently for four hours is its own product failure.

Recording the Decision

Four fields, recorded as part of the run: who approved, when, what they were shown, and what happened afterwards. The third is the one that gets dropped and the one that makes the record worth keeping — if the approval item is not stored as it was rendered, a later review reconstructs the decision from whatever the policy index says today, and the reviewer looks careless for approving something that was reasonable on the evidence in front of them. Store the item, not a pointer to the live documents. Chapter 13 builds the rest of the audit trail on the same principle, and an auditor asking "who authorized this payment and on what basis" gets one row rather than an investigation.

Autonomy as a Dial, Revisited

Chapter 1 said autonomy is a dial with three settings — suggest, approve each action, act alone within limits — and that the same machinery runs at all three. This chapter is that machinery. Sundry sits at the third setting for refunds under $150 and the second above it, and moving along the dial is now a configuration change plus an eval run rather than a project, which is the property that makes the position revisitable when the numbers change.

Tie the position to measurements rather than to confidence. Sundry moved from approve-each to autonomous-within-limits when resolution on the 120-ticket set reached 88%, the invariant violations were zero, and the injection suite passed at 40 out of 40 — and the ceiling stayed where it was, because a good eval number is a reason to widen autonomy and never a reason to remove a bound. That is the whole chapter in one sentence, and it is how the third wound closed: not with a better prompt, but with a smaller blast radius, a narrower channel, and a person on the few decisions that deserve one.