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: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: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.Related
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.

