Where a person should stay in the loop

A common worry about automation is that it takes people out of decisions they should be making. A common disappointment is the opposite: a system that asks a person to approve everything, so nothing actually got faster.

Both come from treating “human in the loop” as a yes or no setting. It works better as a design decision made step by step.

Steps that should wait for a person

Some steps are cheap to get wrong and easy to undo. Let those run on their own. Others deserve a pause. In the systems we build, these usually wait for a yes:

• Anything that moves money. Payments, refunds, credit notes and changes to bank details.
• Anything a customer reads. Replies, quotes and messages that carry the company’s name, especially when AI wrote the first draft.
• Anything hard to reverse. Deleting or merging records, cancelling orders and changing access.
• Anything outside the usual rules. An order above the normal size, a supplier nobody has used before, a request that matches no pattern the system knows.

The last group matters most. A system that handles the usual case and hands the unusual one to a person is far more useful, and far safer, than one that tries to handle everything.

Make the checkpoint fast

A checkpoint only works if people answer it. That means bringing the decision to wherever the person already is, not asking them to log into another dashboard.

A good checkpoint shows what the system is about to do, why, and what it based that on, so the reviewer can decide in seconds. It offers the obvious choices, such as approve, edit or reject, and records who decided and when. And it has a rule for silence: if nobody answers within a set time, the step is escalated or held, never quietly approved.

Let the checkpoints move

Where the checkpoints sit should change as trust is earned. A new system might ask for approval on every customer reply for the first month. Once the team has seen enough good drafts, the rule can relax to approving only replies about refunds or complaints.

That only works if moving a checkpoint is a configuration change, not a rebuild. We design for it from the start, because the right amount of oversight in week one is rarely the right amount in month six.

Rules first, then AI, then a person

Our default order is simple. Rules handle what rules can settle. AI handles the reading, sorting and drafting that rules can’t. A person decides what matters, and anything the first two weren’t sure about.

Built that way, people spend their time on the decisions only they can make, and the system does the rest.