Six things an agent should never do alone

Most arguments about what to let an AI agent do turn into arguments about how good the model is. That framing does not help you write a policy, because it has no stopping point: every model is better than the last one, and none of them are perfect, so the debate never resolves into a rule you can actually apply on a Tuesday.

The more useful question is what a wrong action costs to undo. Tagging a contact incorrectly costs a click. Enriching a record with a stale job title costs a correction. Emailing the wrong person costs an apology at best, and at worst it costs the relationship and a spam complaint that damages the domain everyone else sends from. The same model produces all three, so the model is not the variable. The action is.

SalesCrew encodes this as a default policy table, seeded on every instance and editable under Agents then Guardrails. The table sorts actions by class rather than by agent, which matters because the same agent will take actions of very different consequence within a single run.

1. Send anything outside the building. Email, LinkedIn messages, SMS and marketplace proposals all share one property: once delivered, they exist in someone else's inbox and no control you own can retrieve them. The review queue is not there because drafts are usually bad. It is there because the one time in fifty that a draft misreads the thread is the time you would want back, and you cannot have it back.

2. Delete or merge a contact. A merge is a decision about which history survives. Get it wrong and the notes, threads and deals attached to the discarded record go with it. This is the rare case where the reversal is not only costly but often impossible to do accurately, since reconstructing which note belonged where is guesswork after the fact.

3. Move a deal between stages. This one surprises people, because it looks purely internal. It is on the review list precisely because it is internal: a bad email gets a reply that tells you it was bad, while a deal quietly moved to the wrong stage just changes a number in a forecast that nobody questions until the quarter ends.

4. Spend money. Credits, marketplace connects, ad budget. This class has no automatic mode at all in the default policy, not even a reviewed one, because spending is the action where a loop bug is most expensive and least self-limiting. An agent stuck retrying a send wastes an allowance; an agent stuck retrying a purchase wastes a budget.

5. Act outside the CRM. Every control described here, the approval queue, the guardrails, the audit log, the kill switch, applies to actions taken through the CRM's own tools. An action taken somewhere else is outside all of them. That is why anything beyond the CRM's boundary is human-only: not because the action is necessarily dangerous, but because none of the safety machinery reaches it.

6. Decide it is confident enough. The last one is less an action than a judgement. SalesCrew's auto mode falls back to review when confidence sits below a threshold, and the threshold is set by a person rather than by the agent. An agent that grades its own certainty and acts on that grade has effectively been given permission to promote itself, which removes the human from the loop by a side door.

None of this is permanent. The default policy table is editable, and one row in it, creating a deal from a positive reply or booking a meeting, is written as review first and auto after a clean week. That phrasing is the honest general pattern: move an action to auto after you have watched it in review long enough to know its failure modes, not because you expect it to behave.

What makes that safe is that every tool call is written to the audit log with the actor recorded as a user, a token or an agent, so "a clean week" is something you can check rather than something you feel. And the kill switch on the Agents page stops every agent at once if the promotion turns out to be premature, which is what makes trying it a reversible decision instead of a bet.

The two rows that should stay put are spending and acting outside the CRM. Every other line can be argued about with evidence in hand. Those two are not about trust in the agent; they are about the limits of what the surrounding controls can see and stop.