Every agent we ship has a person reviewing its work somewhere. The idea is easy to say and hard to build. In practice, human review fails in two ways. The person is asked so often that they stop reading, or they are asked after the thing has already happened. Both look fine in a demo. Both show up in the numbers within a month.
We have shipped gates into freight dispatch, support queues, and finance teams. Here is what works, what does not, and the metrics we watch to tell the difference.
What a gate is for
A gate exists to put a person in front of an action that is irreversible, expensive, or customer-facing. That is the whole list. Sending, paying, refunding, deleting, changing a record another team depends on, and committing to a price or a date. Everything read-only runs without asking: looking things up, drafting, sorting, summarizing.
Most broken gates come from ignoring that list. A team wraps every step in an approval because it feels safer, and within three weeks the approver is clicking through 60 cards a day. We have measured it: once an individual sees more than roughly 25 approvals a day, their median decision time drops under five seconds. At that point the gate is decoration.
The four patterns
Four shapes cover nearly everything we build.
1. Pre-flight
The agent prepares the action and stops. A person sees exactly what will happen, then approves, edits, or rejects. This is the default for anything customer-facing. Lumen Logistics' dispatchers see a draft quote with the extracted route, the rate calculation, and the reply that will go out. Approve sends it. Edit changes the number and sends. Reject asks for a reason, which we log and review.
2. Threshold-routed
Ask only when a number crosses a line. The line can be confidence, money, or both. Halcyon's support agent answers on its own when its confidence in the lookup is high and the answer contains no account change. Refunds of any size and every account change go to a person. Answers under the confidence threshold go to a person with the draft attached. Around 61% of tickets clear without review, and the 39% that do not are precisely the ones that should be looked at.
3. Batched
Group approvals into a queue that is reviewed at set times. Right for low-urgency, high-volume decisions with shared context. Meridian Dental Group's front desks get one morning list per location: open slots, reschedule requests from overnight, and any reminder the system could not send. One review, about ten minutes, twelve locations.
4. Act, then audit
The agent acts, logs it, and a person reviews a sample or an exception report later. Only for actions that are cheap to reverse: tagging, internal notes, routing, drafts saved to a folder. We pair this with an undo window and a daily digest. It is the pattern people most want to use for things it is not safe for.
| Pattern | Use when | If it is wrong | Load per person |
|---|---|---|---|
| Pre-flight | Customer-facing, money, irreversible | Caught before it happens | Under 25 a day |
| Threshold-routed | High volume, measurable confidence or amount | Caught above the line; ships below it | 5 to 20 a day |
| Batched | Low urgency, shared context | Caught at the next review | One sitting |
| Act, then audit | Cheap to reverse, internal only | Reversed after the fact | A sample |
Numbers that say a gate is broken
- Approval rate above 97% for a month. Either the agent is excellent and the gate can loosen, or nobody is reading. The median decision time tells you which.
- Median decision time under five seconds. Nobody is reading.
- Edit rate near zero. A gate with only approve and reject gets rejected less than it should, because rejecting means redoing the work. Give people an edit button and watch the rate. Between 5% and 15% is healthy.
- Queue age past the response-time promise. If quotes need to go out within an hour and the median card waits three, the gate is the bottleneck. Route or batch differently.
- Reject reasons repeating. If a third of rejections say the same thing, a rule is waiting to be written before the AI step.
What the approval card shows
The approval card is a small screen that does a lot of work. A few rules have held up.
- Show the action first. "Send this reply to the shipper at Corvid Freight," followed by the reply body. The AI's reasoning goes behind a "show more" link, never in the card.
- Show what the model saw. The source email, the policy it looked up, the record it is about to change. Approvers catch most errors by noticing a mismatch between input and output.
- Three buttons, always. Approve, edit, reject. Reject requires a reason from a short list plus free text.
- One card, one decision. Bundling three actions into one approval means the approver either blocks all three or waves through the one they did not check.
- Put it where the person already is. Slack for ops teams, the transport system (TMS) for dispatch, Zendesk for support. A separate approval portal is where approvals go to expire.
- A deadline and an escalation. Every card has an owner and a fallback after a set time. Unowned approvals are the second most common reason a workflow "stopped working."
An approval is a decision. It needs exactly the information it takes to make it, and nothing that makes it easier to click without reading.
Tuning the thresholds
Gates should get looser over time, on evidence. We start strict and loosen by category.
Halcyon's agent ran with 100% human review for its first two weeks in production, on top of a pre-launch test against 400 past tickets. Each week we looked at approval rate and edit rate per ticket category. Password resets and "where is my invoice" hit 99% approval with under 2% edits by week two, so those categories moved to threshold-routed. Plan changes stayed at 100% review, and still do. The 61% auto-resolution figure is the sum of those category-level decisions, and it moved up in steps, never all at once.
The rule we follow: a category can loosen when it has at least 200 reviewed decisions, an approval rate above 97%, and an edit rate under 3%. It tightens again the moment a customer-visible error is traced back to it.
The mistake we see most
Approve-only gates. When a person can only accept or reject, and rejecting means the work comes back to them, they accept. We have watched approval rates sit at 99% while the same team privately fixed the agent's output after the fact. Adding an edit button dropped the approval rate to 84% and put the edit rate at 12%, which was the truth all along. Now the edits feed the evaluation set (the past cases we test against), and the agent improves from them.
A short checklist
- List every action the agent can take. Mark each one read-only, reversible, or irreversible.
- Gate only the irreversible and customer-facing ones. Let the rest run.
- Pick a pattern per gate from the four above.
- Build the card with approve, edit, and reject, and show the input next to the output.
- Set an owner, a deadline, and an escalation for every gate.
- Launch at 100% review. Loosen per category, on the numbers.
- Review approval rate, decision time, edit rate, and queue age every week.
Done this way, the reviewer makes a few real decisions a day, with the information to make them. Nobody clicks a button the system was going to press anyway.