Skip to main content

The short answer

You can’t recall a sent email. SMTP has no undo button. Once the message hits the recipient’s mail server, it’s delivered. What you can do: send a correction immediately, audit what happened, figure out why, and build guardrails so it doesn’t happen again. Prevention is always cheaper than damage control.

You can’t unsend email

This is worth stating plainly because it changes how you architect agent email systems. Unlike a Slack message you can edit or a web page you can update, email is fire-and-forget. The recipient has a copy. Their mail server has a copy. Any forwarded recipients have copies. There is no API call that reaches into someone else’s inbox and deletes your message. Microsoft Outlook’s “recall” feature only works within the same Exchange organization. Gmail’s “undo send” only works for a few seconds before the email actually leaves Google’s servers. Neither helps you after delivery. This means your entire strategy must be weighted toward prevention, not remediation.

When it does happen: incident response

Despite your best efforts, an agent will eventually send something wrong. A hallucinated fact, a reply to the wrong thread, a tone-deaf response to a sensitive situation. Here’s the playbook.

Step 1: Detect

You need to know something went wrong before the recipient complains. Set up monitoring:

Step 2: Assess

Not every wrong email needs the same response. Classify the severity:

Step 3: Respond

For medium severity and above, send a correction in the same thread:
Keep corrections simple and direct. “Our previous email contained an error. [Correct information]. We apologize for the confusion.” Don’t over-explain that an AI wrote it unless your recipients already know.

Step 4: Prevent recurrence

After every incident, update your guardrails:
  • Add the failure pattern to your test suite
  • Tighten confidence thresholds if the agent was auto-sending
  • Add an escalation rule if the error category wasn’t covered
  • Update the agent’s system prompt to address the specific failure mode

Prevention layers

The best incident is the one that never happens. Stack these defenses:

Test mode

Before your agent goes live, run it in test mode where it drafts emails but doesn’t actually send them. Review a sample of drafts to calibrate quality.

Rate limiting

Commune enforces per-plan rate limits, but you should also set your own agent-level limits that are tighter than Commune’s. If your support agent normally sends 50 emails per hour and suddenly tries to send 500, something is wrong.

Human-in-the-loop

For high-stakes emails, route through an approval queue. See How do I add human approval before my agent sends email? for the full implementation.

Confidence thresholds

Only auto-send when the agent is confident. Route uncertain drafts to human review. This catches most quality issues before they reach recipients.

Auditing what was sent

When investigating an incident, you need the full picture. Use Commune’s message list API to pull everything your agent sent:
Pair this with your own audit logs that capture the agent’s reasoning — what context it had, what prompt it used, what confidence score it assigned. Commune’s API tells you what was sent. Your logs tell you why.

The honest truth

Giving an AI agent the ability to send email is a trust decision. The risk is real — a bad email can damage a relationship, create legal liability, or embarrass your company. But the risk is manageable with the right architecture: test mode first, approval queues second, gradual autonomy third. Every company that deploys agent email goes through the same progression: fully supervised, then supervised for edge cases, then autonomous with monitoring. The timeline depends on your risk tolerance and the quality of your guardrails. Don’t skip steps.

Human-in-the-Loop Approval

Pre-send approval flows, confidence thresholds, and escalation rules.

Preventing Data Leakage

Stop sensitive data from appearing in outbound emails.

Rate Limits

How Commune enforces sending limits to prevent burst damage.

Sending Messages

Full API reference for sending, listing, and retrieving messages.
Last modified on March 19, 2026