{"schema_version":"1.0","record_type":"article","canonical_url":"https://marketingwiki.ai/articles/ai-email-workflow-from-brief-to-send","id":"ai-email-workflow-from-brief-to-send","slug":"ai-email-workflow-from-brief-to-send","title":"How to Build an AI Email Workflow from Brief to Send","description":"A state-based workflow for deciding what AI can own in email marketing, where human approval belongs, and what evidence each handoff requires.","dek":"Move from brief to ground, draft, build, verify, approve, queue, send, and observe with explicit owners, permissions, evidence, and rollback rules.","category":"Email Marketing","topics":["AI email","workflow design","human approval","agent permissions"],"publishedAt":"2026-08-13","updatedAt":"2026-08-13","lastVerifiedAt":"2026-08-13","readingMinutes":13,"author":"Marketing Wiki Editors","reviewer":"Adam Lababidi","featured":false,"sources":[{"title":"NIST AI Risk Management Framework Core","url":"https://airc.nist.gov/airmf-resources/airmf/5-sec-core/"},{"title":"NIST AI RMF Appendix C: AI Risk Management and Human-AI Interaction","url":"https://airc.nist.gov/airmf-resources/airmf/appendices/app-c-ai-risk-management-and-human-ai-interaction/"},{"title":"NIST AI RMF Generative Artificial Intelligence Profile","url":"https://doi.org/10.6028/NIST.AI.600-1"},{"title":"FTC CAN-SPAM Act Compliance Guide for Business","url":"https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business"},{"title":"ICO Guidance on Direct Marketing Using Electronic Mail","url":"https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-direct-marketing-using-electronic-mail/"},{"title":"Google Email Sender Guidelines","url":"https://support.google.com/mail/answer/81126"},{"title":"Migma MCP Server Documentation","url":"https://docs.migma.ai/mcp-server"},{"title":"Migma Agents Documentation","url":"https://docs.migma.ai/agents/overview"},{"title":"Migma Campaigns Documentation","url":"https://docs.migma.ai/campaigns/overview"},{"title":"Migma Email Preflight Documentation","url":"https://docs.migma.ai/email-editor/email-preflight"}],"wordCount":2502,"body":"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.\n\nEvery state should have three things: an artifact, an owner, and an allowed next action. If one is missing, the campaign does not move forward.\n\n[NIST's AI Risk Management Framework](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) calls for defined roles and responsibilities in human-AI configurations. Its [Generative AI Profile](https://doi.org/10.6028/NIST.AI.600-1) 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.\n\nThis 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.\n\n## Nine states from brief to send\n\nUse one forward path:\n\n```text\nBRIEFED -> GROUNDED -> DRAFTED -> BUILT -> VERIFIED -> APPROVED -> QUEUED -> SENT -> OBSERVED\n```\n\nDo 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.\n\n| State | Required artifact | AI can own | Named human owns | Exit condition |\n| --- | --- | --- | --- | --- |\n| `BRIEFED` | Campaign brief | Normalize inputs, identify missing fields | Lifecycle lead | Objective, audience, offer, sender, timing, exclusions, and success measure are explicit |\n| `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 |\n| `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 |\n| `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 |\n| `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 |\n| `APPROVED` | Signed approval record | Summarize evidence and unresolved limits | Named campaign owner | Approval identifies exact content, audience, sender, and schedule versions |\n| `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 |\n| `SENT` | Delivery event and immutable send record | Collect provider events and surface failures | Campaign owner | Send result and incident state are recorded |\n| `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 |\n\nThis is not a waterfall. A change can move work backward. That behavior protects the meaning of each state.\n\n## 1. Brief before the agent writes\n\nAn AI should not invent the campaign goal from a request such as \"write a launch email.\" Give it a structured brief:\n\n- business objective and expected recipient action;\n- audience definition and exclusions;\n- offer, dates, prices, availability, and geographic limits;\n- approved sender identity and reply path;\n- required claims and prohibited claims;\n- brand references and accessibility requirements;\n- send window and success measure;\n- owners for content, audience, privacy, deliverability, and final approval.\n\nAI 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.\n\nExit `BRIEFED` only when each consequential input has an owner. Copy quality does not repair an undefined offer or recipient group.\n\n## 2. Ground claims and audience policy\n\nCreate 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.\n\nAI can extract candidate claims and produce a ledger:\n\n| Claim | Source | Owner | Verified | Allowed wording | Limits |\n| --- | --- | --- | --- | --- | --- |\n| Offer amount | Approved offer record | Growth lead | Date | Exact approved value | Region and end date |\n| Product capability | Current product documentation | Product owner | Date | Supported description | Plan or availability limits |\n| Customer quote | Signed approval record | Customer marketing | Date | Approved excerpt | Approved channels and expiry |\n\nThe human owner decides whether source is authoritative for campaign. AI reports conflicts or missing evidence; it does not resolve them by choosing convenient wording.\n\nAudience 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.\n\nRules vary. [FTC CAN-SPAM guidance](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) covers US commercial email and says a business cannot contract away legal responsibility by hiring another company to handle email marketing. [UK ICO guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-direct-marketing-using-electronic-mail/) 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.\n\n## 3. Draft within approved facts\n\nOnce 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.\n\nAsk for meaningful options, not ten paraphrases. For example:\n\n- one direct offer-led version;\n- one product-use-case version;\n- one editorial version with less promotional density.\n\nContent 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.\n\nKeep draft reversible. No production audience, live sender credential, or send permission is needed here.\n\n## 4. Build final email in target path\n\nMove from copy to final artifact before approval. The artifact includes more than body text:\n\n- HTML and plain-text versions;\n- subject, preview, From, and Reply-To fields;\n- image sources and text alternatives;\n- every destination URL and tracking parameter;\n- personalization fields, fallbacks, and conditional branches;\n- footer, sender details, and unsubscribe behavior;\n- audience query or saved segment version;\n- sending domain and schedule.\n\nAI 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.\n\nAssign immutable content hash or version ID at this state. Every later test and approval should point to it.\n\n## 5. Verify through separate gates\n\n`VERIFIED` means required tests passed against final artifact and configuration. It does not mean \"agent reviewed its own work.\"\n\nUse separate evidence for:\n\n- claims and offer terms;\n- sender and subject accuracy;\n- audience eligibility and suppressions;\n- unsubscribe and required sender details;\n- links and tracked destinations;\n- personalization branches and fallbacks;\n- mobile and desktop rendering;\n- accessibility checks selected by your program;\n- authentication and current mailbox-provider requirements;\n- received test from final send path.\n\nAI can run checks, collect screenshots, compare output, and summarize failures. Named owners accept or reject evidence in their domains.\n\nProvider requirements change. [Google's email sender guidelines](https://support.google.com/mail/answer/81126) 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.\n\nAny failed, stale, or unassigned gate blocks transition to `APPROVED`.\n\n## 6. Approve exact version\n\nApproval should identify what person authorized, not record a floating comment such as \"looks good.\"\n\nBind approval to:\n\n- content hash or immutable email ID;\n- audience query or saved-segment version;\n- sender identity and sending domain;\n- scheduled timestamp and timezone;\n- test bundle and exception list;\n- named approver and approval timestamp.\n\nFinal approver reads unresolved limitations. They should not rely on green automated checks without knowing what those checks covered.\n\nLive 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.\n\n## 7. Queue without changing approval\n\nQueue 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.\n\nCompare provider job before accepting transition:\n\n```text\ncontent_version == approved.content_version\naudience_version == approved.audience_version\nsender == approved.sender\nscheduled_at == approved.scheduled_at\n```\n\nRecord provider campaign or job ID, creation response, current status, and cancellation path. Fail closed if any approved value cannot be matched.\n\n## 8. Record send, failure, or cancellation\n\n`SENT` needs external evidence from provider, not agent statement that tool call succeeded. Capture accepted, rejected, partial, canceled, and unknown outcomes separately.\n\nDo not flatten transport acceptance into recipient delivery. Store provider event IDs and later delivery events with their own timestamps and meanings.\n\nIf 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.\n\n## 9. Observe without granting silent optimization\n\nPost-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.\n\n[NIST AI RMF](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) 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.\n\nDo 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.\n\n## Owner and permission matrix\n\nSet permissions by action, not job title alone.\n\n| Action | AI default | Human owner | Required control |\n| --- | --- | --- | --- |\n| Read approved sources | Allow | Data or product owner | Source allowlist and sensitive-field limits |\n| Draft or revise email | Allow | Content owner | Version history |\n| Build final artifact | Allow | Production owner | Deterministic output and content ID |\n| Run non-destructive checks | Allow | QA owner | Controlled environment and test recipients |\n| Create campaign draft | Allow with log | Campaign owner | No live audience action |\n| Change audience or suppression data | Deny | Audience or privacy owner | Exact mutation approval and audit record |\n| Export to production ESP | Approval required | Campaign operator | Destination and version check |\n| Send test | Allow only to allowlist | QA or campaign owner | Recipient allowlist and test marker |\n| Schedule or live-send | Deny | Named campaign approver | Version-bound approval and scoped action |\n| Read results | Allow | Data owner | Metric definitions and access boundary |\n| Change future campaign from result | Deny | Lifecycle lead | New brief or approved experiment |\n\nThis 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.\n\n## Portable handoff contract\n\nKeep workflow state outside chat history. Pass structured record between agent, editor, sending platform, and reviewer:\n\n```yaml\nworkflow_id: \"wf_2026_08_launch\"\nstate: \"VERIFIED\"\n\nbrief:\n  objective: \"Activate trial users who completed setup\"\n  audience_definition: \"trial_setup_complete_v3\"\n  offer_record: \"offer_2026_08_a\"\n  success_measure: \"qualified_activation_within_7d\"\n\nversions:\n  content_hash: \"sha256:...\"\n  audience_version: \"segment_184@2026-08-12T09:00:00Z\"\n  sender: \"Team Example <news@example.com>\"\n  scheduled_at: \"2026-08-14T14:00:00Z\"\n\nevidence:\n  claim_ledger: \"artifact://claim-ledger/91\"\n  render_report: \"artifact://render/314\"\n  link_report: \"artifact://links/315\"\n  personalization_cases: \"artifact://profiles/316\"\n  received_test: \"artifact://test-send/88\"\n\napprovals:\n  content:\n    status: \"approved\"\n    by: \"named-person\"\n    at: \"2026-08-12T11:32:00Z\"\n  audience:\n    status: \"approved\"\n    by: \"named-person\"\n    at: \"2026-08-12T11:40:00Z\"\n  final_send:\n    status: \"pending\"\n    by: null\n    at: null\n\nnext_action:\n  type: \"schedule_campaign\"\n  permission: \"email:send\"\n  approval_required: true\n\ninvalidate_on:\n  - \"content_hash\"\n  - \"audience_version\"\n  - \"sender\"\n  - \"scheduled_at\"\n```\n\nUse stable references rather than pasting private audience data or credentials into record. Store artifacts where authorized reviewers can inspect them.\n\n## Affiliated implementation example: Migma\n\n**Disclosure:** Initial Marketing Wiki maintainer works on Migma. Following description uses Migma's public documentation. It is not an independent performance test or recommendation.\n\n[Migma's MCP documentation](https://docs.migma.ai/mcp-server) 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.\n\nThat documented surface maps to state model:\n\n| Workflow state | Documented Migma surface |\n| --- | --- |\n| `DRAFTED` and `BUILT` | Prepare one email or multi-email series |\n| `VERIFIED` | Validate output, run [Email Preflight](https://docs.migma.ai/email-editor/email-preflight), and send test |\n| `APPROVED` | Keep human approval before consequential MCP actions |\n| `QUEUED` and `SENT` | Create campaign draft, then approve send or schedule in [campaign flow](https://docs.migma.ai/campaigns/overview) |\n| `OBSERVED` | Read campaign metrics and logs |\n\nMigma 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.\n\nOther platforms may expose different scopes, artifacts, and approval controls. Evaluate actual documentation and observed behavior before applying this mapping elsewhere.\n\n## Change rules that keep approval honest\n\nInvalidate only affected work, but always revoke final approval after a consequential change.\n\n| Changed field | Return to | Re-run |\n| --- | --- | --- |\n| Objective, offer, audience purpose, or material claim | `GROUNDED` | Source, policy, copy, build, verification, approval |\n| Copy, image, link, or personalization logic | `BUILT` | Build, affected tests, approval |\n| Audience query, exclusions, or suppressions | `VERIFIED` | Eligibility, personalization, volume, approval |\n| Sender, domain, or Reply-To | `VERIFIED` | Identity, authentication, received test, approval |\n| Schedule or timezone | `APPROVED` | Timing review and final approval |\n| Provider job differs from approved record | Stop in `QUEUED` | Fix job or obtain new approval |\n\nStart 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.\n\nWhen campaign reaches `VERIFIED`, apply [AI-generated marketing email pre-send checklist](/articles/ai-email-pre-send-review). Use [brand consistency rubric](/articles/ai-email-brand-consistency-rubric) for design approval."}