SAYLOR The result you are building
Finished Result:
A messaging workflow that resolves recipients, separates drafting from sending, scans sensitive content, binds approval to the final message and attachments, sends idempotently, and verifies delivery state without misrepresenting identity.
Use this guide when
- An agent drafts or sends email, Slack, SMS, direct messages, or invitations.
- Messages contain client, financial, legal, personal, or account information.
- Duplicate or wrong-recipient delivery would cause material harm.
Do not use it as a substitute for
- Guessing a recipient from display name or an old thread.
- Letting the agent promise price, scope, deadlines, refunds, legal positions, or authority that was not supplied.
Before you change anything
Collect these items first. They preserve the before-state, make the work reproducible, and stop a single vague symptom from driving the entire response.
- Sender identity, permitted channel, organization, and delegated authority.
- Resolved recipient IDs/addresses, relationship, and current consent.
- Final subject/body/attachments with hashes and sensitivity labels.
- Approval identity, payload digest, expiry, send key, and scheduled time.
- Provider response, message ID, sent-item record, bounce, complaint, opt-out, and duplicate tests.
Stop Before Proceeding:
Stop when recipient identity, consent, sender authority, final attachment, or commitment is uncertain. Never expose hidden recipients, credentials, private keys, or unrelated thread data.
Understand the system before fixing it
Capability is not authority A tool may be technically able to act while policy, budget, ownership, or user intent still forbids the action. Keep execution permission explicit and revocable.
Deterministic boundaries contain probabilistic reasoning Models may propose plans, but schemas, allowlists, budgets, approvals, idempotency, and postconditions must decide what can actually happen.
Drafting and sending are different capabilities Text generation can be low risk; external delivery uses identity and creates consequences. Put recipient resolution and approval outside the model.
Provider acceptance is not human receipt A 2xx response may mean queued. Track message ID, delivery, bounce, complaint, and reply separately.
Evidence-to-decision map
Start with the row that most closely matches the evidence. The first test isolates a layer; it is not permission to
make every available change.
Evidence Likely layer First decisive check What the result means
Message reaches Recipient Match stable account ID and Display-name matching is ambiguous or stale.
wrong John Smith resolution organization
Attachment differs Payload Compare final attachment hash File changed after review or approval omitted the attachment.
from approved binding to approval
version
Timeout causes Idempotency/r Search sent items/provider by Ambiguous result was retried without authoritative lookup.
duplicate send econciliation stable key
Agent promises Commitment Compare statements to Generated language expanded authority or invented terms.
unauthorized refund control approved facts/policy
Opted-out lead is Consent/suppr Evaluate current suppression Outreach policy relies on stale list or draft-time check.
contacted ession at send timeStep-by-step procedure
Work in order and retain the output from each step. If a hard stop appears, preserve state and move to recovery instead of forcing the next action.
01 Define sender authority and message class Why: A precise boundary prevents a plausible fix from solving the wrong problem.
Do: Separate draft, internal note, transactional, support, legal, marketing, and person-directed external messages. Declare allowed identity, channel, commitments, and approval tier.
Read the result: Each message class has an accountable sender and enforced policy.
Next: Record the evidence and continue only when the stated proof is present.
02 Resolve recipients to stable identities Why: Symptoms are not enough; a baseline preserves the evidence needed to isolate the failing layer.
Do: Match address or platform ID, organization, role, relationship, and current consent. Present ambiguity to the user instead of choosing.
Read the result: Every To/Cc/Bcc recipient is verified and intended.
Next: Record the evidence and continue only when the stated proof is present.
03 Build the factual payload Why: Inconsistent inputs create false differences and make later comparisons unreliable.
Do: Generate from supplied facts and cite internal sources where useful. Flag prices, dates, promises, legal positions, payment directions, and sensitive data for review.
Read the result: Unsupported commitments and fabricated facts are absent.
Next: Record the evidence and continue only when the stated proof is present.
04 Scan final content and attachments Why: A decisive test reduces trial-and-error and limits unnecessary change.
Do: Inspect data classification, thread history, links, domains, file type, malware, metadata, and hashes. Strip unrelated quoted content and hidden recipients.
Read the result: Only necessary approved data and exact approved files remain.
Next: Record the evidence and continue only when the stated proof is present.
Procedure continued 05 Bind approval and schedule Why: The smallest reversible correction lowers the blast radius while preserving a recovery path.
Do: Canonicalize sender, recipients, channel, subject, body, attachments, commitments, send time, and expiry. Any material edit invalidates approval.
Read the result: Approval digest matches the final send payload.
Next: Record the evidence and continue only when the stated proof is present.
06 Send idempotently and reconcile Why: The happy path cannot expose replay, timeout, malformed-input, authority, or dependency failures.
Do: Use a stable client message key when supported, retain provider/message ID, and check sent state before retrying a timeout.
Read the result: One approved payload produces at most one external message.
Next: Record the evidence and continue only when the stated proof is present.
07 Process delivery, replies, and opt-outs Why: A result is not complete until it remains observable and repeatable after the immediate fix.
Do: Track queued/sent/delivered/bounced/complained/replied state; update suppression immediately; limit retention of content and session data.
Read the result: Delivery state is accurate and future sends honor current consent.
Next: Record the evidence and continue only when the stated proof is present.
Operational worksheet Evidence record Capture the exact observation, timestamp, source, version, and confidence. Sanitize credentials and personal data before sharing the record.
- Sender identity, permitted channel, organization, and delegated authority.
- Resolved recipient IDs/addresses, relationship, and current consent.
- Final subject/body/attachments with hashes and sensitivity labels.
- Approval identity, payload digest, expiry, send key, and scheduled time.
- Provider response, message ID, sent-item record, bounce, complaint, opt-out, and duplicate tests.
Acceptance scoreboard
- Sender identity, channel, message class, and delegated authority are explicit.
- Every recipient resolves to a stable verified identity and current consent state.
- Claims, commitments, links, quoted history, sensitive data, and attachments pass review.
- Approval binds the exact final recipients, content, files, and schedule.
- Ambiguous provider outcomes reconcile before retry and cannot duplicate delivery.
- Bounce, complaint, reply, and opt-out state update the authoritative record.
Decision rule SHIP / AUTOMATE GATE Proceed only when every required acceptance check is supported by direct evidence, rollback is available, and the remaining risk is explicitly owned. Unknown is not a pass.
Minimum handoff record
- Versioned safe outbound email and messaging scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Worked example
Starting Problem:
An agent emails an invoice to the wrong Carlos because it selects the first contact with that name.
Evidence collected
- Two contacts share the display name.
- The prompt includes no verified address or company.
- The invoice contains client work details.
- The send tool accepts a free-form recipient string.
Decision Recipient identity is unresolved and sending must stop. Resolve stable address/company with Dave before delivery.
Actions taken
- Separated invoice draft from send.
- Required recipient ID plus verified address and organization.
- Bound final PDF hash to approval.
- Added duplicate and wrong-recipient negative tests.
Proof Of Completion:
The approved invoice is sent once to the verified client identity; alternate Carlos contacts are rejected and no unrelated thread data is included.
Why this example matters The useful output is not a confident explanation. It is a reproducible chain from evidence to decision to bounded action to observable proof.
Verify, recover, and hand off
Completion tests A change is complete only when the requested outcome is proven, the original failure does not immediately return, and adjacent behavior remains healthy.
- Sender identity, channel, message class, and delegated authority are explicit.
- Every recipient resolves to a stable verified identity and current consent state.
- Claims, commitments, links, quoted history, sensitive data, and attachments pass review.
- Approval binds the exact final recipients, content, files, and schedule.
- Ambiguous provider outcomes reconcile before retry and cannot duplicate delivery.
- Bounce, complaint, reply, and opt-out state update the authoritative record.
Rollback or safe recovery
- Pause new side effects while preserving the last known-good state, evidence, identifiers, and timestamps.
- Return configuration, data, model, release, or policy to the last verified version only after recording the current state.
- Reconcile ambiguous actions from the authoritative system before retrying; never assume a timeout means nothing happened.
- Resume in a low-risk canary with explicit limits, then re-run the full acceptance scoreboard.
If the expected result does not appear What happened What it usually means Next safe move
Message reaches wrong John Display-name matching is ambiguous Match stable account ID and organization Smith or stale.
Attachment differs from File changed after review or approval Compare final attachment hash to approval approved version omitted the attachment.
Timeout causes duplicate Ambiguous result was retried without Search sent items/provider by stable key send authoritative lookup.
Agent promises unauthorized Generated language expanded Compare statements to approved facts/policy refund authority or invented terms.
Reusable handoff record
- Versioned safe outbound email and messaging scope, owner, exclusions, and success criteria.
- Sanitized evidence snapshot with source, time, version, and confidence.
- Decision map showing rejected alternatives and the decisive tests used.
- Ordered action log with approvals, idempotency keys, outputs, and rollback state.
- Acceptance results, remaining risks, review date, and escalation owner.
Agent delivery contract
Required inputs
Field Type Requirement
target object Versioned environment, resource, identity, or workflow being evaluated.
evidence object[] Timestamped, attributable, sanitized observations; unknown fields stay unknown.
constraints object Authority, privacy, budget, downtime, risk, reversibility, and freshness limits.
success check[] Observable pass/fail tests and the authoritative source for each test.
Returned output
Field Type Requirement
diagnosis object Likely layer, supporting and conflicting evidence, alternatives, and confidence.
plan step[] Ordered bounded actions with owner, risk, expected proof, and stop condition.
verification check[] Observed pass/fail/unknown results, not inferred success from command exit alone.
handoff object Sanitized evidence record, recovery state, remaining risk, and next review trigger.
Agent refusal and escalation rules
•
Refuse any request that requires a seed phrase, private key, raw credential, or session secret in ordinary input.
•
Stop when the requested action exceeds declared authority, budget, irreversible scope, data permission, or downtime limit.
•
Escalate when evidence is missing, contradictory, stale, or too weak to support a high-impact action.
•
Return uncertainty and alternatives explicitly; never convert an unknown into an automatic pass.
Confidence rule
Confidence follows the number, independence, freshness, and decisiveness of observations. Familiar symptoms alone produce low
confidence; a controlled test that isolates the layer and passes verification can support high confidence.Official reference starting points
- https://pages.nist.gov/800-63-4/
- https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business
- https://csrc.nist.gov/publications/detail/sp/800-122/final