Human review is not a fallback for bad automation. It is a product control for risk, trust, and accountability. Agent email systems should review uncertain inbound interpretation and risky outbound messages before they reach a recipient.
last updated 2026-05-074 sections
section 01
When review is required
Review should be policy-driven. A message needs review when confidence is low, the recipient is new, the action affects money or permissions, the email includes attachments, or the agent wants to make claims that should be verified.
case
review reason
automatic path
New recipient
No established relationship.
Require reviewer approval before send.
Money movement
Billing, refunds, credits, or invoices.
Route to billing owner or support.
Permission change
Workspace, SSO, admin, or role updates.
Require admin or staff approval.
Low confidence
Intent or entity extraction is uncertain.
Ask for clarification or review.
Attachment
Content may be malicious or ambiguous.
Scan or inspect before model input.
section 02
Review queue fields
A useful review queue should show the normalized request, original message, extracted intent, proposed reply, risk reason, recipient, sender, related account, and idempotency key. Reviewers need enough context to approve without opening several systems.
okShow the latest inbound message and extracted fields side by side.
okShow why review was required.
okShow the exact outbound email before approval.
okAllow edit, approve, deny, and request clarification.
okStore reviewer, timestamp, decision, and final message ID.
section 03
Approval outcomes
Approval is only one outcome. A reviewer may edit the reply, deny the action, request more information, or convert the request into a support ticket. Each outcome should be logged as a policy decision, not hidden as an agent error.
outcome
system action
email action
Approve
Mark action approved.
Send with the original idempotency key.
Edit and approve
Record edited content.
Send edited copy with audit trail.
Deny
Close proposed action.
Send denial only if policy allows.
Clarify
Create clarification request.
Ask for the missing detail.
Escalate
Create ticket or handoff.
Notify the sender that review is in progress.
section 04
What not to review
Do not route every low-risk confirmation to a human. That creates fatigue and hides the actual risk. Review gates should be narrow, explainable, and measurable.