The kill switch nobody else ships

Most products that let AI act on your behalf give you a list of automations and a switch beside each one. That is a reasonable way to configure which agents you want running. It is a bad way to stop them, and the difference shows up exactly when it matters.

Picture the moment a kill switch is built for. A reply comes in that should not have been sent. A contact says they already asked to be removed. A field on a record looks wrong and you do not know when it changed. You do not yet know which agent did it, whether more than one is involved, or whether the same thing is about to happen to the next two hundred records. What you need in that minute is for everything automated to stop while you look.

With per-agent toggles, that minute becomes a sequence of decisions. Find the settings page. Read the list. Decide which of these could be the cause. Switch them off one at a time, and hope you did not miss one. Every step is a chance to be wrong under pressure. The failure is not dramatic. It is quietly leaving one agent on because it did not look related, and finding out later that it was.

SalesCrew puts one control on the Agents page that stops every agent. It has an MCP twin, agent_set_mode, so the same stop can be triggered from Claude, ChatGPT, Cursor or any other MCP client, not only from the browser. That second part matters more than it sounds. If the only way to stop automation is a button in a web app, stopping depends on someone being logged into that web app. The twin means the stop is available from wherever the person who notices the problem happens to be working.

The scope of the stop is deliberately blunt. It applies to agents, not to people. A rep halfway through a reply keeps writing it. A manager moving a deal to the next stage still moves it. Manual paths never stop. SalesCrew applies the same principle to AI usage caps: when the AI allowance hits its hard stop at 100 percent, AI features stop and manual work continues. A safety control that also removes the team's ordinary tools is one people hesitate to use. A stop control people hesitate to use is worse than none, because it creates a false sense that stopping is available.

Underneath the switch is the record of what happened before it was pulled. Every tool call in SalesCrew is written to an audit log, with the actor recorded as a user, a token or an agent. Stopping the agents buys you time. The audit log lets you use that time, because it answers which agent touched which records and what the values were before. A kill switch without a log leaves you stopped and still guessing.

The order that works is stop first, diagnose second. Pull the switch as soon as something looks wrong, before you have a theory. Stopping is cheap and reversible. Letting an agent keep running for the ten minutes it takes to form a theory is not, because the volume an agent works at is the whole reason you gave it work. Nobody regrets stopping automation for a quarter of an hour.

Then read the audit log for the window in question, filtered by actor, and find which agent produced the action you noticed. The question becomes whether the agent's mode was wrong or its guardrails were. SalesCrew's modes are off, draft, review and auto. An agent that produced an unwanted external action while in auto usually belongs back in review, where a person sees the artefact before it goes out. If the problem was volume rather than judgment, the guardrails are the lever: minimum days between touches per contact, the per-cadence cap, the per-mailbox and per-domain daily caps, and the business-hours send window.

Turn agents back on one at a time, not all at once, starting with the ones whose actions are reversible. That order follows the default policy table. Research, enrichment, tagging and internal notes carry little risk if wrong. An external send cannot be recalled. Restore the harmless work first, confirm it behaves, and only then restore anything that leaves the building.

This control is worth building rather than assuming because it has to exist before you need it. Nobody adds a stop button during the incident it would have helped with. It is the same kind of decision as writing the audit log from the first tool rather than after the first surprise. Both are cheap while you are building and impossible to retrofit in the moment they become urgent.