How do I stop AI from sending emails on its own?
Put every external send behind one review queue, add guardrails around it, and keep a single switch that stops every agent.
The short answer
- Put every external send an agent could take, including email, behind a review mode: the agent drafts the message, a queue holds it, and a person approves it before it leaves.
- Add guardrails around the queue itself: a minimum number of days between touches to the same contact, a daily send cap per mailbox, a business-hours send window, and a suppression check that runs again at the moment of send, not only when the list was built.
- Keep one kill switch that stops every agent at once, rather than a separate on/off toggle per agent that someone has to remember to flip when something goes wrong.
- A per-bot autopilot toggle is not a control plane. A control plane is one queue, one set of guardrails applied consistently, and one switch, with a log of what happened.
Why an on/off toggle does not actually solve this
Most tools that added AI features answer "can I stop it" with a toggle: turn the bot on, turn the bot off. That works until you have more than one agent doing more than one job, which is most real setups within a few weeks. At that point a toggle per agent means remembering which ones are on, and a mistake usually surfaces as "which one sent that," not as a clean stop.
The actual problem is not whether an agent can act. It is whether an external action, the kind a customer or prospect will actually see, happens before or after a person looks at it. A toggle answers "is the agent running." A review queue answers the question that matters: "did a person see this before it left."
The two are not the same thing, and conflating them is how teams end up with an agent that is technically "off" for one workflow while still auto-sending through another one they forgot was connected to the same mailbox.
Controls that actually stop an unwanted send
| Control | What it prevents | Where it applies |
|---|---|---|
| Review mode on external sends | A draft going out before a person reads it | Every agent, by default, for email, LinkedIn messages, SMS and marketplace proposals |
| Minimum days between touches | The same contact getting hit repeatedly in a short window | Per contact, enforced across every cadence step |
| Per-mailbox and per-domain daily caps | A burst of sends that damages deliverability or looks automated | Applied at send time, not only at list-build time |
| Business-hours send window | Messages landing at odd hours that make the sender look like a bot | Configurable per cadence or per instance |
| Suppression re-checked at send | A contact who unsubscribed or bounced getting a message anyway, even if they were added to a list earlier | Checked again at the moment of send, not only when the audience was built |
| One kill switch | Any agent continuing to act after something has gone wrong | Stops every agent at once, not one at a time |
What this looks like set up correctly
A working setup has one queue, not several. Every agent's draft, whatever kind of message it is, lands in the same place, shown with the evidence behind it: the thread it is replying to, the contact's history, why the agent chose to say what it said. A person approves, edits and approves, or rejects with a reason, and that reason feeds the next run so the same mistake gets caught earlier next time.
Underneath the queue, the guardrails apply the same way no matter which agent or which channel triggered the send: the touch spacing, the daily caps, the send window, and the suppression check happen automatically and cannot be skipped by one agent forgetting to check.
Disclosure: SalesCrew is our product, and this is how its agent policy is built by default. Every agent ships in review mode. Research, tagging, scoring and internal logging can run automatically; any external send, a stage change, or a contact merge or delete waits in one approval queue. A single kill switch on the Agents page stops every agent, and every tool call, whether triggered by a person, a token or an agent, is written to an audit log.
A per-bot toggle is not the same as a control plane
Questions
- Is a per-agent on/off toggle enough?
- No. A toggle stops one agent from running at all, but it does not stop a running agent from sending without review, and if you have several agents you need to remember to flip several switches. A single kill switch that pauses every agent at once is a different and more reliable control.
- Does review mode slow the team down?
- It adds one step: someone reads the draft before it goes out. Lower-risk actions, like tagging a contact or logging a note, can stay automatic while sends and stage changes wait for a person, so the review step lands only where a mistake would be visible to someone outside your team.
- What if the AI is only summarizing or scoring, not sending anything?
- Internal actions like summaries, scoring and tagging carry a different risk than an external send, since nothing leaves the building. Most approval-queue designs let those run automatically and reserve the review step for anything a customer or prospect would actually see.