An AI system that suggests a reply and an AI system that sends that reply are doing different jobs.

The words may be identical. The consequences are not.

That distinction is where I would start when designing an agent: what can it inspect, what can it propose and what can it change?

"Human in the loop" is too vague on its own. I want to know which human, at which point, reviewing which information, with what authority.

Map actions by consequence

I would assess each action with questions like these:

  • Does it change an external system?
  • Does it expose information?
  • Is it reversible?
  • Does it create a financial or contractual commitment?
  • How many people or records could it affect?
  • Can the user verify the proposed action before it happens?

A draft summary and a payment should not inherit the same approval rules just because the same agent can produce both.

This is a design framework, not a substitute for the security, legal or domain-specific review a particular product may need.

Make approval specific

A confirmation that says "Continue?" asks the user to approve something without saying what that something is.

For an external message, I would show:

  • The recipient.
  • The complete message.
  • Any attachments.
  • Whether it will be sent now or scheduled.

For a record update, I would show the affected records and the proposed changes. For a bulk operation, I would show the scope, not just a reassuring summary.

The user should not have to reconstruct the action from the conversation history.

Bind approval to the proposed action

My design requirement would be that approval applies to the action the person actually reviewed. If the recipient, amount, records or content change, the earlier approval should not silently carry over.

An approval screen is also not the permission system underneath it. The implementation still needs to enforce which actions the agent and the user are allowed to perform. A clear interface cannot make up for missing access controls, which is why an agent's login is not permission to do everything.

Avoid asking so often that review becomes meaningless

I would not add a confirmation to every harmless step.

Instead, I would define the boundaries in advance: actions allowed automatically, actions that need review and actions the agent cannot perform.

For a limited workflow, that could mean letting the agent categorize incoming requests while requiring approval before it contacts a customer. The exact boundary should follow the risk and the operating context.

Plan for what happens afterward

Approval is not the end of the workflow.

I would also want a record of what was proposed, what was approved, what ran and whether it succeeded. Sensitive information in those records needs its own handling rules.

NIST's Generative AI Profile treats risk management as a lifecycle activity, including evaluation and monitoring after deployment. On my own products, the same thinking applies to releases: AI can draft and summarize, and a person keeps launch authority.

The goal is not maximum autonomy. It is useful autonomy within boundaries people can understand and the system can enforce, so people can delegate work without losing track of what the system is allowed to do.

If you are designing an agent and the approval step is still a "Continue?" button, email me.