AI SDR Kill Switch: Stop an Outbound Agent Without Stranding Your Replies
How many stop buttons an outbound agent needs, what keeps sending after you press one, and who answers the people who already wrote back.
Most teams find out whether their AI SDR has a kill switch on the worst morning of the quarter.
Somebody notices the agent has been congratulating forty prospects on an acquisition that happened to a different company with the same name, the Slack channel fills up, and three people go looking for the off button at once. One of them stops the agent process. The emails keep going out anyway, because step three of the sequence was scheduled in the sequencing tool on Monday and that tool has never heard of the agent.
The pages that rank for AI agent kill switches are written for security and platform teams, and the good ones agree on the shape. Have more than one switch, from a single agent up to a global stop. Keep the switch outside the agent, in a layer the agent cannot edit. Cap the risky actions so a runaway loop hits a ceiling. Log every stop. Rehearse it before you need it. We agree with all of that, and the outbound version of each idea is below.
None of them deal with the inbound side. An outbound agent is usually also the thing reading replies, so the moment you stop it, the prospects who said "sure, Thursday works" stop getting answers. That is the part this page cares about most. It builds on our MCP tool permission matrix for outbound agents, which decides what the agent can touch, and our guide to AI SDR approval queues, which decides what waits for a person.
Four stops, sized differently
A single big red button gets pressed too late. People hesitate to stop everything over one bad email, so they wait until there are thirty.
One prospect
Anyone on the teamThe most common stop by far. A rep sees a name in the queue they are already talking to, or a prospect replies with something odd, and that one person comes out of every sequence on every channel. It should take one click from the Slack card, with no ticket and no explanation required.
One campaign
Campaign ownerThe research behind a segment turned out wrong. A funding round was misread, or the list filter caught a whole industry you do not sell to. Everything in that campaign stops, including steps already queued for later in the week.
One mailbox
Whoever owns deliverabilityBounces climb on a single sending address, or Gmail starts throttling it. Pause that mailbox and leave the rest alone. Shifting its queue onto a healthy mailbox is how one bad address becomes two.
Everything
Two named peopleAll outbound sends, all enrollments, all LinkedIn actions. Rare, and it should feel rare. Writes that make the agent do less (suppressing an address, logging an unsubscribe) keep running even here.
Make the small stops cheap and nobody will ever need the big one.
The switch lives in the send tool
A prompt makes a poor off button. One that says "pause all outreach" works right up until a long-running session that loaded the old prompt an hour ago finishes its batch.
Our rule: every tool that puts words in front of a prospect (send, enroll, schedule, LinkedIn message) reads a pause flag from outside the agent on every call and refuses if any matching flag is set. Prospect, campaign, mailbox, global. The agent gets an error back and reports it in Slack. It cannot reason its way past a function that says no, which is the same reason the exclusion check in our AI SDR exclusion list guide sits in the send tool and nowhere else.
If the flag store cannot be reached, the tool refuses. A pause check that fails open is decoration.
What keeps sending after you press it
Our sequences run five to eight touches across email and LinkedIn. When the agent enrolls someone, most of those touches get handed to other systems with their own clocks, and pausing the agent does nothing to them.
Walk the list once, before the bad morning. Steps already scheduled inside the sequencing tool. Emails sitting in Gmail's scheduled-send folder. LinkedIn actions queued in whatever tool runs them. A retry that timed out at 9:02 and will try again at 9:07, which our permission matrix already warned can turn into a duplicate send. Your stop procedure has to pause each of those at its source, or the switch has to sit in front of every one of them, and in practice that means writing down the pause step for every tool by name, in the order you would do it.
Write the receipt, too. When a campaign stops, log what was pending, meaning every held email with the tool it was sitting in. The person restarting it next week will need that list and will not remember.
The replies you just orphaned
This is the gap in every kill switch guide we read, and for outbound it is the expensive one.
A pause should cut the agent off from sending and leave its inbox wide open. Replies keep arriving after a pause (some of them to emails sent days earlier, some of them to the bad email that caused the pause), and an interested prospect who hears nothing for a week does not stay interested. Our AI SDR reply handling guide sorts replies into categories. During a stop, keep the sorting and change where the results go.
Unsubscribes and "take me off your list" replies still get suppressed immediately, pause or no pause, because CAN-SPAM gives you 10 business days to honor an opt-out and a frozen agent does not stop that clock. Interested replies become Gmail drafts assigned to a named account owner, with a Slack ping, and they never send on their own. Angry replies to the bad email go to whoever pressed the switch, since that person knows what went wrong and can apologize specifically instead of generically. Out-of-office replies can wait.
Test this path separately. A global stop that also silences suppression is a compliance problem you created while fixing a quality problem.
Trips that should fire without a person
Some stops should not wait for anyone to notice. A short list, enforced server-side next to the daily enroll cap: a mailbox whose bounces jump within a single sending window pauses itself. A spam complaint rate that climbs past the 0.1% ceiling in our deliverability guide pauses the domain, well before the 0.3% where that guide says domain-level throttling becomes a risk. A CRM or suppression lookup that comes back empty pauses the campaign, because an empty answer from an expired OAuth token looks exactly like "nobody has opted out."
Two prospects replying "you already emailed me this" inside an hour is a duplicate-send bug until proven otherwise. Pause and look.
Who holds the global switch
Two named people, one of whom is awake when the other is not.
Restarting is a new decision
Do not resume a paused campaign by flipping the flag back. Everything queued before the stop was written from research that is now days old, and some of it was written by the same logic that caused the stop. Drafts that were waiting go back into the pool and get redrafted. Scheduled steps get reviewed against the receipt, prospect by prospect, and anyone who replied during the pause comes out of the sequence entirely, since they are now in a conversation with a person. The first day back runs at a fraction of normal volume, with every send going through the approval queue again, including categories you had already loosened.
Annoying. Worth it.
Rehearse on a quiet Tuesday
Once a quarter, pause a real campaign on purpose and time how long it takes until nothing more goes out, across every tool on your list. Then check that a test reply sent during the pause landed as a draft with the right owner. Most first rehearsals find one tool nobody wrote down.
Why we care
After the free pilot we get paid per qualified meeting, and a qualified meeting is one where the prospect shows up. A campaign that keeps sending a wrong fact for six hours burns prospects we can never email again, and an interested reply nobody answers during a pause is a meeting that would have paid. Both cost us money directly, which is most of why these rules exist.
Mira runs on OpenClaw from a Mac mini in San Francisco, so the pause flags, trip rules and stop receipts all live in config somebody maintains. The OpenClaw MCP Integration Kit ships twelve annotated MCP skill configs with a tool permission matrix and a troubleshooting runbook for auth failures, which is a reasonable place to write your stop procedure down next to everything else. The wider setup is in our outbound automation playbook. If you would rather someone else held the switch, here is how Mira works.