THE AGENTIC SALES BRIEF / SYSTEM 09
A prospect's company announces a new partner programme. An AI assistant turns that into: “I've been following your journey, and I know scaling partner revenue is keeping you up at night.”
The announcement may be real. The relationship and the diagnosis are invented.
That is the problem this playbook solves: turning legitimate business context into a useful first message without overstating what the seller knows. The output is a short draft with an evidence card, a clear reason for contacting this role and a decision to approve, revise or stop.
For a lean B2B team, the aim is to reduce the work of preparing an honest, relevant message. More personal details are not the objective. A message can name a real event and still have no useful connection to the recipient's work.
SYSTEM DEFINITION / Relevance with a boundary A personalization system connects a checked business fact to a plausible work question and an approved offer. It keeps those three things separate. The agent prepares the connection; the account owner decides whether it is worth making.
This is one bounded workflow within the Agentic Sales Systems Playbook. The model below is a proposed operating design, not a measured claim that personalization improves replies or revenue.
The signal: a real fact can support a false message
A citation cannot carry more meaning than its source. A job advertisement for a sales operations manager establishes that an employer advertised a role. It does not establish that its CRM is broken, that a particular executive owns the issue or that it has budget for your service.
Generative AI adds another source of uncertainty. NIST's Generative AI Profile describes confabulation as confidently presented false or erroneous content, including misleading supporting logic or citations. That is a documented risk, not evidence that every generated message is wrong.
Use a practical test: Could the recipient reasonably ask, “How would you know that?” If the answer requires a leap beyond the source, rewrite the statement as a genuine question or remove it. Adding “probably” to a speculative accusation rarely makes it useful.
Three distinctions matter:
Business fact: the company announced a partner programme.
Work hypothesis: partner lead handoffs might require attention.
Personal assertion: this executive is frustrated by handoffs.
Only the first is established by that announcement. The second may justify a question if the role and offer fit. The third needs evidence you do not have.
The system: build one evidence card before one draft
The user is a founder, account executive or SDR preparing an individual message. The sales leader owns the message standard and approves the eligible audience. A named operator owns source access, logging and failures; in a small team, the founder can hold both roles.
Start with existing approved tools: a CRM view or minimal export, a browser or licensed research source, an AI workspace approved for the data involved, and a document or review queue. The pilot needs no sender integration. CRM access is read-only; the agent writes only to the review queue. An approved offer sheet supplies what the seller actually provides and may promise.
An account research agent that cites every claim can supply the source record. This playbook handles the next decision: which part of that research belongs in a message, and how strongly it can be stated.
1. Confirm eligibility before collecting more detail
The operator starts from the team's approved account and contact list, current suppression information and applicable channel rules. The model does not decide whether a person may be contacted. Unknown eligibility is a hold, even when an excellent business signal exists.
Public availability is not blanket permission. The UK ICO's B2B marketing guidance says that UK GDPR obligations can apply to business contact data and that public data does not imply agreement to marketing. The page is under review following the Data (Use and Access) Act. Treat it as UK guidance with that stated limitation, not a global sending rule.
For US commercial email, the FTC's CAN-SPAM guide explicitly includes B2B messages and requires, among other things, accurate headers, non-deceptive subjects and opt-out handling. Your compliance owner must check the actual countries, recipients and channel. This playbook provides general operational information, not individual legal advice.
2. Capture the smallest useful source record
Use company announcements, current product documentation or an authorised record of a previous business conversation. Prefer a primary source over an aggregator's summary. Do not collect private social details, family circumstances or inferred sensitive traits to manufacture a hook.
The evidence card needs:
account identity and confirmed business domain;
intended recipient's current business role and its source;
one business fact, source URL or authorised record ID, and exact supporting location;
event date, source date when available, and retrieval date;
what the source does not establish;
relevance hypothesis, approved offer reference, owner and review status.
Keep the dated claim precise. “Announced on 3 September” can remain an accurate historical statement even when “is launching now” would be stale. Reopen time-sensitive sources before approval. If a deadline has passed, a role has changed or sources disagree, hold the contextual claim until the discrepancy is resolved. Set freshness rules by signal type instead of treating every fact as valid for the same number of days.
The ICO's accuracy guidance distinguishes facts from opinions and stresses making the source and status of personal data clear. This ICO page also carries an under-review notice. Our application is an explicit separation of checked facts, unconfirmed interpretations and missing information in the evidence card.
3. Choose the strongest justified level of relevance
Use one of three routes.
Account-specific: a current source supports a business event, and the recipient's role has a plausible connection to the work involved. State the event narrowly, then ask about the work.
Role-specific: the role is verified, but there is no reliable account signal. Use a transparent question about that responsibility. Do not decorate the message with an unrelated award or an old social post.
No draft: identity, eligibility, relevance or offer fit is unresolved. Return the missing item to the owner. The workflow has completed correctly when it stops a weak message.
This routing is an editorial proposal. It does not claim that account-specific messages always outperform role-specific ones. Sometimes a concise role question is the most accurate message available.
4. Draft the observation, question and offer separately
Ask the model for three short parts plus the evidence card. The observation describes what the source supports. The question makes uncertainty explicit. The offer describes a real resource or service from the approved offer sheet.
A model with native citations can make source inspection easier. Anthropic documents citations that link generated text to locations in supplied documents. This is a documented product capability, not a guarantee that the seller's inference is sound. A human still checks whether the cited passage supports the precise wording. This playbook does not require that vendor or an API integration.
Use this drafting instruction:
Use only the approved evidence card and offer sheet.
Return: decision, observation, work question, offer, evidence IDs.
Separate source facts from our hypothesis.
Do not invent familiarity, pain, intent, budget or results.
If a required input is missing, return HOLD with the missing item.
Do not contact anyone, enrol a sequence or update the CRM.
The instruction helps define the task; access controls enforce the action boundary. A prompt alone is not a permission system.
A worked example: remove the invented relationship
The following is a fictional training example, including the company, offer and evidence. It is not a customer case or an observed result.
Assume Northstar Analytics has published a dated announcement of a partner programme. Its current company page identifies a Head of Partnerships. The seller's approved offer is a workshop that maps partner lead handoffs, including ownership and acceptance criteria. No revenue outcome is promised.
Rejected draft: “I've followed Northstar for years. Your exciting growth must be creating chaos in partner handoffs. We can fix that fast.”
The source supports none of the claimed history, internal chaos or speed of improvement. Removing the enthusiasm would not fix the underlying problem.
Reviewable draft: “Northstar's September announcement describes a new partner programme. Is defining who accepts a partner lead part of your remit? We run workshops to map that handoff and its acceptance criteria. Would a short outline be useful?”
The reviewer can identify each component: a dated announcement, an honest role question and a bounded offer. The message does not say that Northstar has a broken process. The example shows a message body only; the normal approved channel must add the required sender and opt-out elements.
If the announcement cannot be verified: “Does your partnerships remit include the handoff of partner leads to sales? We run workshops to map ownership and acceptance criteria for that handoff. Would a short outline be useful?”
Use this role-specific fallback only when the role, offer fit and contact eligibility have passed review. If they have not, produce no message. Do not replace a missing fact with a vague claim about “companies like yours”.
Fallbacks deserve the same scrutiny as personalised fields. For example, HubSpot's documentation, updated 10 September 2026, describes global and message-specific defaults and requires fallback values for marketing-email personalization tokens. That is documented vendor behaviour, not a quality check on the resulting sentence. Preview every fallback path in your own approved tool.
HUMAN GATE / Approve the exact message The reviewer checks recipient, source, strength of wording, role relevance, offer and current contact eligibility together. Approval belongs to this message version and recipient. A changed claim, recipient, attachment or offer returns to review. The agent then stops; a separately authorised human handles sending.
The guardrail: keep research content out of the control path
The agent may retrieve from approved sources, extract a narrow fact, propose a work question and save a draft for review. It may not send, enrol recipients, discover extra contacts beyond scope, overwrite CRM facts, promise discounts or infer personal vulnerabilities.
Websites and retrieved documents are untrusted inputs. OWASP's prompt-injection guidance describes how external content can redirect a model's behaviour. In this design, source text must never grant tool access, change the approved offer or instruct the agent to message someone. Keep sender credentials outside the workflow and enforce the source and write destinations in the integration layer.
Minimise what reaches the model. Send the necessary business excerpt and record identifiers, not the full CRM history or mailbox. Check provider access, retention and processing terms before using personal or confidential data. Restrict the evidence queue to the team that needs it, and set a retention period with the data owner. Avoid recording raw sensitive content in error logs.
Give failures visible states:
SOURCE_UNAVAILABLE: retry a transient read once, then hold; do not substitute model memory.
SOURCE_CONFLICT: show the disagreement to the owner; do not silently choose the convenient version.
IDENTITY_UNCERTAIN: stop until the company and role match.
UNSUPPORTED_CLAIM: remove or revise the claim and require another review.
ELIGIBILITY_UNKNOWN: stop; no draft is eligible for sending.
Log the run ID, account ID, source references and timestamps, model/prompt version, draft version, decision reason and reviewer. A retry updates the same review item rather than creating another queued action. Use an account-and-purpose identifier to prevent duplicate work.
If a bad draft escaped review, freeze related queue items, correct the evidence and identify any affected approved versions. A human decides whether any external correction is necessary. Never let the agent send an apology automatically.
To switch the system off, disable its trigger, revoke its source connector or workflow credential, freeze pending drafts and record who owns the manual queue. Remove retained material according to the agreed policy. If a downstream sender exists elsewhere, its owner must separately pause any queued messages; disabling research does not cancel them.
The proof: measure relevance and review effort first
Run the first evaluation without sending. Use a small, fixed set of eligible historical or fictional cases that includes good signals, missing sources, changed roles and conflicts. Have a reviewer label the acceptable facts and the expected route before comparing drafts. This gives you something more useful than the model rating its own work.
Record five measures:
Supported-claim rate: supported factual claims divided by all factual claims in reviewed drafts. Also report the raw unsupported count; a high average cannot excuse an invented relationship.
Relevance acceptance: drafts the reviewer judges useful for the confirmed role and offer, divided by all reviewed drafts. Keep this separate from factual accuracy.
Hold correctness: expected hold cases actually held, plus acceptable cases held unnecessarily. A system that stops everything is safe from sending but provides little value.
Total human effort: research, source checking, rewriting and approval time per usable draft, compared with the current manual process on comparable cases.
Critical failures: any suppression bypass, wrong recipient, invented relationship, sensitive inference or unsupported offer promise. Any occurrence pauses expansion and triggers investigation.
PROOF STANDARD / A fluent draft is not a result Passing the offline review permits consideration of a controlled pilot. It does not establish higher reply rates, buyer trust or pipeline impact. Those outcomes need separately approved live activity and a defined comparison.
If the owner later authorises a live test, use the human-in-the-loop outbound experiment. Keep audience, offer, sender, channel and observation window stable; change the preparation method. Define a qualified conversation before results arrive. Report delivered messages, relevant replies, qualified conversations, objections and opt-outs with their denominators. Small counts are operational learning, not proof of a universal uplift.
The playbook: review one evidence card this week
Choose a message your team already has a legitimate reason to prepare. Confirm its owner and eligibility, record one business fact and its limits, and write one question the source cannot answer. Then connect that question to an offer you can substantiate.
Have a second person inspect the evidence before polishing the copy. If they cannot explain the relevance, return to the card. If the source is weak, use the role route or stop. Record what changed and how much review effort it required.
The useful output is a message the seller can explain, together with a record of why it is appropriate for this recipient. Familiarity is optional. Accuracy, relevance and permission are required by this operating design.
Scope this workflow with a named owner, a human gate, a manual fallback and a 30-day test using the Starter Kit.
Build systems your team trusts—and your pipeline can prove.
