Show the decision, evidence, scale, cost, identity, and exact messages together. Bind approval to a version and expire it when material inputs change. Safety events should stop automatically; they should not wait for human review.
Approve an artifact, not a conversation
Chat history is a poor authorization record. It mixes ideas, discarded drafts, tool output, and later corrections. Ask the agent to produce a final structured artifact containing target criteria, exclusions, representative evidence, sender identity, exact sequence, infrastructure, limits, assumptions, and cost.
The interface should render that artifact in plain language and preserve the machine-readable version. Approval stores who acted, when, which version they saw, and what consequences were allowed.
Use separate approval levels
| Approval | What it authorizes | What invalidates it |
|---|---|---|
| Plan approval | Audience rules, sources, sequence, assumptions | Material change to targeting, claims, or content |
| Budget approval | Maximum spend and resource scale | Higher spend, more domains, mailboxes, or data |
| Provisioning approval | Domain registration and mailbox creation | Different identities or irreversible vendor action |
| Launch approval | First send to a defined cohort | New campaign version or expired review window |
| Scale approval | A bounded volume increase | Unsafe delivery evidence or limit increase |
Define a material change
Changing punctuation is not the same as adding a claim, widening a geography, doubling the audience, replacing the sender, or purchasing new domains. Encode material fields so the system can invalidate approval mechanically instead of asking the agent whether its own change is important.
A useful diff highlights additions and removals, not just the latest state. Reviewers should see that “U.S. seed-stage robotics firms” became “North American industrial companies,” or that the call to action changed from a question to a meeting request.
Do not put humans in the emergency path
Complaints, opt-outs, hard bounces, provider blocks, broken authentication, and severe queue anomalies should trigger deterministic suppression or pausing. Waiting for someone to approve a stop defeats the purpose of the safety control.
Humans decide whether and how to resume after diagnosis. That separation keeps routine operation efficient while reserving judgment for changes in strategy or risk.
Prevent rubber-stamp review
Actually Agentic’s planned flow is built around an external agent proposal followed by validation and explicit customer approval. The general principle is portable: reasoning and authority should meet at a concrete, reviewable boundary. [1]
- Show a small representative audience sample with source reasons.
- Put exclusions and uncertainty beside the positive targeting case.
- Render every sequence step exactly as recipients will see it.
- Show absolute volume and cost, not only percentages.
- Require a reason for overriding a warning.
- Expire approvals rather than carrying them across indefinite edits.
- Keep an operator-controlled global send switch outside the agent’s credentials.
Common questions
Questions, answered plainly
What should a human approve in an email-agent workflow?
At minimum: the audience and exclusions, evidence, sender identity, complete sequence, scale, infrastructure consequences, budget, and first production cohort.
Does every email need manual approval?
Not necessarily. Approve a bounded template and policy for a defined campaign, then require new approval when material inputs or generated claims change.
Should pausing require approval?
No. Safety signals should pause or suppress deterministically; accountable humans should control any later resume.
Evidence
Sources and methodology
Product capabilities were checked against first-party documentation available on September 9, 2026. Policies, plans, and prices can change; verify them before buying. General guidance is educational and is not legal advice.
- Actually Agentic product overview Actually Agentic. Product scope and operating model.
- Actually Agentic terms of service Actually Agentic. Current service boundaries, customer obligations, geography, and deliverability limitations.
Your agent can do the thinking.
The infrastructure still needs a grown-up.