# Should an AI agent send your emails? Ours did, once No, an AI agent should not be the part that actually sends your emails. Let the model draft and sort, then pass each message to a small, boring service that sends on a schedule and confirms every delivery. OCTYN learned this after a model driven sender built for a client reported a send that never happened. Date: 2026-09-25 Updated: 2026-09-28 Reading time: 4 min Author: OCTYN No. 02 The pitch for handing outreach to an agent is very tidy. It reads the lead, writes something warm, sends it and moves on to the next one while you sleep. What the pitch leaves out is the night it gets something wrong, because anything allowed to send is also allowed to send the wrong thing to the wrong person, and it will do so with complete confidence. OCTYN found that out by building one. It runs the outreach for [an independent craft retailer](/casestudies/craft-retail-brand-sales) that makes handmade goods and sells them to brands, and an early version handed the sending step to a worker driven by a model. It errored, and then it sent something it should not have. After that it reported a send that had never happened, so now the record was wrong as well as the inbox. ## Why sending is the wrong job for a model A lot of outreach genuinely needs something that can read. Deciding whether a company fits, and working out how to open a first email so it does not sound like a mail merge, are judgement calls. A model is decent at those. When it gets one wrong, there is still time for a person to notice before anything leaves the building. Sending has none of that slack. Once an email goes, it stays gone, and the only acceptable result is that exactly what sat in the queue went out, once, at the time it was meant to. There is nothing in that job to interpret. What it wants is a clerk, and the trouble with putting a model in the clerk's chair is that every so often it has a thought. So the send moved out of the clever part of the system entirely. The replacement is a small service with no model and no browser. Every sixty seconds it looks for jobs whose time has come, marks each one as it goes and posts a confirmation for every send. The mail credentials are not even stored on its disk; it fetches them when it runs. Of everything this retailer's outreach runs on, this is the dullest component, and it is the one trusted with the step that cannot be taken back. ## Where the judgement goes instead None of this means the drafting has to be dumb. The two halves of the system simply never talk to each other directly. At this retailer, the heavy work runs overnight, from finding brands to writing the drafts, while the always on half only ever reads a queue. They share one database and nothing else. The rules that decide things are plain code with tests beside them, so the same lead gets the same answer on Tuesday as it did on Monday. Where a lead is based, for example, is worked out from its currency, phone prefix and domain. That rule replaced a model's impression, which kept filing leads under the wrong market. A person still gets [the last look](/glossary/human-in-the-loop), though not one email at a time. For one of the retailer's markets nothing sends before one in the afternoon, so the owner can read the day's queue and pull anything that looks off before the sender reaches it. There is deliberately no approval button on each mail. At twenty five a day, a button like that becomes a reflex within a week. ## The sixteen minute save The best argument for this split arrived on 12 August. A lead had replied and named the person to talk to, and a proposal was already with that person. Then a step that reroutes idle leads noticed the original role inbox had gone quiet and queued a cold first touch to a third person at the same company. It was cancelled sixteen minutes before it would have gone. The send was a row in a queue. No agent was halfway through sending it, so cancelling meant changing one row. The rule that came out of it is short: once any human at a company answers, that company belongs to the conversation, and the cold sequence is over for everyone who works there. Every queued send can still be edited, moved or cancelled right up to its send time, and the row that sends is the edited row. A [rollback](/glossary/rollback) here is just an edit made in time, which is about as simple as that idea ever gets. ## So, should an agent send your emails Let it do everything up to the send. Give it the finding and the drafting, and let it be wrong in places where a person or a rule will catch the mistake. Then hand the sending itself to something that cannot be talked into anything, working from a queue a human can read, with a [dry run](/glossary/dry-run) before the first real message goes out. If an agent already sends on your behalf, there is a simple check worth doing this week. Ask it for its record of the last hundred sends and compare that with what actually landed in the recipients' inboxes. Ours once claimed a send that never happened. It is worth knowing whether yours ever has. ## Related **Systems this bears on** - [Growth Engine](https://octyn.co/systems/growth-engine) **Case studies cited** - [Brand sales for an independent craft retailer](https://octyn.co/casestudies/craft-retail-brand-sales) **Terms used here** - [Human in the loop](https://octyn.co/glossary/human-in-the-loop) - [Rollback](https://octyn.co/glossary/rollback) - [Dry run](https://octyn.co/glossary/dry-run) **The longer argument** - [Why your AI automation broke and nobody noticed](https://octyn.co/compare/ai-automation-failing-silently) **Read next** - [How to prevent accidental data deletion in automated systems: make it refuse](https://octyn.co/blog/how-to-prevent-accidental-data-deletion-in-automated-systems-make-it-refuse) - [Rollback plan for an AI workflow: what can still be put back after it acts](https://octyn.co/blog/rollback-plan-for-an-ai-workflow-what-can-still-be-put-back-after-it-acts) - [Monitoring an AI workflow without an engineering team starts with a morning read](https://octyn.co/blog/monitoring-an-ai-workflow-without-an-engineering-team-starts-with-a-morning-read) - [A founder time audit should count the questions only you can answer](https://octyn.co/blog/a-founder-time-audit-should-count-the-questions-only-you-can-answer) More on automation that holds up: [Automation that holds up](https://octyn.co/blog/topic/reliable-automation) Canonical: https://octyn.co/blog/should-an-ai-agent-send-your-emails