What should happen when an agent reply needs human review?

Suppose a support agent drafts a reply that promises a refund. The right system behavior is not simply “block the AI.” Routine replies should keep moving, while commitments that cross a policy boundary should stop with enough context for a person to decide.

A useful review flow has four parts: a held outcome, an explanation, a human decision, and an attributable record.

The agent needs an outcome it can act on

When a message is held, the send response should distinguish the content decision from the delivery effect. A scanner may describe a liability risk, while the email effect says that nothing was sent and the message is waiting for review.

The agent's instruction is deliberately boring: report the hold and do not retry. Retrying with rewritten language can turn a governance control into a prompt-optimization target. It can also create duplicate work for reviewers.

ReplyLayer represents this path with a held effect such as held_for_review, plus findings and agent instructions. See the send-outcome contract for the exact fields.

The reviewer needs the relevant context

A useful queue should answer:

• Which mailbox and recipient are involved?
• What did the agent attempt to say?
• Which policy or finding caused the hold?
• Is the message releasable, blocked, or waiting on infrastructure?
• What will approval actually do?

The reviewer should not have to reconstruct the event from application logs. The decision belongs next to the message, its scan result, and the policy that governed it.

Approval dispatches the held message. Denial ends that send attempt. A release is a privileged human action, not an ability granted to the same mailbox-scoped agent that authored the reply.

Test the exception path before customers find it

You can inject a synthetic inbound message containing a known prompt-injection fixture:

rly simulate inbound \
  --mailbox support-bot \
  --scenario prompt_injection_quarantined \
  --json

The scan is real, and the returned status remains authoritative. When structural protection is active, the expected result is quarantined; otherwise branch on the actual status rather than inferring it from the scenario name.

For an outbound review test, use a test mailbox policy that holds agent sends, then submit an ordinary simulator-addressed message. Verify that the agent receives a held outcome, the message appears in the review queue, and only the reviewer can approve or deny it.

A hold is a product state, not an error page

The most important interface decision is what happens next. Give the agent a stable stop condition. Give the reviewer a direct action. After the decision, record who acted and why.

That makes human review compatible with automation: the normal path remains autonomous, while the exception path is visible and bounded.

Try the workflow in a free Sandbox or read the content-scanning guide.