How do I set guardrails for sales AI?
Enforce guardrails in the system, not the prompt. Minimum days between touches, daily caps per mailbox and domain, business-hours windows, suppression re-checked at send, and a confidence floor below which the action goes to review.
The short answer
- Enforce guardrails in the system that executes the action, not in the prompt that instructs the model. A cap, window or check written into code cannot be talked around the way an instruction in a prompt sometimes can.
- A working starting set covers five things. A minimum number of days between touches to the same contact. Daily send caps per mailbox and per domain. A business-hours send window. A suppression check that runs again at the moment of send. A confidence threshold below which the action routes to review.
- These guardrails apply the same way whichever agent or cadence triggered the action. They are not settings an individual agent can be configured to skip.
- A guardrail the agent can be told to ignore, because it lives in the prompt rather than the system, is a suggestion, not a guardrail.
Why the prompt is the wrong place for a hard rule
It is tempting to write guardrails as instructions. "Never email the same contact twice in one week." "Only send between 9am and 5pm." These read like rules, and a model following them carefully will usually respect them. The problem is "usually". A long conversation, an ambiguous edge case, or an instruction elsewhere in the same context that conflicts with the rule can all produce an exception the prompt did not anticipate. None of that requires the model to be malicious, or even wrong in a way anyone would call a bug. It is how instructions in natural language behave under pressure.
A guardrail enforced in the system that executes the send does not have this problem. If the code checks "has three days passed since the last touch to this contact" before allowing a send, that check runs whatever the model decided, whatever the prompt said, and however the conversation got there. The model can recommend a send. The system decides whether it is allowed to happen.
A starting guardrail set
Values here are a reasonable starting point, not a fixed standard; tighten or loosen based on your own reply and complaint data.
| Guardrail | Value to start with | What it prevents |
|---|---|---|
| Minimum days between touches | 3 days per contact | The same contact getting hit repeatedly in a short window |
| Daily send cap per mailbox and domain | Set per sender based on account age and reputation | A burst of sends that damages deliverability or reads as automated |
| Business-hours send window | Configurable per cadence or instance | Messages landing at odd hours that make the sender look like a bot |
| Suppression re-checked at send | Every send, not only at list-build time | A contact who unsubscribed or bounced getting a message anyway |
| Confidence threshold | Below the threshold, route to review instead of auto-send | A low-confidence draft going out unattended |
Making guardrails visible, not only enforced
A guardrail that silently blocks a send without telling anyone creates its own confusion. A rep will eventually ask why a follow-up never went out. The useful version surfaces the block. This contact was skipped because of the three-day rule. This draft was held because its confidence was below the threshold. That visibility turns a guardrail from an invisible constraint into something the team can reason about and request changes to.
Disclosure: SalesCrew is our product, and this exact set of guardrails ships as the default and is editable in Agents → Guardrails. Minimum days between touches, per-cadence caps, per-mailbox and per-domain daily caps, a business-hours send window, suppression re-checked at send, and a confidence threshold that routes low-confidence actions to review. None of it lives in a prompt an agent could be argued out of.
A guardrail the agent can be told to ignore is a suggestion
Questions
- Why do guardrails belong in the system rather than the prompt?
- A prompt is an instruction the model can be talked out of, by an ambiguous request, a long conversation that drifts, or a user asking it to ignore prior instructions. A guardrail enforced in code, like a hard cap the system checks before a send is allowed, does not depend on the model choosing to comply.
- What is a reasonable starting cap for touches per contact?
- A minimum of three days between touches to the same contact is a reasonable starting point. Tighten or loosen it based on your own reply and complaint data over time. The number matters less than that it is enforced automatically across every cadence step, not tracked by hand.
- Should guardrails be visible to the sales team, or just to the system?
- Visible. A team that can see the caps and windows in place can reason about why an agent held back a send. They can ask for a specific guardrail to be adjusted rather than assuming the agent malfunctioned.