Your practice space
Read first, or open the worksheet whenever you are ready.
“A person approves it” sounds reassuring until you ask what the person sees. If the approval is a green button next to “AI recommends sending,” the human may have no chance to catch a wrong recipient, a private attachment, or a changed price. Approval works when it is a real decision with the consequence visible.
The simplest starting move is to separate reading, drafting, and acting. An assistant can often read approved material and produce a useful draft without being allowed to send it. That keeps the benefits while you decide which actions need a named person, a limit, or a second review.
Constructed teaching example
See the risk in ordinary work
Example: an assistant prepares a batch of supplier payments.
Where it fails
It reads a changed bank detail from an invoice and queues the payment. A manager thought “review” meant checking a sample at the end.
A better route
The assistant can prepare the batch, but a finance owner checks the destination against a trusted record before release. A changed bank account gets a separate verification call.
The working diagram
Follow the boundary
- 01
Read
Access only approved records.
- 02
Draft
Create an internal proposal.
- 03
Review
Show the person the exact consequence.
- 04
Act
System checks authority and saves an action record.
A human in the loop needs a real decision
“Human in the loop” is often used to mean a person can see something somewhere. That is not enough. The person must have the right authority, enough context to spot a mistake, and a way to reject or correct the action before it happens.
Use a simple ladder. Reading approved records and drafting internal text may be low impact. Sending a customer message, changing a price, moving money, deleting a record, or changing access needs a separate rule. The rule should live in the system that performs the action, not only in the assistant’s prompt.
Review what will actually happen
A useful approval screen shows the target person or record, the exact change, source evidence, attachments, costs, and any uncertainty. “Approve AI recommendation” is too vague. If a reviewer must open six systems to understand the result, approval will turn into a click habit.
Choose which cases can be auto-approved using narrow limits: for example, internal draft formatting with no external send. Review only exceptions that require judgment. If every sentence waits for a manager, people will bypass the tool; if no one reviews a payment, the system has more authority than the business intended.
Check it in your organization
- List read, draft, send, spend, delete, and permission-change actions separately.
- Name the approver and what they must see.
- Create a revoke or emergency-stop path before live use.
Measure the review burden
Track accepted actions, corrections, false alarms, approval delay, and actions reversed after the fact. If reviewers approve almost everything in seconds, sample the decisions for missed errors. If legitimate work sits for days, simplify the low-risk path or provide a trained backup.
A good approval design makes the safe route the quickest normal route. It reserves friction for the few moments where a mistake is costly or hard to reverse.
Follow one business through the course
Northline: a follow-up that almost went to the wrong buyer
Northline Supply is a fictional teaching example, not a reported company incident.
After a trade event, Northline’s sales assistant drafts follow-ups. Two attendees have similar names. One has a confidential discount in the customer system; the other is a new prospect. In a hurried batch review, a polished message looks fine until the account owner checks the address and realizes the private price note belongs to the other person.
The approval view now shows the full recipient address, organization, source event, exact message, attachments, and any price or discount before the send button appears. For simple internal summaries, no manager approval is needed. For an external message with a price promise, the account owner approves. If the owner is away, a named backup handles the queue. The team measures review time so this control does not turn into a week-long traffic jam.
Another setting
A purchase-order assistant
An assistant recommends reordering standard supplies. It also has permission to place an order. The supplier has doubled its unit price, and the draft reflects the new amount without flagging the change.
What to do: Let the assistant prepare the order and show quantity, current price, prior price, supplier, and total. A buyer approves a purchase above a set limit in the purchasing system; the assistant cannot raise its own limit.
Where this goes wrong
Three traps worth catching early
The reviewer sees a summary, not the action
Show the exact recipient, record, amount, and final text. A vague summary turns approval into theater.
Every tiny step needs the same approval
A review queue that blocks harmless formatting will invite workarounds. Spend human attention where a mistake changes the outside world.
No way to revoke a mistake
Approval is not a replacement for a pause button, action log, and correction process. Design the bad day before rollout.
What good looks like on paper
An action ladder, filled in
Keep the action categories separate even when one vendor bundles them into a single permission.
- Read
- Assigned account records only; administrator enforces scope.
- Draft
- Internal follow-up draft; salesperson can edit or discard.
- Send
- Account owner approves exact recipient, message, attachments, and price note.
- Stop and evidence
- Disable send connection; retain action ID, approver, time, and final message.
Put it into practice
Try this on one real workflow
Write an action ladder for one assistant and walk through a wrong-recipient case.
The fill-in worksheet is in the practice space at the top of this lesson. Open it when you have a workflow in mind; it will keep your notes out of the reading flow.
Go to the worksheetSources behind this lesson
The business examples are constructed. These sources support the method or risk described above; they do not prove a result for the fictional company.
Risks from broad tools, broad permissions, and weak approval controls.
Approval must be usable. If the safe route takes longer than the work allows, people will quietly find another route.