"Human in the loop" is the phrase vendors use when they want you to stop worrying. Somewhere in the product a person clicks Approve, so the agent is supervised. We think that sentence confuses two different things. An approval is an event. Oversight is a capability, and it is the capability you were promised.
The evidence that the two come apart is unusually direct. Anthropic, which builds Claude Code, reported that its users approve 93% of permission prompts. The population is people using a coding agent, so the number says nothing about invoices or purchase orders. But it describes a mechanism, and the mechanism travels. Ask someone to confirm the same kind of action forty times a day and they stop reading it by the tenth. Anthropic's own response was to build classifiers that decide some of those prompts automatically, because the manual gate was not protecting anyone.
What a rubber stamp looks like in an ERP
The case below is constructed. It is not a client, not a past project and not a measurement. Picture an agent that drafts vendor bills from emailed invoices and routes each one to a person to confirm. On day one the clerk checks every field. By week three the queue holds two hundred items, almost all of them correct, and the clerk has learned that the button is always safe to press. The one wrong bill looks exactly like the other 199. The approval was logged, the audit trail is clean, and the error went through anyway.
Nobody was negligent. The design asked a human to do what humans are worst at: stay alert against a rare failure while watching a stream of successes.
Four changes that make the loop real
Gate on consequence, not on volume. Reading a record is not the same as posting an entry, and posting an entry is not the same as releasing a payment. Let the agent run freely on the first, and put people only on actions that move money, change a vendor's bank details or touch customer data. A queue that is short enough to read is the only kind that gets read.
Make reversibility the first control. If an action can be undone cheaply, a draft that a person can delete, it needs a review after the fact, not a permission before it. Spend human attention on the things that cannot be taken back. This also tells you which agent permissions to grant in the first place, which is the argument of our piece on prompt injection and agent security.
Show the difference, not the summary. A message saying "Create bill for Supplier X, 4,200" invites a click. A view that shows the bank account that changed since last time, or the amount that sits outside this supplier's usual range, invites a decision. The reviewer should see what is unusual, because the agent already knows.
Measure the approver. Track how often a person edits, rejects or sends back what the agent proposed. A rejection rate of zero for months is not proof that the agent is perfect. It is the signal that the gate has stopped working. Seed the queue with known-bad cases now and then, and count how many get caught. That is the same discipline as writing the test before the agent, covered in AI agent evals before production, applied to the person instead of the model.
Where we land
A human in the loop is a design problem with a measurable outcome: the share of real errors a person actually stops. If nobody can say what that share is, the loop is decoration, however many approvals are in the log.
We implement Odoo and ERPNext and build the agent behind the screen, so the approval step is something we design alongside the permissions, not bolt on at the end. If you are deciding where agents should be allowed to act in your own system, our approach page explains how we scope that, and the services page lists where we can help.
