Governance
Agents propose. Humans decide.
Not every send should go out automatically. Policy-blocked sends, high-risk inbound, and HITL-gated outbound all flow through approval queues where operators approve, reject, edit, or escalate. The agent waits. The human has full context.
Three queues, three reasons
Needs approval
When HITL is enabled for your tenant, every outbound send pauses here before delivery. Inbound messages that trigger safety review land here too. Operators can approve (and optionally send a reply in the same action), reject, or escalate. Approvals have a configurable timeout (default 24 hours) — expired approvals are auto-rejected.
Blocked by policy
The agent tried to send but a policy rule said no. Duplicate dedupe key, cooldown still active, recipient suppressed, rate limit exhausted, domain still warming up, template not approved. These are informational — operators can dismiss or investigate, but they can't override the policy and force delivery.
High risk
Inbound emails flagged for injection risk, malware, phishing, or anomalies. The message is held. An operator reviews and either releases it to the agent or quarantines it. Read-only queue — the operator acknowledges risk, they don't approve a send.
What operators can do
Four actions, each logged to an immutable audit trail. Every action records who did it, when, and why.
Approve
Release the send. Optionally attach a template and recipient to send a reply in the same step. The approved request re-enters the send queue and goes through normal delivery.
Reject
Kill the send. The thread moves to resolved and is trashed. The linked send request is marked rejected. Terminal state.
Edit
Update thread metadata or reassign to a different agent. The thread stays in the queue. Useful for adding context before another operator makes the final call.
Escalate
Pull the thread out of the queue and assign it to a human or team. Status moves to escalated. The agent disengages. Use this when the thread needs expertise beyond what the queue operator can provide.
Manage queues from the CLI
# Check what's waiting
$ molted overrides counts
{
"needs_approval_outbound": 2,
"needs_approval_inbound": 1,
"blocked_by_policy": 4,
"high_risk": 0
}
# Approve and send a reply in one step
$ molted overrides approve d290f1ee-... \
--reason "Reviewed, looks good" \
--template follow-up \
--to alice@bigcorp.com \
--payload '{"name":"Alice"}'Escalate and handle held messages
# Escalate to a human team
$ molted overrides escalate d290f1ee-... \
--reason "Needs legal review before responding" \
--assign-to legal-team
# Release a held inbound message
$ molted overrides release msg-abc123...
# Reject a suspicious inbound
$ molted overrides reject msg-abc123... \
--reason "Phishing attempt"How sends flow through the queue
Your agent calls request-send as usual. If HITL is enabled, the send pauses with status pending_approval and a send.approval_pending event fires. When an operator approves, the send re-enters the queue, goes through normal delivery, and a send.approval_decided event fires. If the operator doesn't act within the timeout window, the approval expires and the send is rejected automatically.
Policy-blocked sends work differently. They never reach the approval queue — they're blocked before HITL evaluation. The agent sees a blocked status with the policy reason. The thread gets a blocked_by_policy queue tag for operator visibility, but the operator can't override policy and force the send through. Policy is infrastructure, not a suggestion.
Enable HITL: Set hitl_enabled: true on your tenant quotas. Configure hitl_timeout_hours (default 24) to control how long approvals wait before expiring. Available via the admin API or by contacting support.
Trust your agents. Verify when it matters.
Most sends go out automatically. Policy catches the obvious violations. Approval queues catch the rest — the edge cases, the high-stakes threads, the ones where a human eye makes the difference. Every action is audited.