What this covers
- Approval design is a business decision, not a technical setting. It belongs to the people who own the workflow.
- Route on risk, not on uncertainty alone: value, customer, irreversibility and novelty each justify a stop.
- A held case is only useful if it arrives as a specific question with the work already done and the options laid out.
- Thresholds should tighten and loosen over time, with evidence from the log rather than by instinct.
Every conversation about AI in operations eventually reaches the same question, usually phrased as a worry: what if it gets something wrong? It is the right worry, and the answer is not better accuracy. Accuracy improves the odds; it never reaches certainty, and a business cannot run on odds when the outcome is a price committed to a customer or a payment released to a supplier.
The answer is structural. Decide, in advance and explicitly, which outcomes the agent may commit and which it must hand to a person. That boundary is the product. Everything else is the machinery that respects it.
The two failure modes
Deployments fail on one side or the other, and they fail differently.
| Boundary too loose | Boundary too tight | |
|---|---|---|
| What happens | The agent commits things nobody would have approved | Every case ends up in a review queue |
| How it shows up | A quote below margin, an order for an account on credit hold | The team is now reviewing instead of doing, and volume has not moved |
| How it is discovered | By a customer, or by finance, weeks later | Immediately, as a complaint that the tool creates work |
| The usual overcorrection | Route everything to a person | Loosen everything at once |
The overcorrection row is the trap. Each failure pushes teams to the opposite extreme, and the second extreme is where most abandoned projects end: an automation that technically works and that nobody trusts enough to let finish anything.
Four reasons to stop, not one
Most tools route on confidence alone. Confidence is necessary and insufficient, because an agent can be entirely certain about something it should still not be allowed to do. Four independent triggers cover operational reality.
- 01Uncertainty
The agent could not resolve something with enough confidence: a part it could not match, a customer it could not identify, a figure it could not reconcile. It stops on that specific item.
- 02Value
The transaction is above a threshold the business set. Nothing is uncertain; the amount alone justifies a person looking, and the threshold can differ by workflow and by account.
- 03Irreversibility
The action is hard or expensive to undo: releasing a payment, committing a delivery date, sending a binding price to a customer. Reversibility, not difficulty, is the test.
- 04Novelty
The case is unlike anything this account has done before. A quantity ten times the usual, a first order from a new entity, a delivery address nobody has seen. Statistically unusual is a reason to pause even when every check passed.
What a good held case looks like
The quality of the handover decides whether approval is a thirty-second decision or a fifteen-minute investigation. Most of the time lost to human-in-the-loop designs is lost here, not in the volume of cases.
A poor handover says: this document needs review. The reviewer now opens the document, opens the system, and redoes the work the agent already did in order to find out what the problem was.
A good handover states the question, shows the work, and offers the options.
- The specific item that stopped, not the whole transaction. Seven lines cleared; line eight is the question.
- The reason, in business terms: "the unit price is 2.4% below the contract price for this account", not "validation failed".
- What the agent already established: the account, the contract, the eleven other lines, the stock position.
- The candidates it was choosing between, with why each was plausible.
- One action that resolves it, so approving is a click rather than a re-key.
If approving a held case takes as long as doing the work, the boundary is not the problem. The handover is.
Setting the first thresholds
There is no universal number, and anyone offering one has not looked at your business. But there is a reliable starting posture: begin tighter than you intend to end, and loosen with evidence.
- 01Start with the authority a new team member would get in their first month. That is a threshold the business already understands and can defend.
- 02Set value limits per workflow rather than globally. A quote and a payment release do not deserve the same number.
- 03Treat the first weeks as measurement. Every held case is data about where the real line should be.
- 04Loosen one rule at a time, and only where the log shows a run of held cases that were all approved unchanged.
- 05Tighten immediately and specifically when something gets through that should not have, rather than tightening everything.
Point four is the one that gets skipped. A rule that has held forty cases and had forty approved without a single edit is not protecting anything; it is a tax. The log makes that visible, which is a large part of why the log exists.
Who owns the line
Approval thresholds look like configuration and are actually delegation policy. The question "may this agent commit a price of this size to this customer" is the same question as "may this person", and it belongs to the same people: the head of sales, the finance lead, whoever signs off today.
Practically, that means the thresholds should be written in the language of the business, visible to the people accountable for them, and changeable without a development cycle. An approval rule that only an engineer can read is a rule nobody is really accountable for.
This is the same principle the rest of our approach rests on: the agent is adapted to how the business already decides, rather than the business adapting to the tool. How it works sets out where that line sits in a deployment, and Security covers the controls around it.