How to Build an AI Email Workflow from Brief to Send
Move from brief to ground, draft, build, verify, approve, queue, send, and observe with explicit owners, permissions, evidence, and rollback rules.
- Written by
- Marketing Wiki Editors
- Reviewed by
- Adam Lababidi
- Published
- Updated
- Evidence checked
- Sources
- 10
A state-based workflow for deciding what AI can own in email marketing, where human approval belongs, and what evidence each handoff requires.
Build an AI email workflow as a state machine, not a long prompt. Let AI do reversible work such as research, drafting, production, testing, and analysis. Keep audience policy, material claims, final approval, and live sending with named human owners.
Every state should have three things: an artifact, an owner, and an allowed next action. If one is missing, the campaign does not move forward.
NIST's AI Risk Management Framework calls for defined roles and responsibilities in human-AI configurations. Its Generative AI Profile also identifies confabulation, confidently stated false content, and recommends reviewing sources and citations during pre-deployment measurement and ongoing monitoring. Email turns those general risks into external consequences: a send reaches people, uses a sender identity, changes suppression state, and can create legal or reputational harm.
This workflow gives a lifecycle lead a practical boundary between AI work and human decisions. It is an operating model, not legal advice. Privacy and legal owners must define rules for each program, jurisdiction, recipient type, and message class.
Nine states from brief to send#
Use one forward path:
BRIEFED -> GROUNDED -> DRAFTED -> BUILT -> VERIFIED -> APPROVED -> QUEUED -> SENT -> OBSERVED
Do not use status labels such as "in progress" or "ready". They hide what has been proven. A state should tell an operator which artifact exists and which action is allowed next.
| State | Required artifact | AI can own | Named human owns | Exit condition |
|---|---|---|---|---|
BRIEFED | Campaign brief | Normalize inputs, identify missing fields | Lifecycle lead | Objective, audience, offer, sender, timing, exclusions, and success measure are explicit |
GROUNDED | Source and policy pack | Retrieve approved material, extract claims, flag conflicts | Product, audience, privacy, or legal owners | Material facts and audience basis have current sources and owners |
DRAFTED | Copy and creative specification | Produce options, personalize within approved fields, explain choices | Content and brand owners | One direction is selected; claims remain tied to sources |
BUILT | Final email artifact and configuration | Build HTML, variants, dynamic fields, links, and plain text | Design or production owner | Final output exists in target sending path |
VERIFIED | Test bundle | Run link, rendering, content, personalization, sender, and controlled-recipient tests | QA, deliverability, audience, and privacy owners | Required checks pass with attached evidence |
APPROVED | Signed approval record | Summarize evidence and unresolved limits | Named campaign owner | Approval identifies exact content, audience, sender, and schedule versions |
QUEUED | Provider job or scheduled campaign ID | Create approved job and report provider response | Campaign operator | Job matches approved record and can still be stopped |
SENT | Delivery event and immutable send record | Collect provider events and surface failures | Campaign owner | Send result and incident state are recorded |
OBSERVED | Measurement and incident report | Aggregate results, compare with success measure, propose next test | Lifecycle and data owners | Learning is accepted, rejected, or assigned to next brief |
This is not a waterfall. A change can move work backward. That behavior protects the meaning of each state.
1. Brief before the agent writes#
An AI should not invent the campaign goal from a request such as "write a launch email." Give it a structured brief:
- business objective and expected recipient action;
- audience definition and exclusions;
- offer, dates, prices, availability, and geographic limits;
- approved sender identity and reply path;
- required claims and prohibited claims;
- brand references and accessibility requirements;
- send window and success measure;
- owners for content, audience, privacy, deliverability, and final approval.
AI can turn scattered notes into this structure and highlight blank fields. It should not fill material blanks with plausible guesses. A missing offer end date stays missing. An unclear audience basis goes to the audience or privacy owner.
Exit BRIEFED only when each consequential input has an owner. Copy quality does not repair an undefined offer or recipient group.
2. Ground claims and audience policy#
Create a source pack before prose. It can include approved product records, price and availability data, offer terms, brand guidance, consent policy, suppression rules, and current provider requirements.
AI can extract candidate claims and produce a ledger:
| Claim | Source | Owner | Verified | Allowed wording | Limits |
|---|---|---|---|---|---|
| Offer amount | Approved offer record | Growth lead | Date | Exact approved value | Region and end date |
| Product capability | Current product documentation | Product owner | Date | Supported description | Plan or availability limits |
| Customer quote | Signed approval record | Customer marketing | Date | Approved excerpt | Approved channels and expiry |
The human owner decides whether source is authoritative for campaign. AI reports conflicts or missing evidence; it does not resolve them by choosing convenient wording.
Audience policy needs same treatment. Record list or segment source, inclusion rule, exclusions, suppression behavior, applicable program policy, and owner. Do not let agent infer sending permission from public contact data or a profile field.
Rules vary. FTC CAN-SPAM guidance covers US commercial email and says a business cannot contract away legal responsibility by hiring another company to handle email marketing. UK ICO guidance uses different concepts and conditions for electronic direct marketing. A qualified owner must select applicable policy. Neither an AI tool nor this workflow makes that decision universally.
3. Draft within approved facts#
Once source pack is stable, AI can produce subject lines, preview text, body copy, CTA options, and personalization rules. Require each material claim to reference source-ledger entry. That makes review faster and prevents unsupported claims from hiding inside polished copy.
Ask for meaningful options, not ten paraphrases. For example:
- one direct offer-led version;
- one product-use-case version;
- one editorial version with less promotional density.
Content owner selects direction and records why. AI may revise tone, structure, length, and emphasis. It may not change approved facts, widen audience, or create urgency not present in offer terms.
Keep draft reversible. No production audience, live sender credential, or send permission is needed here.
4. Build final email in target path#
Move from copy to final artifact before approval. The artifact includes more than body text:
- HTML and plain-text versions;
- subject, preview, From, and Reply-To fields;
- image sources and text alternatives;
- every destination URL and tracking parameter;
- personalization fields, fallbacks, and conditional branches;
- footer, sender details, and unsubscribe behavior;
- audience query or saved segment version;
- sending domain and schedule.
AI can assemble these parts and run deterministic validation. Production owner confirms that final artifact is what provider will send. A design preview is not equivalent to received message.
Assign immutable content hash or version ID at this state. Every later test and approval should point to it.
5. Verify through separate gates#
VERIFIED means required tests passed against final artifact and configuration. It does not mean "agent reviewed its own work."
Use separate evidence for:
- claims and offer terms;
- sender and subject accuracy;
- audience eligibility and suppressions;
- unsubscribe and required sender details;
- links and tracked destinations;
- personalization branches and fallbacks;
- mobile and desktop rendering;
- accessibility checks selected by your program;
- authentication and current mailbox-provider requirements;
- received test from final send path.
AI can run checks, collect screenshots, compare output, and summarize failures. Named owners accept or reject evidence in their domains.
Provider requirements change. Google's email sender guidelines currently describe authentication, message format, sender identity, spam-rate, and one-click-unsubscribe requirements that vary by volume and message type. Treat provider documentation as dated input to verification, not permanent configuration and not a promise of inbox placement.
Any failed, stale, or unassigned gate blocks transition to APPROVED.
6. Approve exact version#
Approval should identify what person authorized, not record a floating comment such as "looks good."
Bind approval to:
- content hash or immutable email ID;
- audience query or saved-segment version;
- sender identity and sending domain;
- scheduled timestamp and timezone;
- test bundle and exception list;
- named approver and approval timestamp.
Final approver reads unresolved limitations. They should not rely on green automated checks without knowing what those checks covered.
Live send permission should remain unavailable to drafting and testing roles by default. Grant it only for approved action, with scope and expiry your system supports. If platform cannot separate drafting from sending, keep credential outside agent runtime and let human operator execute send.
7. Queue without changing approval#
Queue or schedule step converts approval into provider action. It should not rewrite content, recalculate audience silently, choose sender, or optimize schedule unless those changes are part of approved record.
Compare provider job before accepting transition:
content_version == approved.content_version
audience_version == approved.audience_version
sender == approved.sender
scheduled_at == approved.scheduled_at
Record provider campaign or job ID, creation response, current status, and cancellation path. Fail closed if any approved value cannot be matched.
8. Record send, failure, or cancellation#
SENT needs external evidence from provider, not agent statement that tool call succeeded. Capture accepted, rejected, partial, canceled, and unknown outcomes separately.
Do not flatten transport acceptance into recipient delivery. Store provider event IDs and later delivery events with their own timestamps and meanings.
If send partially fails, campaign owner decides retry scope. Agent can identify failed recipients and suggest action, but should not resend whole audience from an ambiguous state.
9. Observe without granting silent optimization#
Post-send work closes loop. AI can summarize delivery events, clicks, downstream conversions, complaints, unsubscribes, and anomalies using approved metric definitions. It should report unavailable data as unknown, not zero.
NIST AI RMF includes post-deployment monitoring, override, incident response, recovery, and change management. For email, that means named owner can stop scheduled work, investigate complaints, repair bad links or targeting logic, and decide whether proposed change becomes next brief.
Do not let agent turn one campaign result into a live optimization rule without review. A recommendation can be reversible draft. Updating audience logic or future sends is new consequential action.
Owner and permission matrix#
Set permissions by action, not job title alone.
| Action | AI default | Human owner | Required control |
|---|---|---|---|
| Read approved sources | Allow | Data or product owner | Source allowlist and sensitive-field limits |
| Draft or revise email | Allow | Content owner | Version history |
| Build final artifact | Allow | Production owner | Deterministic output and content ID |
| Run non-destructive checks | Allow | QA owner | Controlled environment and test recipients |
| Create campaign draft | Allow with log | Campaign owner | No live audience action |
| Change audience or suppression data | Deny | Audience or privacy owner | Exact mutation approval and audit record |
| Export to production ESP | Approval required | Campaign operator | Destination and version check |
| Send test | Allow only to allowlist | QA or campaign owner | Recipient allowlist and test marker |
| Schedule or live-send | Deny | Named campaign approver | Version-bound approval and scoped action |
| Read results | Allow | Data owner | Metric definitions and access boundary |
| Change future campaign from result | Deny | Lifecycle lead | New brief or approved experiment |
This matrix is a starting point. Transactional messages, internal tests, emergency notices, regulated content, and high-volume marketing can require different controls. Make deviations explicit instead of hiding them in broad agent credential.
Portable handoff contract#
Keep workflow state outside chat history. Pass structured record between agent, editor, sending platform, and reviewer:
workflow_id: "wf_2026_08_launch"
state: "VERIFIED"
brief:
objective: "Activate trial users who completed setup"
audience_definition: "trial_setup_complete_v3"
offer_record: "offer_2026_08_a"
success_measure: "qualified_activation_within_7d"
versions:
content_hash: "sha256:..."
audience_version: "segment_184@2026-08-12T09:00:00Z"
sender: "Team Example <news@example.com>"
scheduled_at: "2026-08-14T14:00:00Z"
evidence:
claim_ledger: "artifact://claim-ledger/91"
render_report: "artifact://render/314"
link_report: "artifact://links/315"
personalization_cases: "artifact://profiles/316"
received_test: "artifact://test-send/88"
approvals:
content:
status: "approved"
by: "named-person"
at: "2026-08-12T11:32:00Z"
audience:
status: "approved"
by: "named-person"
at: "2026-08-12T11:40:00Z"
final_send:
status: "pending"
by: null
at: null
next_action:
type: "schedule_campaign"
permission: "email:send"
approval_required: true
invalidate_on:
- "content_hash"
- "audience_version"
- "sender"
- "scheduled_at"
Use stable references rather than pasting private audience data or credentials into record. Store artifacts where authorized reviewers can inspect them.
Affiliated implementation example: Migma#
Disclosure: Initial Marketing Wiki maintainer works on Migma. Following description uses Migma's public documentation. It is not an independent performance test or recommendation.
Migma's MCP documentation says agents can prepare and validate emails, send tests, create campaign drafts, export approved emails, manage contacts, and inspect results. It also says email:send permits test and live sends and recommends human approval before sends, exports, audience changes, and campaign changes.
That documented surface maps to state model:
| Workflow state | Documented Migma surface |
|---|---|
DRAFTED and BUILT | Prepare one email or multi-email series |
VERIFIED | Validate output, run Email Preflight, and send test |
APPROVED | Keep human approval before consequential MCP actions |
QUEUED and SENT | Create campaign draft, then approve send or schedule in campaign flow |
OBSERVED | Read campaign metrics and logs |
Migma documents preflight checks for client previews, CSS compatibility, links, grammar, compliance basics, and spam or deliverability review. Treat these as documented checks, not proof of legal compliance or inbox placement. Named owners still need to review final artifact, audience, sender, and send action.
Other platforms may expose different scopes, artifacts, and approval controls. Evaluate actual documentation and observed behavior before applying this mapping elsewhere.
Change rules that keep approval honest#
Invalidate only affected work, but always revoke final approval after a consequential change.
| Changed field | Return to | Re-run |
|---|---|---|
| Objective, offer, audience purpose, or material claim | GROUNDED | Source, policy, copy, build, verification, approval |
| Copy, image, link, or personalization logic | BUILT | Build, affected tests, approval |
| Audience query, exclusions, or suppressions | VERIFIED | Eligibility, personalization, volume, approval |
| Sender, domain, or Reply-To | VERIFIED | Identity, authentication, received test, approval |
| Schedule or timezone | APPROVED | Timing review and final approval |
| Provider job differs from approved record | Stop in QUEUED | Fix job or obtain new approval |
Start with one recurring campaign type. Run workflow in dry mode, with live-send permission removed, until team can produce complete handoff record and trace every transition. Then decide whether any additional action deserves scoped automation.
When campaign reaches VERIFIED, apply AI-generated marketing email pre-send checklist. Use brand consistency rubric for design approval.
Sources behind this page
Claims remain tied to dated source review. Method and corrections stay public.
- S-01NIST AI Risk Management Framework Coreairc.nist.gov
- S-02NIST AI RMF Appendix C: AI Risk Management and Human-AI Interactionairc.nist.gov
- S-03NIST AI RMF Generative Artificial Intelligence Profiledoi.org
- S-04FTC CAN-SPAM Act Compliance Guide for Businessftc.gov
- S-05ICO Guidance on Direct Marketing Using Electronic Mailico.org.uk
- S-06Google Email Sender Guidelinessupport.google.com
- S-07Migma MCP Server Documentationdocs.migma.ai
- S-08Migma Agents Documentationdocs.migma.ai
- S-09Migma Campaigns Documentationdocs.migma.ai
- S-10Migma Email Preflight Documentationdocs.migma.ai