Where to put a human checkpoint on an agent

Put the checkpoint at the last reversible moment. Let an agent run without interruption through anything you can undo. Then stop it before the step that cannot be taken back: sending a message, deleting data, publishing, merging, charging a card. The field settled on this during 2026. It is a better rule than "approve everything" or "let it run", which both fail for the same reason.

Why is full autonomy the wrong target?

Because what teams want is outcomes they do not have to check. Autonomy was only ever a means to that.

Teams that aim at full autonomy end up with a system nobody trusts. So somebody reviews everything anyway, informally and without a record. Teams that approve every step build a queue that no human can keep up with, and the approvals turn into clicking yes. Both end up in the same place. The control exists on the diagram but not in practice.

The approach that works is selective autonomy. The agent is unsupervised where mistakes are cheap and reversible, and gated where they are not. That puts human attention where it changes an outcome, instead of spreading it evenly over work that did not need it.

Which steps need a gate?

Check reversibility first, then reach, then confidence.

Irreversibility is the main test, and it is usually obvious. Reading a repository, drafting a change, running tests and proposing a branch are all recoverable. None of them needs a checkpoint. Merging to main, emailing a customer, deleting records, moving money and publishing anything cannot be undone by anyone, however sorry everybody is afterwards.

Reach is the second test. An action that leaves your organisation deserves a gate even when it is technically reversible. Retracting something is not the same as undoing it. A message sent to a customer has been read.

Confidence relative to stakes is the third test, and the easiest to overdo. Gating a high-stakes action on low model confidence is reasonable. Using confidence in place of the first two tests is not. When agents fail, they are usually confident about it.

The result is a short list that holds across most products: send, delete, publish, merge, charge, grant access. If your gate list is much longer than that, you are gating ordinary steps. The queue will grow faster than people can handle it properly.

Is an approval the same as a done-gate?

No. Mixing them up is the most common design error here.

An approval checkpoint asks a person to authorise an action before it happens. It is about permission. It runs at the moment of the act, and it asks "should this be allowed to proceed".

A done-gate asks whether the work satisfies what was asked. It runs after the work exists, and it asks "does this evidence meet the definition of done". For most tasks a machine can answer that, because the criteria were written down in advance.

They fail in different ways, so you want both. Approvals catch the catastrophic and the irreversible. Done-gates catch work that is wrong but harmless. That outcome is far more common, and an approval queue is poorly placed to spot it. A person clicking approve on a merge is deciding whether merging is allowed. They are not reading the diff carefully at four in the afternoon.

How do you stop the queue becoming the bottleneck?

By measuring the queue, and by making the gate carry its own evidence.

Human wait share is the number that shows this. It is the percentage of total cycle time spent waiting on a person instead of on work. Once agents are involved it is usually the largest single part. It responds to scheduling, not engineering, which makes it the cheapest thing to fix.

Two design choices keep it small:

• Give the approver what they need to decide, in the request. An approval that requires opening three systems will be batched, delayed, and eventually rubber-stamped. Put the proposed change, what it affects and what the checks said in front of them.
• Route by authority, not by availability. Send the approval to the person accountable for the thing, so it is a decision. Sent to whoever happens to be online, it becomes a formality.

Treat a rising approval queue as a signal about your gate list. If the queue grows steadily, you are probably gating reversible steps.

Does the regulation say anything about this?

Yes. It says the oversight has to work. Having it on paper is not enough.

The EU AI Act's Article 14 requires high-risk systems to be designed so people can effectively oversee them, with measures proportionate to the risk and the level of autonomy. The key word is effectively. A dashboard nobody owns is oversight in name only. Oversight that works is a checkpoint that pauses the action, and a halt that takes one action instead of a deploy.

Whether that applies to you is a legal question with a definite answer. It deserves a proper answer from someone qualified, not from a blog. The design lesson holds either way. Build the stop before you need it. A control you add during an incident arrives too late.

What does this look like when it is working?

Mostly, it is quiet. The agent works for long stretches without anyone watching, because the steps it is taking cannot hurt anybody. People step in at a small number of moments that need a decision. Over time, the number of approvals per unit of work falls as the team learns which steps can be undone. In a setup that is not working, it rises as trust erodes.

In Cognibl the safe default is built into the product. You do not have to configure it. Agents can only read your tools today, and code changes arrive as pull requests that a person merges. Write-type tool calls stay closed until they can land in a staging queue, where a commit step will push them through or discard them. Halting is one action at the job, agent or customer level, and never a deployment.