Agents need a queue, not a toggle
One on/off switch cannot tell a contact tag from an email send. A queue can, because it treats every action on its own risk, not the agent's risk in general.

The short answer
- A single global on/off switch cannot tell a low-risk action, tagging a contact, from a high-risk one, sending an email. Both run under the same setting.
- SalesCrew's default policy table sets the mode per action class instead. Research, tagging and scoring default to auto. Anything that leaves the building, or changes a stage, merges or deletes, defaults to review. Any spend is human-only in every mode.
- An approval queue adds friction only to the action classes it gates. Actions set to auto run with no queue at all, so the cost of review is paid only where the policy puts it.
- The queue is built to make review fast. One list grouped by agent, each item showing the artefact, the evidence behind it, a confidence score and a cost. Approving is a quick judgment, not a re-investigation.
What a single toggle actually controls
A global AI on/off switch is easy to build and easy to explain, which is why it is a common first version of AI controls. The problem is what it controls: everything the agent might do, at once, under one setting. Turn it on, and every action class runs unattended, tagging a contact and emailing a real person alike. Turn it off, and the agent stops doing the safe, cheap things too, such as research, summaries and internal notes. Nobody needed a human to review those.
The mismatch is between the granularity of the control and the granularity of the risk. An agent performs many kinds of actions with very different consequences when wrong. A mistagged contact is trivial to fix and invisible outside the team. A wrongly sent email has already reached someone's inbox by the time anyone notices. A single switch treats those the same, because it has no way to treat them differently.
Setting policy per action class instead of per agent
SalesCrew's default policy table sets the mode, off, draft, review or auto, per action class rather than per agent or globally. Research, enrichment, tagging, scoring, summaries and internal tasks default to auto, because a mistake there is cheap and contained inside the CRM. Classifying a reply, and suppressing a contact on unsubscribe or bounce, default to auto for the same reason. No external party is affected by either action running without a person looking first.
Anything that leaves the building defaults to review: an email, a LinkedIn message, an SMS, a marketplace proposal. So do stage changes and contact merges or deletes, because those alter shared records other people rely on. Any action that spends money, whether credits, connects or ad budget, is human-only in every mode. No setting lets it run unattended, however long the agent has been running cleanly.
Two actions in the default table, creating a deal from a positive reply and booking a meeting, may graduate from review to auto, but only after a clean week with no rejected items in that queue. Those two sit in a middle tier. They are real enough to start in review, and contained enough that a track record of accuracy can justify loosening the policy for that specific action, without touching anything else the agent does.
What the queue itself has to get right to be worth using
A policy that routes risky actions to review only works if reviewing is fast enough that someone does it consistently. If checking the queue takes as long as doing the task by hand, the policy becomes a bottleneck people route around, not a safety net they rely on. SalesCrew's approval queue is built to keep that cost low. One queue, grouped by agent. Each item shows the artefact itself, the evidence it drew on (a thread, a lead score, a knowledge-base source), a confidence number, and what it would cost to run. A reviewer can approve, edit then approve, or reject in the time it takes to read one screen. Nobody has to rebuild the agent's reasoning from scratch.
The test, for any team evaluating AI controls in a product, is whether the control is a single switch or a policy whose granularity matches the real spread of risk in what the agent does. A toggle is a reasonable start when an agent does one kind of thing. Once an agent's actions span internal housekeeping and external communication, a toggle is the wrong shape of control. A queue tied to a per-action policy is what the risk profile calls for.
Questions
- Why not only turn AI off for the risky parts and on for the rest?
- That is what a per-action policy does. A single global toggle cannot express it. One switch turns every action an agent does on or off together. So it either blocks safe actions like tagging a contact, or allows risky ones like sending an email, as a side effect of the same setting.
- Does an approval queue slow an agent down too much to be useful?
- For the action classes that stay in review by design, an external send, a stage change, a spend, yes, on purpose. A person sees the result before it happens. Everything set to auto, such as research, tagging, scoring and summaries, has no queue at all. The slowdown applies only where it is the point.
- Who decides which actions are safe enough to skip the queue?
- SalesCrew ships a default policy table, editable per instance in Agents → Guardrails, that sets the starting mode per action class. A team can tighten or loosen it from there. The default exists so nobody designs the policy from a blank page on day one.