Where the handoff belongs

Most teams put the human in the wrong place. They either approve everything, which means the agent has added a step rather than removed one, or they approve nothing, which means the first serious error is discovered by a customer. Both are the result of treating the handoff as a policy rather than a design.

The handoff belongs at the point where the cost of being wrong first exceeds the cost of a human glance. That point is specific to each action, and it moves as the system earns trust.

Three handoff patterns, and when each applies

• Review before act. The agent proposes, a human approves, nothing happens without a click. Correct for irreversible actions, money movement, and anything external-facing in the first months.
• Act and notify. The agent acts, a human sees a record and can reverse it inside a defined window. Correct for reversible internal actions where speed is the point.
• Act and sample. The agent acts unattended, a fraction of outputs are reviewed on a schedule. Correct for high-volume, low-stakes work where per-item review destroys the economics.

The mistake is picking one pattern for the whole system. A single agent usually needs all three, applied per action. Drafting a reply is act-and-sample. Sending it to a customer is review-before-act. Updating an internal status field is act-and-notify. Choosing one policy for the agent rather than one per action is how you end up with a queue of approvals nobody clears.

If your reviewers approve everything without reading, you have not built an oversight mechanism. You have built a latency tax with an audit trail.

Design the escalation, not just the escalation rate

When an agent hands off, the human receives a decision, not a mystery. That means the handoff has to carry the context: what the agent was trying to do, what it found, why it stopped, and what it recommends. A handoff that arrives as a bare alert forces the human to redo the work from scratch, which is worse than never having automated it.

Instrument how long handoffs sit unclaimed. A rising queue is the earliest reliable signal that the agent is escalating on cases it should handle, or that the routing is sending them to someone with no authority to resolve them. Both are fixable, but only if the queue is measured.

Let the boundary move

The handoff point should be written down and revisited on a schedule. As evaluation data accumulates, categories of work graduate from review-before-act to act-and-notify. That graduation is the actual return on the project, and it only happens if someone owns the decision and has the numbers to defend it.

Graduate by category rather than globally. Refund approvals under a threshold move before refund approvals above it. One document type moves before the rest. Each move is a small, defensible decision backed by the review history for that specific category, which means it can be argued for and, if it goes wrong, reversed without touching anything else.

Design the boundary to move in both directions too. If the error rate in a graduated category rises, it should return to review without a deployment and without a meeting. A handoff policy that can only be loosened is not a policy, it is a ratchet, and the first serious incident will take the whole system back to manual.