Build the control system before AI drafts the message.

This page is an implementation specification, not a promise that automation will create meetings. The companion field note, AI-assisted B2B outreach starts with evidence—not volume, explains the principles. This playbook defines the records, gates and failure behavior needed to operate those principles.

1. Set the operating boundary

The first release supports a small number of researched, person-to-person reaches. It does not buy or scrape a list, run unattended sequences, impersonate Tony, auto-reply, or grant a tool standing permission to send.

AI may

• Organize approved account information and source links.
• Separate observed facts from inference and missing information.
• Compare an account with an approved customer profile.
• Draft short message options from cited evidence.
• Recommend a next action, confidence level or stop decision.

A person must

• Select the account and contact.
• Confirm that the source is permitted, current and relevant.
• Choose the channel, timing and message.
• Approve the exact recipient and exact final copy before sending.
• Send or explicitly authorize one bounded send.
• Own replies, objections, opt-outs and relationship decisions.

No approval is implied by a draft. No send is implied by an approval request. No reply is delegated to AI.

2. Require a bounded input contract

The workflow should refuse to draft when the required record is incomplete. Each target-account record needs:

• Account identity: company name, official website and stable internal ID.
• Reason in scope: the approved customer-profile condition that made the account relevant.
• Contact identity: name, role, company relationship and the evidence supporting that role.
• Permitted sources: source URL, page title, publisher, observed or published date, capture date and owner.
• Evidence ledger: each fact, its source ID, verification state and last-reviewed date.
• Uncertainty: explicit inferences, unknowns, conflicting records and confidence.
• Contact context: channel, prior relationship, permission status, suppression status and applicable internal policy.
• Ownership: human owner, current state, next action and due date.

Verification states

Use a controlled vocabulary rather than letting prose blur the evidence:

• Verified: supported by an approved source and reviewed by a person.
• First-party documented: stated by the company or contact in an attributable public source.
• User-provided: supplied directly but not independently verified.
• Inferred: a hypothesis that must be phrased as a question, never as a known problem.
• Unknown: missing or conflicting information.
• Retired: no longer current and excluded from drafting.

Confidence is not evidence

Confidence describes how dependable the available record appears; it does not upgrade an inference into a fact. The output should explain why confidence is high, moderate or low and name the missing information that would change it.

3. Use an inspectable state machine

Every record should occupy one explicit state:

Candidate → Researching → Evidence review → Ready for human review → Approved → Sent → Replied, paused, opted out or closed.

AI may move work into research or review queues. Only Tony, or a specifically authorized human, may move it into Approved. A delivery receipt may record Sent; it cannot create approval retroactively.

Step A: define the daily boundary

Set the target market, allowed channels, permitted sources, owner and a conservative daily cap before research begins. If no cap is approved, the permitted send count is zero. Do not add volume simply because the software can process it.

Step B: collect only approved public data

Use public pages and approved providers within their terms. Do not collect private information, evade access controls or treat a publicly visible email address as permission to contact.

Step C: create a source-backed account brief

The research output should contain facts with source IDs, inferences, contradictions, missing fields, confidence, research date and the question that would test the account hypothesis.

Step D: validate before drafting

Check identity, role relevance, source recency, suppression status, prior contact and whether a responsible reason to reach out exists. A failed check moves the record to Paused; it does not ask the model to write around the problem.

Step E: create a structured draft

The model returns a schema, not free-form sales copy:

• Proposed subject and message.
• Reason for contact.
• Every factual observation with its source ID.
• Assumptions and missing information.
• Confidence and explanation.
• Required consent or opt-out language.
• Recommended decision: review, revise or stop.
• Prompt version and generation timestamp.

Step F: review, send manually and record

Tony reviews the recipient, evidence, tone, claim boundaries, channel and timing. In the first release, Tony sends the approved message manually and records the provider message ID or equivalent evidence of the send. The system then creates the next action and due date.

4. Make approval exact and expiring

