What an approval step for AI email should show and when it expires
A good approval step shows the recipients, the full message, why the agent wrote it and what it is based on, and it expires if nobody acts. A checklist.
On this page(7 sections)
An approval step for AI email is the point where an agent proposes a message and a person decides whether it goes out. It only protects you if the person can see what is about to be sent, to whom and why, and if a forgotten proposal cannot go out days later. Most of the risk sits in what the screen shows, not in the button.
Approval is the standard answer to the risk of an agent acting on bad input. OWASP's list of LLM risks names Excessive Agency and recommends human-in-the-loop control "to require a human to approve high-impact actions before they are taken." Sending email to a customer is high-impact: you cannot unsend it. This post is about designing the approval step itself, so the human in the loop is doing real review and not clicking through.
What is the difference between Suggest, Approve and Auto?
They are three levels of how far an email agent can go. Suggest means the agent writes drafts and a person sends. Approve means the agent proposes a send and waits for a person to approve it. Auto means the agent sends on its own inside rules you set. Koltrix calls this the autonomy dial and sets it per agent mailbox.
| Level | What the agent does | Who sends | Where it fits |
|---|---|---|---|
| Suggest (default) | Writes a draft or proposal | A person | First weeks of any agent |
| Approve | Proposes a send and waits | A person taps approve | Routine replies you want to skim |
| Auto (Beta) | Sends alone inside your rules | The agent, with every send logged | Narrow, repetitive replies after weeks of good drafts |
Auto is a Beta feature, off by default for every agent, and anything that fails one of its rules falls back to the approval step described below. That makes the approval step the safety net for the other two levels as well, so it is worth getting right. If you are choosing a level, reply suggestions or full drafts covers the trade-off, and human-in-the-loop email automation patterns covers where approval belongs in a workflow.
What should an approval screen show?
It should show everything the message will do once it leaves, in the form the recipient will see it. If the approver has to open another tab to find out who gets this, the review gets skipped.
- The exact recipients. To, Cc and any added address, spelled out. Wrong-recipient mistakes are the most expensive kind.
- The full subject and body. Not a summary and not a preview line. What you approve is what is sent.
- The thread it answers. The message being replied to, so the approver can check the answer fits the question.
- Why the agent wrote it. A one-line reason, such as which rule or instruction applied.
- What the answer is based on. The knowledge or earlier message the agent used. A claim with no source is the first thing to question. Checking an AI-drafted reply walks through that review.
- Any warning on the incoming message. If the message that triggered the proposal looked like a prompt injection, say so on the same screen.
- Why it is waiting. If the agent could have sent alone but a rule held it back, name the rule: a recipient not on the allowed list, the daily cap, quiet hours or a risky message.
In Koltrix, proposed sends wait in the Action center, which lists what needs you and how many sends each agent has made today against its cap. A held send says why it was held, and a message the injection shield holds back from an agent appears there with the warning so a person can release it or leave it held.
What actions should an approver have?
Four are enough: approve, edit then approve, reject and snooze. Fewer forces people to choose between sending something imperfect and throwing it away. More invites mistakes.
- Approve sends the proposal as written.
- Edit then approve lets the person fix a sentence and send. Re-check the edited text, because an edit is new content.
- Reject drops the proposal without sending.
- Snooze brings it back later, for the proposal you cannot judge right now.
One rule is worth copying: an edit should be allowed to remove recipients but not add them. In Koltrix, editing before approval can only remove proposed recipients, and adding one is refused. If a reviewer needs a new recipient, that is a new message, not an edit to something an agent proposed. Edits to the subject and body are re-checked before sending, and the message goes out under the name of the person who approved it.
Permissions matter here too. In Koltrix, approving and rejecting a send needs an owner or admin, while answering an agent's question or snoozing an item is open to any non-viewer member. Decide who your approvers are before you start, so the people who see the queue are the people allowed to clear it.
When should a pending approval expire?
Within days, not weeks. A reply that made sense on Monday can be wrong by the following Monday: the customer has been answered another way, the invoice was paid, the meeting time passed. An approval with no expiry turns a to-do list into a trap.
Koltrix expires pending approvals after 7 days: they leave the list, and approving an expired one is refused. There is also a cap of 100 open approval, question and escalation items per mailbox, so a flood of proposals cannot bury the ones that matter.
If you build your own approval step, set the expiry from the shortest time your replies stay true. For support mail that may be one or two days. For invoice reminders it may be a week. Whatever you pick, show the age on every item, and make an expired proposal disappear from the approvable list instead of staying clickable.
How do you keep approvers from clicking through?
Approval fatigue is real: when every proposal looks the same and there are fifty a day, people approve without reading. Guidance on agent autonomy from several vendors makes the same point, that approvals should scale with risk and reversibility and be targeted, not applied to everything. Practical ways to keep review honest:
- Send fewer, better proposals. If an agent proposes on everything, narrow its scope or its allowed senders.
- Put the risky ones first. Held-for-a-reason items should look different from routine ones.
- Sample, do not skim. Once a week, read five approved messages end to end and ask whether you would sign them.
- Track edits. If you edit most proposals, the agent's instructions or knowledge need work before you give it more freedom. A golden set for AI email drafts shows one way to measure that.
- Keep Auto narrow, if you use it at all. Auto in Koltrix is for agents you have watched in Suggest or Approve, and it is built to hold anything it is unsure about: it sends alone only when it is highly confident and grounded, to allowlisted recipients it already knows, inside a daily cap and optional quiet hours, with a 10-minute hold on identical messages. No approval process removes the need for judgment, so start at Suggest.
A checklist you can reuse
- The screen shows recipients, full text, the original message, the reason and the source.
- A held proposal says which rule held it.
- Approve, edit then approve, reject and snooze all exist.
- An edit can remove recipients, not add them.
- Only named roles can approve a send.
- Proposals expire, and the expiry is visible.
- Someone reads a sample of approved messages every week.
- One switch turns every agent back to the safest level.
Bottom line
The button is the easy part. A trustworthy approval step shows the recipients and the full message, explains why the agent wrote it and what it relied on, limits what an edit can change, and expires old proposals. Start every agent on Suggest, move to Approve when the drafts are consistently good, and treat Auto (Beta) as something to earn, not a default. You can see how Koltrix handles each level on the autonomy page and the injection shield page.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
