01 / 08

Find the consequential moments

Not every agent action needs intervention. A read-only data lookup is different from deleting records, publishing content, transferring funds, or changing access rights. Classify actions by impact, reversibility, and uncertainty.

PUT IT INTO PRACTICE

Create a small action inventory and label each action as informational, reversible, sensitive, or irreversible.

02 / 08

Make the request concrete

“Confirm this action” is weak when the person cannot tell what the action is. A strong handoff names the operation, the target, the effect, and the relevant context.

PUT IT INTO PRACTICE

Show the human-readable consequence beside the primary confirmation action.

03 / 08

Bind verification to context

A presence result obtained for one action should not silently authorize unrelated actions. The consuming backend should check the intended purpose and reject stale, reused, or mismatched proofs.

PUT IT INTO PRACTICE

Represent the requested action with a server-generated identifier and validate it when consuming the result.

04 / 08

Expect failures

Network loss, expired results, abandoned flows, and conflicting state are normal—not exceptional. Define whether to pause, retry, recover, or safely roll back.

PUT IT INTO PRACTICE

Write the negative-path UX before implementing the happy path.

05 / 08

Keep accountability clear

A person participating in a checkpoint is not automatically assuming every responsibility of an autonomous agent. Explain the degree of control and retain only appropriate audit details.

PUT IT INTO PRACTICE

Separate event records, account identity, and operational logs so each has a documented purpose.

06 / 08

A handoff is a transaction boundary

Consider an assistant that reviews a set of invoices and proposes paying the approved ones. The agent can collect records, calculate totals, and prepare the batch. But the payment instruction changes the world outside the assistant. The human handoff should occur after all relevant details are assembled and before the payment is committed. It should display the recipient, total, exceptions, and the operation that will occur if the person approves.

A common design mistake is to gather a generic approval at the beginning and treat it as permission for anything the agent later decides to do. That decouples the human from the actual consequence. Instead, the system should create a reviewable transaction description and bind any participation result to that exact transaction or a verifiable hash of its essential details. Changing the payment after approval should invalidate the earlier confirmation.

PUT IT INTO PRACTICE

Specify the immutable fields that an approval covers and the changes that require a new human handoff.

07 / 08

Design concurrency and interruption deliberately

Real workflows do not unfold on a perfect linear timeline. The same approval request may open in two browser tabs. A person may approve while an agent is still updating the task. A response may arrive after a timeout or after a different administrator cancels the operation. Without a clear state machine, the system can accidentally process the same request twice or apply a stale response to a changed operation.

A safe design models states such as proposed, awaiting human, approved, declined, expired, cancelled, and executed. Legal transitions are explicit. Approval does not necessarily mean execution succeeded; execution may fail and must have its own status. When an approval expires, the agent should pause safely and explain the next step. If the request changes, a new handoff should present the updated consequence in plain language.

PUT IT INTO PRACTICE

Draw the state diagram for one workflow and mark the transitions that must be atomic and idempotent.

08 / 08

Measure handoff quality, not clickthrough alone

A quick confirmation flow can look successful while hiding important information. Measuring only the rate of accepted requests rewards frictionless rubber-stamping. A more balanced review looks at completion time, decision reversals, support requests, misunderstanding, error recovery, and incidents prevented. The system should also record whether users had enough information to evaluate the action without jumping between multiple applications.

The interface should support the legitimate choice to decline. Declining a questionable action is sometimes the successful outcome. That choice should be visible, well-labeled, and free from manipulative copy. In high-impact workflows, provide a way to inspect underlying evidence and a route to ask for clarification. The goal is meaningful participation rather than an artificially high acceptance rate.

PUT IT INTO PRACTICE

Review your confirmation screen: can a person confidently decline, and can they tell exactly what approving will change?

THE NEXT STEP

Turn the idea into a practice.

Use the companion activity to apply this topic to a real workflow or design problem.

Open the matching activity
Previous guide Next guide