An approval record should bind together:

• Recipient and channel.
• Final subject and message hash.
• Evidence snapshot and confidence.
• Consent and suppression checks.
• Approver identity and approval timestamp.
• Prompt version, policy version and expiration time.

Changing the recipient, copy, evidence, channel or policy state invalidates approval and sends the record back to review. An AI process or service credential cannot approve its own output.

5. Give every relationship an owner and an audit trail

The CRM is the operating record. An approved reach must have one accountable owner, one current state, one next action and one due date. Replies remain in a human queue; the system may summarize or draft a response, but it may not send one.

Minimum CRM fields

• Company, contact, relationship context and source.
• Customer-profile fit and supporting evidence.
• Last interaction, current state and reply classification.
• Owner, next action and due date.
• Permission, suppression and opt-out status.
• Draft, approval and send identifiers.
• Outcome and attribution limitations.

Required audit events

Write append-only events for account creation, evidence changes, draft creation, approval request, approval, rejection, send recording, reply recording, opt-out, delivery failure, workflow stop and record closure. Each event should identify the actor type, target, time, prior and new state, reason, source IDs, prompt or policy version and correlation ID.

Do not silently repair history. A correction creates a new event and preserves the original record.

6. Treat consent, opt-out and deliverability as gates

This playbook is not legal advice. The operator must establish the applicable law, contract, platform rules and internal policy for each channel and market before contact.

• Do not use purchased or prohibited scraped lists.
• Do not assume public availability equals consent.
• Keep a shared suppression record that every workflow checks.
• Make declining or opting out clear and easy where appropriate.
• Apply an opt-out immediately across all outreach queues and channels.
• Use an authenticated business sending identity and monitor provider feedback.
• Pause on repeated bounces, complaints, authentication problems or unusual delivery changes.
• Never evade provider limits or rotate identities to bypass safeguards.

Measure deliverability as an operational risk signal, not as permission to send more. A clean technical delivery does not prove relevance or consent.

7. Fail closed, with bounded retries

Every service boundary needs a timeout, retry limit, cost ceiling and human-visible failure state. One automatic retry may be appropriate for a temporary read failure; a send must never be blindly retried.

Error handling rules

• Missing credentials: mark the integration not configured; do not display a success state.
• Source unavailable: keep the last reviewed evidence but mark it stale; do not draft from an unverified replacement.
• Structured output invalid: reject the result, record the validation error and stop after the configured retry limit.
• Partial database write: roll back the transaction; do not leave a draft without its evidence and audit event.
• Delivery timeout: reconcile against the provider message ID before considering a retry, preventing duplicate sends.
• Policy or suppression conflict: stop immediately and route the record to Tony.
• Unexpected model claim: remove the claim, flag the run and require a new review.

Non-negotiable stop conditions

• The contact identity or role is unclear.
• The key observation has no approved source.
• The evidence is stale, contradictory or low confidence.
• The message states an inferred business problem as fact.
• The contact opted out or appears on a suppression record.
• Consent, policy or jurisdictional requirements are unresolved.
• The source or proposed automation conflicts with platform terms.
• The approved recipient, channel or message changed.
• A bounce, complaint, authentication or delivery threshold is reached.
• A reply requires relationship context or a consequential decision.

8. Launch the smallest testable system

1. Approve one narrow customer profile and one responsible reason for contact.
2. Define the source allowlist, evidence states and staleness rules.
3. Create CRM states, ownership fields, suppression checks and audit events.
4. Test drafts against controlled records without sending externally.
5. Verify that every stop condition actually prevents approval and sending.
6. Complete a manual, human-approved pilot with a dated baseline.
7. Review replies, objections, opt-outs, bounces and next-action completion before changing the boundary.

The baseline should record what the system actually processed: candidates researched, records stopped, drafts reviewed, messages approved, sends recorded, replies, opt-outs, delivery failures and completed next actions. Do not infer business impact from activity alone.