What human-in-the-loop actually means when an agent writes to your ERP

There are three places a gate can sit, and the choice determines whether the system is genuinely safe or just theatrically cautious. Before extraction is useless — nothing has been proposed yet. After the write is worse than useless — the damage is already in your system of record and you are reviewing history. The only place a gate earns its name is between the proposal and the write.

That sounds obvious written down. It is worth being precise about, because all three positions can be described in a sales call using the same four words, and only one of them protects you.

The three positions, and what each one buys

A gate before extraction is a queue of raw documents waiting for someone to say "yes, process this". It feels safe and buys nothing. The person approving has not seen what the agent will conclude, because the agent has not concluded anything yet. They are approving the existence of a PDF.

A gate after the write is a review report. The order is already in the OMS, the invoice is already posted. What you have is an audit trail with a human attached, which is genuinely useful for catching a systematic problem over a month — and completely useless for preventing the one wrong quantity that ships tomorrow.

A gate between proposal and write is the only one where a person's decision changes what happens next. The agent has done its work: read the document, extracted the fields, scored its own confidence, checked the rules. It has produced a specific, reviewable intention — create this order, with these fourteen lines, on this account — and it is waiting.

A gate is a state, not a notification

Sending someone a Slack message and proceeding anyway is not an approval gate. A real gate means the item sits in a held state with the proposed write attached, it cannot advance without an explicit decision, and it ages visibly so nothing rots in a queue nobody owns.

If a person can miss the message and the write still happens, there was never a gate — only a log entry with better marketing.

The distinction has a practical test. Turn off the notification channel entirely: delete the Slack integration, block the email. Does anything still get written? If yes, the notification was decoration and the system was always going to act on its own judgement.

A held item is a first-class thing in the database. It has an owner, a created timestamp, a reason, and a proposed action stored alongside it. It can be queried, counted, and reported on. "How many items are waiting, and for how long" should be a question with an exact answer, not an estimate someone forms by scrolling a channel.

What the reviewer needs to see

Approving blind is worse than not approving at all, because it manufactures a false audit trail. A reviewer needs the source document, the extracted values, the confidence attached to each, and the specific rule that stopped it. Then approval takes eight seconds and means something.

Per-field confidence matters more than it sounds. A single overall score of 94% tells a reviewer nothing actionable — 94% of what, and which part is the shaky 6%? Per-field, the same information becomes a instruction: the customer and the reference are certain, the delivery date was written as a week number and the agent is unsure. Now the reviewer knows exactly where to look, and the review takes seconds instead of a full re-read.

Field names matter for the same reason. If the agent proposes writing to ship_date_2 and your team calls it "requested week", every review carries a translation step, and translation steps are where mistakes enter.

Ageing, and who owns the clock

The failure mode nobody demos is the queue that grows. Gates that work technically still fail operationally if held items have no owner and no deadline.

Every held item should route to a named person — not a team alias, a person — with a rule for what happens if they do not act. Escalate to their lead after four hours. Escalate again at end of day. The specific numbers are yours; the requirement is that there is a number at all, and that ageing is visible on the item rather than something you discover during a month-end scramble.

This is also the honest answer to "how much time will this save". An agent that holds 30% of items and routes them well saves real hours. An agent that holds 30% of items into an unowned queue has moved the work, not removed it.

Gates should loosen, never tighten

Start with everything held. As the pilot produces real accuracy numbers on your own documents, open the cases you're confident about and leave the rest closed. The direction matters: a system that starts open and tightens after an incident has already spent the trust it needed.

Direction is a cultural fact as much as a technical one. Loosening a gate is a decision made calmly, with numbers, by someone who chose to make it. Tightening one is a decision made after something went wrong, by someone explaining themselves. The same configuration change, arrived at from opposite ends, leaves your team with completely different confidence in the system.

Every loosening should be an explicit, logged, reversible change — the same as any other production change. If you cannot answer "who opened this gate, when, and on what evidence", the gate is not really under control.

The uncomfortable part

Doing this properly means the first version of your agent will look underwhelming. It will hold a lot. Its accuracy numbers will be visible and some of them will be mediocre on your messier document types.

That is the product working. The alternative — a system that writes confidently and shows you a clean dashboard — is not more capable. It is the same uncertainty with the reporting removed.