THE AGENTIC SALES BRIEF / SYSTEM 06
An AI sales agent should not gain authority because its output sounds finished.
Drafting, approving and sending are three different permissions. A reliable system treats them separately:
agent drafts → evidence is checked → named human approves → approved channel sends → action is logged
That rule is necessary but not sufficient. Some content should remain prohibited even when a model can generate it and a tool can deliver it.
This playbook defines the deny list.
If your team has not yet mapped the full operating loop, begin with Start Here. The boundary in this article assumes that data, decision rights, review and measurement already have named owners.
SYSTEM DEFINITION — CONSEQUENCE DEFINES PERMISSION A model may help create an internal draft. It does not gain authority to create an external consequence. Research, drafting, policy, approval and sending remain separate permissions.
Start with a three-level permission model
Every customer-communication action belongs in one of three states.
Allowed to draft
The system may prepare content from approved inputs, preserve sources and clearly label uncertainty. A draft has no external effect.
Human approval required
A named, authorised person must see the final recipients, content, evidence and consequences before the send or change. Approval applies to that exact version, not future variants.
Prohibited
The system must not generate for external use or send the content, regardless of a timeout, confidence score or workflow pressure. A policy owner—not the model—changes this status through a documented review.
Use deny by default. If an action is not explicitly allowed, pause it.
The policy must live outside the prompt. A model can classify a proposed action and explain why it may be risky, but a deterministic control decides whether the action can enter review. Only the approved sending identity can execute it.
Approve the inputs and control services
A send workflow should receive only:
approved account and contact fields
the current suppression and channel-eligibility result
official or otherwise approved research sources
a versioned offer and claims library
the exact message template or drafting instructions
the named reviewer and permitted sending account.
Treat the tools as replaceable control services: retrieval, claim checking, policy evaluation, human review, approved sending and evidence logging. The research and drafting components do not need permission to send. The sending component does not need broad CRM-write access. Credentials should be scoped to the smallest account, object and action set the workflow needs.
If a source, suppression control, claims library or reviewer identity is unavailable, the missing input is a stop condition—not permission to guess.
The minimum architecture is:
approved sources + CRM fields + suppression state
↓
internal draft
↓
deterministic permission check
↙ ↓ ↘
draft allowed human gate send prohibited
↓
exact-version approval
↓
restricted sender + log
1. Unverified factual claims
Never send a material statement about the prospect, your company, a customer, a product or a market unless the workflow can show adequate support.
Examples:
“Your team is expanding into Germany” based only on an old job page
“We reduced sales cycles by 40%” without approved evidence
“You use Salesforce” inferred from a third-party list
“Your CEO said…” without the actual source.
Require a claim record with source, retrieval date, evidence location and status. If support is missing, remove the claim or turn it into an honest question.
An account research agent that cites every claim can prepare this evidence layer. Its output is still an input to review, not permission to send.
The US FTC's advertising guidance says advertising claims must be truthful, not misleading and evidence-based. That principle still matters when AI drafts the copy.
2. Fabricated familiarity or relationships
Never let a system pretend that the sender:
attended an event they did not attend
read content it did not retrieve
shares a mutual connection that was not verified
remembers a conversation that is not in the authorised record
knows a person's priorities from a generic signal.
Personalisation should explain relevance, not simulate intimacy.
Use explicit phrasing when the evidence is indirect:
Your company announced X. I wondered whether Y is a current priority.
Do not convert that into:
I know Y is keeping you up at night.
3. Sensitive personal data or inferred traits
Never include sensitive personal information, inferred protected characteristics or irrelevant private details in a sales message.
Examples include health, political views, religion, sexual orientation, ethnicity, financial distress or family circumstances. Public availability does not automatically make the information appropriate for sales use.
Use company-level and role-relevant information wherever possible. Apply purpose limitation and data minimisation. GDPR Article 5 makes those explicit principles when personal data is processed, alongside accuracy and other obligations.
If a workflow encounters sensitive data unexpectedly, it should exclude it from the output, limit the log and flag the source for review.
4. Prices, discounts, terms or commitments without authority
Never allow a model to invent or approve:
price or discount
payment, renewal or cancellation terms
implementation scope
delivery date or service level
contract language
refund or remedy
product capability commitment.
The system may retrieve approved, current commercial information for an authorised seller. The seller still confirms that the offer applies to this account and version.
Put a structured approval before any message containing a commercial commitment. The approver needs the source, version and account context—not only the generated sentence.
Re-check the authoritative record immediately before release. A draft can be accurate when it is created and wrong when it is sent. If price, scope, availability, contract version or approver authority changed, fail closed and request a new review.
5. Legal, compliance or security guarantees
Never send absolute statements such as:
“This makes you GDPR compliant.”
“Our system is completely secure.”
“There is no legal risk.”
“The AI Act does not apply to you.”
“Your data never leaves the region” without verified architecture and terms.
Approved factual descriptions may be used when their scope and source are clear. Guarantees and legal conclusions require the authorised subject-matter process.
The EU AI Act includes human-oversight requirements in Article 14 for high-risk AI systems as defined by the Act. That does not mean every sales assistant is automatically high-risk, and a generic sales workflow cannot determine a buyer's legal classification.
6. Unsupported performance and customer claims
Never manufacture:
customer names, logos or quotes
conversion, revenue or productivity results
rankings or superiority claims
case-study details
“typical” outcomes without a defensible basis.
Keep an approved claims library with:
exact wording
evidence owner
applicable product and version
geography or audience limits
expiry or review date
required disclaimer.
If the claim is not in the library, the agent can request review. It cannot improvise proof.
7. Discriminatory or high-impact decisions disguised as sales operations
Never let a sales agent make or communicate a consequential decision about a person based on protected, sensitive or irrelevant characteristics.
Do not use inferred traits to exclude, rank, price or pressure individuals. Do not let a model silently disqualify or deprioritise a buyer when the decision could affect access to an important opportunity or service.
For ordinary B2B qualification, use transparent company and business-fit criteria. Preserve the reason, allow correction and route unusual cases to a human.
If the use case could become a high-impact or regulated decision, stop the sales-workflow pilot and obtain the appropriate legal, risk and domain review.
8. Messages that bypass channel, consent or suppression controls
Never send when:
the recipient is suppressed, opted out or otherwise ineligible
the source or lawful operating basis has not been assessed where required
the sender identity or header information is misleading
the required opt-out mechanism is absent
the platform or account policy prohibits the action
a duplicate or previous-send state is uncertain
the final version has not been approved.
The FTC's CAN-SPAM guidance applies to commercial email, including B2B email in the United States. ICO guidance describes separate UK rules and data-protection considerations for electronic marketing. Other markets and channels differ. Build the applicable controls outside the model and verify them before the send action becomes available.
The system must also block ambiguous operational states. A queued message, recent contact, open opportunity, ownership conflict or uncertain delivery result can turn an otherwise acceptable draft into a duplicate or contradictory action. The CRM and messaging provider—not the model's conversational memory—are the authoritative state.
A practical permission matrix
External consequence is the boundary. Any material change invalidates approval.
Communication action | Agent | Human reviewer | Policy owner |
|---|---|---|---|
Retrieve approved company facts | May perform | Reviews exceptions | Defines sources |
Draft from approved facts | May perform | Reviews final wording | Defines templates |
Label an inference | May perform | Decides whether usable | Defines standard |
Select a recipient | May recommend only | Confirms eligibility | Defines criteria |
Change price or terms | Prohibited | Requests authorised process | Sets authority |
Make a legal/compliance guarantee | Prohibited | Escalates | Sets policy |
Override suppression | Prohibited | Prohibited | Formal exception process only |
Final customer send | Prohibited in pilot | Performs exact-version send | Defines later maturity gate |
Do not encode human review as a decorative checkbox. The reviewer must have the authority, evidence, context and time to say no.
HUMAN GATE — APPROVAL BELONGS TO ONE EXACT VERSION The approval object binds the recipient, channel, evidence, final rendering, attachments and timing. Any material change invalidates it and returns the action to review.
Build the approval packet
Before a customer-facing send, show:
recipient and account
channel and campaign purpose
eligibility and suppression result
final subject and message
material claims with source status
commercial commitments and source version
personal data used
model/workflow version
draft changes since prior approval
reviewer decision and timestamp
Any material edit after approval invalidates the approval. Run the changed version through the gate again.
For a bounded way to test this control with a small cohort, use the human-in-the-loop outbound test. Keep the final send manual until the team has evidence that the gates work under failure, not only during the happy path.
Make failures stop the workflow
Failure | Required response |
|---|---|
Source unavailable or stale | Remove the claim or pause for review |
Entity match uncertain | Block personalisation and send |
Suppression service unavailable | Block send |
Approved-claims library unavailable | Block affected claims |
Reviewer times out | Keep as draft; do not send |
Content changes after approval | Invalidate approval |
Sending API returns uncertain status | Freeze retries; resolve duplicate risk |
Policy violation detected after send | Stop the workflow, preserve evidence and follow incident procedure |
Reliability means the safe state survives an outage. A system that sends when a control is unavailable has inverted its priorities.
Log enough to reconstruct the decision
Record:
run and message IDs
input sources and approved claims
eligibility and suppression checks
generated and final versions
reviewer, decision and material edits
send attempt and provider result
overrides, exceptions and incidents.
Protect the log. Do not store credentials or unnecessary personal data. Restrict access, define retention and make the record tamper-evident where the risk warrants it.
Measure:
prohibited content caught before send
unsupported claims per draft
reviewer correction and rejection rates
review time
suppression and wrong-recipient incidents
duplicate or unapproved sends
complaints and opt-outs
qualified conversations from approved messages.
Zero incidents does not prove the system is safe if the test never exercised failure states. Test blocked paths deliberately with synthetic, non-customer fixtures in a non-sending environment.
PROOF STANDARD — TEST THE BLOCKED PATHS Seed unsupported claims, stale prices, suppressed recipients, sensitive traits, fake familiarity, duplicate actions and post-approval changes. The expected result is a deterministic block or named escalation.
Track false blocks too. A control that stops legitimate work every time will be bypassed. Improve source quality, authoritative records and the review interface before weakening a prohibition.
Define the kill switch and shutdown path
One named owner must be able to:
disable all triggers and pending sends
revoke model, CRM, enrichment and email credentials
freeze automatic retries
identify every message state
preserve logs and approved versions
apply suppression updates
return the team to the manual process.
Test the switch before live use and after material integration changes.
The pre-send deny-list check
Do not send if any answer is yes:
Is a material fact unsupported, stale or contradicted?
Does the message imply familiarity or a relationship that was not verified?
Does it use sensitive or irrelevant personal information?
Does it introduce an unapproved price, term, deadline or capability?
Does it make a legal, compliance or security guarantee?
Does it contain an unapproved performance or customer claim?
Does it use a discriminatory or opaque high-impact decision?
Is eligibility, suppression, duplicate state or exact-version approval uncertain?
If none applies, the message may proceed to the named human gate. That is not the same as automatic permission to send.
Build the permission model before the integration
The free Agentic Sales System Starter Kit gives you the Permission Map, Human Gate, Failure and Fallback sheet and Evidence Record used in this design.
Define the hard boundary before you connect the sender.
Sources and further reading
This article provides general operational information, not legal advice. Obtain qualified legal, privacy, security or compliance review for the laws, markets and high-impact uses relevant to your organisation.
Build systems your team trusts—and your pipeline can prove.
