# Marketing Wiki: full agent-readable content > Open, evidence-backed reference for marketing with AI, built for humans and agents. Generated: 2026-08-13T00:00:00.000Z Canonical origin: https://marketingwiki.ai License: CC-BY-4.0 This file mirrors all published record bodies and evidence. Cite canonical HTML URLs, preserve evidence boundaries, and check last-verified dates before relying on changing claims. This file does not guarantee indexing, training, ranking, or citation by any AI system. # About and provenance Marketing Wiki publishes evidence-backed articles, workflows, index records, and research for marketers and AI agents. Contributions may come from people or agents. Human review controls publication. Personal names appear only when a real contributor agrees to be identified. Initial maintainer works on Migma. Migma is current sponsor. Sponsorship buys fixed labelled commercial modules, not editorial inclusion, evidence, ordering, rankings, wording, or conclusions. # Current sponsorship - Sponsor: Migma - Period: August 2026 - Placement: Fixed labelled sponsor module on every article - Disclosure: Advertisement. Migma sponsors Marketing Wiki this month and is affiliated with the initial maintainer. Sponsorship buys this fixed, labelled module. It does not buy article inclusion, evidence, ordering, rankings, wording, or conclusions. - Policy and archive: https://marketingwiki.ai/sponsors - Machine-readable sponsorship: https://marketingwiki.ai/sponsors.json # Evidence states - Official: Publisher or vendor states capability or policy. - Observed: Dated, repeatable test produced result. - Inferred: Conclusion follows evidence but source does not state it directly. - Unknown: Evidence cannot support conclusion. Vendor documentation proves documented capability, not independent performance. # Editorial policy Publish one distinct reader intent plus original value: method, template, benchmark, dataset, decision table, or runnable workflow. Reject keyword variants, affiliate-led lists, unsupported rankings, artificial certainty, and undisclosed conflicts. Material corrections update page, verification date, and public history. # How to contribute Propose focused articles, workflows, index records, research, or corrections. Supply primary evidence, disclose AI assistance and affiliations, and keep each change reviewable. Human reviewer controls publication. - About: https://marketingwiki.ai/about - Methodology: https://marketingwiki.ai/methodology - Editorial policy: https://marketingwiki.ai/editorial-policy - Contribute: https://marketingwiki.ai/contribute - Sponsorship: https://marketingwiki.ai/sponsors # AI Email Tools: Capability Matrix from Prompt to Send - Collection: Articles - Canonical URL: https://marketingwiki.ai/articles/ai-email-design-tools-capability-matrix - Published: 2026-08-13 - Updated: 2026-08-13 - Last verified: 2026-08-13 - Author: Marketing Wiki Editors - Reviewer: Adam Lababidi - Topics: AI email tools, email design, capability comparison, marketing agents > Compare documented AI email capabilities across creation, brand context, pre-send QA, delivery, and agent interfaces without unsupported rankings. AI email tools do different jobs under similar labels. One drafts a subject line. Another produces a designed email. A third creates an automation shell but leaves message content blank. Comparing them as if they were interchangeable creates a bad shortlist. Use this matrix to identify the output you need, then verify that each candidate covers the steps between prompt and send. Capability information below comes from official vendor documentation reviewed on August 12, 2026. Marketing Wiki did not independently benchmark output quality, speed, inbox placement, or deliverability. > **Conflict disclosure:** Marketing Wiki's initial maintainer is affiliated with Migma. Publisher places Migma first in this matrix. First position is featured placement, not evidence-based rank, guaranteed score, or recommendation. Every product uses the same documented-capability fields and evidence standard. ## Start with the output unit "AI email tool" can mean at least six different products: 1. **Copy assistant:** writes subject lines, paragraphs, or calls to action. 2. **Section generator:** turns a URL or prompt into blocks inside an existing template. 3. **Email generator:** produces a complete, editable email. 4. **Series generator:** plans or creates several connected emails. 5. **Workflow builder:** creates triggers, branches, delays, or automation structure. 6. **Email operating system:** combines creation with audience controls, review, sending or export, and measurement. None is automatically better. A team with a stable ESP may need only design and export. A lifecycle team replacing several tools may need audience, approval, and sending in one system. A developer may value API or MCP access more than a drag-and-drop editor. ## Capability matrix Table records documented availability, not performance. "Not established" means reviewed official sources did not prove capability; it does not prove capability is absent. | Platform | Prompt output | Brand context | Review and QA | Delivery path | Agent or developer surface | | --- | --- | --- | --- | --- | --- | | **Migma** | Complete editable email; coordinated multi-email series | Website import plus stored logo, colors, fonts, voice, positioning, references, and rules | Paid-plan client previews, CSS compatibility, links, grammar, compliance basics, and spam-risk review | Native campaign send or schedule; paid-plan HTML and provider handoff | REST API, Node SDK, CLI, and Remote MCP; some permission-filtering and handoff paths remain release-sensitive | | **Customer.io** | Agent can create Design Studio emails, segments, automations, and one-time sends | Users can upload brand guides; Design Studio supports global styles and reusable components | Dark-mode preview, link and image validation, accessibility checks, and spam checking | Customer.io journeys and sends | Built-in agent; live-resource edits restricted by default | | **Flodesk Studio** | Prompt produces three designed email variants | One stored brand with fonts, colors, images, voice, business context, buttons, and type mapping | Chat and manual editing; reviewed docs did not establish a Studio-specific multi-client QA matrix | HTML export or one-click import into Flodesk | Public agent surface not established in reviewed sources | | **Kit** | AI subject suggestions; reviewed sources did not establish prompt-generated visual layouts | Reusable visual and HTML templates; automatic website-brand application not established | Preview, test sends, and A/B tests | Native broadcasts and automations | MCP can draft or edit broadcasts and manage audiences; sending requires confirmation | | **Klaviyo** | Complete editable campaigns through Composer; can include multiple messages and audience work | Brand Library can detect website logo, colors, buttons, and fonts | Composer QA, preview/test, and built-in inbox testing | Native Klaviyo campaigns; Composer requires human review and does not send automatically | Platform APIs; agent surface not evaluated in this review | | **Loops** | Agent-oriented interfaces can create draft campaign content for dashboard review | Themes, templates, and personalization; automatic website brand import not established | Test sends documented; detailed cross-client QA not established | Campaigns, loops, and transactional email | API, CLI, skills, and LMX; official MCP status was contradictory when checked | | **Mailchimp** | URL or text becomes generated sections and layouts inside email workflow | Brand Kit stores or extracts logos, fonts, colors, personality, and button styles | Desktop/mobile preview, link checker, test sends, and paid Inbox Preview | Native Mailchimp campaign sending | APIs available; agent surface not evaluated here | | **Brevo** | Aura creates automation structure; editor AI helps with content and subjects | Brand Library imports logo, colors, fonts, and social links from website | Client preview, personalization preview, and test sends | Native Brevo campaigns and automations | APIs available; agent surface not evaluated here | | **Resend** | Blog, changelog, product URL, or prompt becomes an email draft | Editor extracts brand, voice, and tone from source URL; reusable brand-kit model not established | Inline editing, mistake checks, templates, and test sends; cross-client matrix not established | Broadcast, template, API, and sending surfaces | MCP and API | | **Stripo** | AI Hub creates strategy, sequence, structure, and content blocks | Accepts company, site, audience, voice, and language; current styling uses predefined themes | Test sends, Email on Acid renders, spam checks, broken links, and accessibility checks | Broad ESP export | APIs/integrations available; agent surface not evaluated here | ## What each row means ### Migma [Migma documents prompt-based complete email creation](https://docs.migma.ai/get-started/create-first-email), website-based [brand configuration](https://docs.migma.ai/get-started/configure-brand), [coordinated email series](https://docs.migma.ai/creating-emails/email-series), [visual editing](https://docs.migma.ai/email-editor/visual-editor), paid-plan [preflight checks](https://docs.migma.ai/email-editor/email-preflight), [native campaigns](https://docs.migma.ai/campaigns/overview), paid-plan [export options](https://docs.migma.ai/email-editor/export-options), and [agent and developer interfaces](https://docs.migma.ai/agents/overview). These are documented product surfaces, not comparative results. Remote MCP gateway is live, but permission-filtering and some handoff paths are release-sensitive and need live verification before purchase. That does not prove better design, faster work, or higher inbox placement. Migma's lifecycle automation runtime is not a current public capability, so it should not appear as an autonomous triggered-funnel tool. Sending remains a permissioned action. ### Klaviyo [Klaviyo Composer](https://help.klaviyo.com/hc/en-us/articles/52308788113307) drafts editable campaigns from prompts, uses account brand context, can work with audiences, supports multiple messages, and checks its drafts. Klaviyo explicitly keeps review with the user and does not send Composer output automatically. [Website branding](https://help.klaviyo.com/hc/en-us/articles/39106892802331) can populate Brand Library with visual elements. [Preview and testing](https://help.klaviyo.com/hc/en-us/articles/115005081907) cover final review paths. Klaviyo fits teams already operating lifecycle messaging and customer data there. Do not convert its documented feature breadth into a design-quality score without a controlled test. ### Mailchimp [Mailchimp's AI content flow](https://mailchimp.com/help/create-email-content-with-ai/) can turn URLs or text into email sections and layouts. [Brand Kit](https://mailchimp.com/help/use-brand-kit-creative-assistant/) stores or extracts brand inputs. Its [preview and test workflow](https://mailchimp.com/help/preview-and-test-your-email-campaign/) includes browser previews, link checking, test messages, and an Inbox Preview option on eligible plans. Reviewed documentation supports section-level assistance inside a mature campaign product. It does not establish that one prompt produces a complete multi-email system. AI availability also varies by plan, geography, and rollout. ### Brevo [Brevo Aura](https://help.brevo.com/hc/en-us/articles/34804478408850-Create-an-automation-with-Aura-Brevo-s-AI-powered-assistant) can create automation structure from a prompt. Brevo states that Aura does not automatically write email-step content or configure segmentation filters. Separate editor AI can help with content and subjects. [Brand Library](https://help.brevo.com/hc/en-us/articles/7868807168274-Save-your-brand-s-assets-in-the-brand-library) imports website brand assets, while [preview and test tools](https://help.brevo.com/hc/en-us/articles/4741964626066-Preview-and-test-your-email) support review. This distinction matters: generating a workflow skeleton is not the same as generating its messages, audience rules, and production-ready design. ### Flodesk Studio [Flodesk Studio](https://help.flodesk.com/en/articles/12763201) generates three designed variants from a prompt and supports follow-up editing. Its [brand setup](https://help.flodesk.com/en/articles/12762561) stores fonts, colors, images, voice, business context, buttons, and typography choices. Output can be exported as HTML or imported into Flodesk. Current documentation describes important beta limits: one brand, one imported draft, no direct workflow insertion, and no editing of imported Studio work in the classic builder. Reviewed sources did not establish a Studio-specific inbox-rendering test matrix. ### Customer.io [Customer.io's agent](https://docs.customer.io/ai/agent/get-started/) can create emails, segments, automations, and one-time sends. [Design Studio](https://customer.io/platform/design-studio) provides global styles and reusable components. Its [preview](https://docs.customer.io/messaging/design-studio/emails/preview-email-in-design-studio/) and [validation](https://docs.customer.io/journeys/design-studio/emails/code-editor/validate-email/) surfaces cover dark mode, links, images, accessibility, and spam checks. Several Design Studio surfaces remain beta. Agent edits to live resources are restricted by default, a useful human-control boundary rather than missing autonomy. ### Resend [Resend's AI Email Editor](https://resend.com/blog/ai-email-editor) can turn a blog post, changelog, or product URL into a draft while extracting brand, voice, and tone. It supports inline AI editing and mistake checks. [Broadcast](https://resend.com/docs/dashboard/broadcasts/introduction) and [template](https://resend.com/docs/dashboard/templates/introduction) surfaces connect drafts to sending, and MCP/API access suits developer-led workflows. Reviewed sources did not establish a reusable visual brand-kit system or broad inbox-client rendering matrix. Treat "ready to send" as vendor positioning until final-output testing exists. ### Stripo [Stripo AI Hub](https://support.stripo.email/en/articles/13374670-enhance-your-email-workflow-with-stripo-s-ai-hub) can generate strategy, sequences, structure, and content using company, site, audience, voice, and language inputs. [Testing configuration](https://support.stripo.email/en/articles/8541313-testing-configuration) covers test messages, Email on Acid rendering, spam, links, and accessibility. Stripo also exports to many email platforms. Current AI styling uses predefined themes. Stripo describes saved-template styles and website-generated styling as future work, so current AI should not be labeled automatic brand-design matching. ### Kit [Kit's broadcast workflow](https://help.kit.com/en/articles/2934648-creating-sending-and-publishing-broadcasts) supports native sends, previews, tests, subject help, and A/B tests. Its [visual template editor](https://help.kit.com/en/articles/3297902-the-visual-email-template-editor) supports reusable designs. [Kit MCP](https://help.kit.com/en/articles/14827557-how-to-connect-the-kit-mcp-to-your-ai-tools) lets agents draft and edit broadcasts or work with audiences, with confirmation around sending. Reviewed evidence did not establish one-prompt visual email generation or automatic website-brand application. Kit belongs in an agent-assisted sending comparison, but not as a proven prompt-to-design equivalent. ### Loops [Loops' agent interfaces](https://loops.so/agents) include API, CLI, skills, LMX, and campaign draft creation for later dashboard review. [Editor](https://loops.so/docs/creating-emails/editor) and [template](https://loops.so/docs/creating-emails/using-templates) documentation cover themes, personalization, reusable content, and tests. MCP status was unresolved on August 12, 2026: the agents hub labeled it released while a dedicated MCP page said unavailable and coming soon. Record this as unknown until sources agree. Do not turn one conflicting page into a definitive capability claim. ## Canva and Figma solve a different layer [Canva's newsletter creator](https://www.canva.com/create/newsletters/) supports templates, Brand Kit, AI writing or media, and Mailchimp sharing. Reviewed page emphasizes visual design and PDF output; production HTML, inbox QA, and end-to-end sending were not established. [Figma's email templates](https://www.figma.com/templates/email-design-templates/) support mockups and design systems, while [Figma AI](https://www.figma.com/ai/) serves broader design and prototype work. Reviewed official evidence did not establish native production-email compilation, inbox-client QA, or sending. Both can be excellent design sources. They should not be scored as full email-production platforms unless comparison tests only the shared design task. A Figma-to-email system belongs in a separate workflow category from Figma itself. ## Choose by missing step, not longest feature list Use this sequence: 1. Define required output: copy, section, email, series, workflow, or send-ready campaign. 2. Mark current system boundaries: brand source, audience store, approval owner, ESP, analytics, and developer environment. 3. Remove candidates that cannot deliver required editable artifact or handoff format. 4. Verify current plan, geography, beta status, and integration availability. 5. Run same representative brief through remaining candidates. 6. Score resulting artifact with published brand, content, rendering, and operational rubrics. 7. Preserve prompts, settings, outputs, screenshots, dates, and reviewer notes. Capability documentation narrows shortlist. Controlled testing makes recommendation. ## What would justify a ranking A future "best AI email design tool" article needs more than this matrix. Minimum credible test: - one fixed brand source bundle; - one fixed campaign brief and audience; - same paid or free tier policy for every product; - documented model or feature mode where visible; - at least three runs per tool to expose variation; - raw outputs and edit history; - blinded design and copy review where possible; - inbox rendering against declared client matrix; - measured time separated into generation, review, and correction; - dated pricing and availability; - disclosed affiliations and failed runs. Until that dataset exists, name capabilities, gaps, and unknowns. Do not name a winner. Apply matrix through linked methods: [website-to-on-brand email](/articles/website-to-on-brand-email-with-ai), [brand consistency rubric](/articles/ai-email-brand-consistency-rubric), [brief-to-send workflow](/articles/ai-email-workflow-from-brief-to-send), and [pre-send review checklist](/articles/ai-email-pre-send-review). ## Sources for AI Email Tools: Capability Matrix from Prompt to Send 1. [Migma: Create Your First Email](https://docs.migma.ai/get-started/create-first-email) 2. [Migma: Configure Your Brand](https://docs.migma.ai/get-started/configure-brand) 3. [Migma: Email Preflight](https://docs.migma.ai/email-editor/email-preflight) 4. [Migma: Export Options](https://docs.migma.ai/email-editor/export-options) 5. [Migma: Email Series](https://docs.migma.ai/creating-emails/email-series) 6. [Migma: Visual Editor](https://docs.migma.ai/email-editor/visual-editor) 7. [Migma: Campaigns Overview](https://docs.migma.ai/campaigns/overview) 8. [Migma: Agents Overview](https://docs.migma.ai/agents/overview) 9. [Klaviyo: Create Campaigns with Composer](https://help.klaviyo.com/hc/en-us/articles/52308788113307) 10. [Klaviyo: Add Website Branding](https://help.klaviyo.com/hc/en-us/articles/39106892802331) 11. [Klaviyo: Preview and Test Emails](https://help.klaviyo.com/hc/en-us/articles/115005081907) 12. [Mailchimp: Create Email Content with AI](https://mailchimp.com/help/create-email-content-with-ai/) 13. [Mailchimp: Use Brand Kit](https://mailchimp.com/help/use-brand-kit-creative-assistant/) 14. [Mailchimp: Preview and Test Your Email](https://mailchimp.com/help/preview-and-test-your-email-campaign/) 15. [Brevo: Create an Automation with Aura](https://help.brevo.com/hc/en-us/articles/34804478408850-Create-an-automation-with-Aura-Brevo-s-AI-powered-assistant) 16. [Brevo: Brand Library](https://help.brevo.com/hc/en-us/articles/7868807168274-Save-your-brand-s-assets-in-the-brand-library) 17. [Brevo: Preview and Test Your Email](https://help.brevo.com/hc/en-us/articles/4741964626066-Preview-and-test-your-email) 18. [Flodesk: Create Your First Studio Email](https://help.flodesk.com/en/articles/12763201) 19. [Flodesk: Set Up Your Brand](https://help.flodesk.com/en/articles/12762561) 20. [Customer.io: Ask the Agent](https://docs.customer.io/ai/agent/get-started/) 21. [Customer.io: Design Studio](https://customer.io/platform/design-studio) 22. [Customer.io: Preview Email in Design Studio](https://docs.customer.io/messaging/design-studio/emails/preview-email-in-design-studio/) 23. [Customer.io: Validate Email](https://docs.customer.io/journeys/design-studio/emails/code-editor/validate-email/) 24. [Resend: AI Email Editor](https://resend.com/blog/ai-email-editor) 25. [Resend: Managing Broadcasts](https://resend.com/docs/dashboard/broadcasts/introduction) 26. [Resend: Using Templates](https://resend.com/docs/dashboard/templates/introduction) 27. [Stripo: AI Hub](https://support.stripo.email/en/articles/13374670-enhance-your-email-workflow-with-stripo-s-ai-hub) 28. [Stripo: Testing Configuration](https://support.stripo.email/en/articles/8541313-testing-configuration) 29. [Kit: Connect MCP to AI Tools](https://help.kit.com/en/articles/14827557-how-to-connect-the-kit-mcp-to-your-ai-tools) 30. [Kit: Create Broadcasts](https://help.kit.com/en/articles/2934648-creating-sending-and-publishing-broadcasts) 31. [Kit: Visual Email Template Editor](https://help.kit.com/en/articles/3297902-the-visual-email-template-editor) 32. [Loops: Email for Agents](https://loops.so/agents) 33. [Loops: Email Editor](https://loops.so/docs/creating-emails/editor) 34. [Loops: Using Templates](https://loops.so/docs/creating-emails/using-templates) 35. [Loops: MCP Status](https://loops.so/agents/mcp) 36. [Canva Newsletter Creator](https://www.canva.com/create/newsletters/) 37. [Figma Email Design Templates](https://www.figma.com/templates/email-design-templates/) 38. [Figma AI](https://www.figma.com/ai/) --- # AI-Generated Marketing Email: Pre-Send Review Checklist - Collection: Articles - Canonical URL: https://marketingwiki.ai/articles/ai-email-pre-send-review - Published: 2026-08-13 - Updated: 2026-08-13 - Last verified: 2026-08-13 - Author: Marketing Wiki Editors - Reviewer: Adam Lababidi - Topics: AI email, email QA, human approval, deliverability > A practical pass-or-fail checklist for reviewing AI-generated marketing emails before sending, with named owners and evidence for every gate. Do not approve an AI-generated marketing email because the draft looks finished. Approve it only after named owners pass ten checks against the exact content, audience, sender, and schedule that will go live. AI can find defects; a named human owns the send decision. [NIST identifies confabulation](https://doi.org/10.6028/NIST.AI.600-1) as confidently presented false content from generative AI and recommends reviewing sources and citations before deployment. Email adds more failure points: a valid claim can reach the wrong audience, a working template can break in a major inbox, and a clean test email can hide a failed personalization branch. This checklist is an operational review method, not legal advice. Email rules depend on recipient location, sender, organization, list source, and message classification. Have a qualified privacy or legal owner define the rules for your program. ## Ten pass-or-fail gates Every row needs a named owner and attached proof. "Looks good" is not evidence. | Gate | Pass when | Proof to attach | Evidence class | Default owner | | --- | --- | --- | --- | --- | | 1. Accuracy | Every product, price, date, discount, statistic, quote, comparison, and availability statement matches a current source of truth. | Claim ledger with dated sources | Supported | Content owner | | 2. Subject and sender identity | `From`, `Reply-To`, subject, and preview text identify the sender and describe the message without deception. | Received headers and inbox screenshot | Supported | Campaign owner | | 3. Audience and permission | List source, segment logic, exclusions, suppression state, and applicable consent or other sending basis are documented for this audience. | Audience version, query, and eligibility note | Supported, jurisdiction-limited | Audience or privacy owner | | 4. Unsubscribe and sender details | Required body link, one-click headers, sender address, and advertising disclosures are present and functional where applicable. | Received headers plus completed opt-out record | Supported plus vendor-documented | Privacy and sending owners | | 5. Accessibility | Informative images have useful text alternatives; decorative images are ignored; text contrast passes the chosen standard; meaning does not depend on color alone. | Audit output and reviewer notes | Supported baseline plus observed | Design or accessibility owner | | 6. Rendering | Final HTML passes the target mobile, desktop, light, dark, and image-blocked client matrix. Plain-text fallback remains understandable. | Dated client-matrix results | Vendor-documented need plus observed | Email QA owner | | 7. Links | Every visible CTA and linked image opens the intended final destination. Redirects, tracking parameters, anchors, `mailto:` links, and dynamic URLs are checked. | Link report and manual exception checks | Vendor-documented limit plus observed | Campaign operator | | 8. Personalization | Complete, missing, long, unusual, and ineligible recipient profiles render expected copy with safe fallbacks and no raw tokens. | Recipient-case matrix and captured output | Vendor-documented limit plus observed | Lifecycle owner | | 9. Sending requirements | Sending owner confirms current authentication, alignment, DNS, message format, unsubscribe, complaint, and suppression requirements for target providers. | Authentication results and provider checklist | Vendor-documented plus observed | Deliverability owner | | 10. Final test and approval | Reviewer inspects the received message and headers from the final send path, then named campaign owner signs the exact version. | Received test artifact and signed record | Observed | Campaign owner | One failed, expired, or unassigned gate blocks send. ## 1. Check claims against source material Verify facts before polishing grammar. Ask the AI or writer for a list of every checkable statement, then verify each one against product data, approved offer terms, legal copy, or another current source. The [FTC says US advertising claims must be truthful, non-deceptive, and evidence-based](https://www.ftc.gov/business-guidance/advertising-marketing). This checklist applies that same rule to AI-written copy. Higher-risk claims, including health, finance, safety, comparative performance, scarcity, and endorsements, need review from the owner who can assess their evidence and applicable rules. Pass evidence should identify: - claim as sent; - source URL or internal record; - source owner; - date checked; - reviewer decision. Delete unsupported copy. Softer wording does not repair a false underlying fact. ## 2. Read subject, preview, and sender fields together Review inbox chrome as one promise: display name, From address, Reply-To, subject, and preview text. Confirm the sending brand owns the identity and monitors replies where replies are invited. For US commercial email, the [FTC CAN-SPAM guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) says header and routing information must be accurate and subject lines must reflect message content. Other jurisdictions can add different duties. The campaign owner should record which rule set applies instead of treating one country's checklist as global policy. Fail examples: - subject starts with `Re:` when message is not a reply; - display name implies a person or company that did not send it; - preview text promises a discount missing from offer terms; - Reply-To points to an unmonitored mailbox. ## 3. Prove audience eligibility before reviewing creative AI should not infer permission from an email address, job title, public profile, purchase, or prior conversation. Audience owner must verify list provenance and current eligibility for this specific message. Record segment query or saved audience version, inclusion reason, exclusions, suppression timestamp, and applicable jurisdiction. The [ICO's UK guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-direct-marketing-using-electronic-mail/) shows why context matters: subscriber type, consent, soft opt-in conditions, message purpose, and use of personal information can change the rule. That guidance covers UK law, not a universal standard. Pass only after qualified owner confirms campaign against your program's approved audience policy. ## 4. Test unsubscribe and required sender details Inspect message body and received headers. Do not approve a visible unsubscribe link without testing the request and resulting suppression state. For US commercial messages, FTC guidance covers accurate sender identity, valid postal address, advertising identification, opt-out notice, and prompt handling of opt-out requests. Requirements depend on message classification. Separately, [Google's Gmail sender guidelines](https://support.google.com/mail/answer/81126) and [Yahoo's sender requirements](https://senders.yahooinc.com/best-practices/) publish authentication and unsubscribe conditions for mail sent to their users. [RFC 8058](https://www.rfc-editor.org/rfc/rfc8058.html) defines one-click signaling through `List-Unsubscribe` and `List-Unsubscribe-Post` headers. Sending owner should verify actual received headers, not assume email-builder settings produced them. ## 5. Use WCAG checks as baseline, then test email output [WCAG 2.2](https://www.w3.org/TR/WCAG22/) provides practical checks for text alternatives, color use, and contrast. For normal text, its Level AA minimum is 4.5:1; large text uses 3:1. Informative non-text content needs an equivalent text alternative, while decorative content should be ignorable by assistive technology. Apply those checks to final email, including CTA text, legal copy, image-based offers, and dark-mode variants. Then test with accessibility tooling and assistive technologies appropriate to audience. Passing these selected checks does not prove full WCAG conformance or legal compliance. Email-client support varies, so record tested clients and known limits. ## 6. Render where recipients read Browser preview proves little about inbox rendering. [Mailchimp documents that email programs display HTML differently](https://mailchimp.com/help/preview-and-test-your-email-campaign/). Build target matrix from audience client data when available, then cover important mobile and desktop environments. Inspect: - structure and reading order; - type size and line breaks; - CTA visibility and tap area; - image cropping, missing images, and alternative text; - light and dark modes; - long content and narrow screens; - plain-text version. Attach screenshots or test output for each required client. A generated preview is evidence only for environment that produced it. ## 7. Open every destination Automated link checks help, but they do not close gate. Mailchimp notes its checker cannot validate some links containing merge tags, anchors, or `mailto:` destinations. Other platforms have different limits. Click final tracked URLs from received test message. Confirm destination loads without authentication surprises, matches CTA promise, preserves required parameters, and shows same price, date, product, and disclosure as email. Check linked logos and images too. ## 8. Test personalization with real branch cases Generic test sends can give false confidence. Mailchimp documents that contact-specific merge tags and dynamic content may not populate in a normal test email; it recommends live-profile preview or a small controlled test segment for those cases. Choose profiles that exercise branches: - all fields present; - first name or company missing; - unusually long values; - non-Latin characters; - each conditional segment; - excluded or suppressed profile; - expired or unavailable offer. Fail on blank greetings, raw variables, wrong language, sensitive inferred traits, broken URLs, or copy that exposes segment logic. ## 9. Separate sender compliance from inbox predictions Content review cannot validate DNS or reputation. Deliverability owner should inspect authentication results and current requirements for receiving providers represented in audience. Google and Yahoo document requirements for SPF, DKIM, DMARC in qualifying cases, DNS, message format, complaint rates, and unsubscribe behavior. Check current pages at review time because requirements change. Do not approve claims such as "guaranteed inbox placement." Meeting published requirements addresses known provider conditions; it does not control every filtering decision. ## 10. Test received message, then freeze approval Send through final campaign path to controlled test recipients. Inspect actual received message, source headers, sender identity, subject, preview, images, links, personalization, footer, and unsubscribe behavior. If platform's test-send path skips audience data, use documented live-profile preview or controlled live test segment without exposing unapproved recipients. Approval record should bind to exact version: ```yaml campaign_version: "immutable ID or content hash" audience_version: "saved segment or query ID" sender: "display name " scheduled_at: "2026-08-12T14:00:00Z" gate_results: "link to signed checklist" approved_by: "named human" approved_at: "ISO-8601 timestamp" ``` Any change to content, audience, sender, offer, destination, or schedule should invalidate affected gates. Re-run those checks before send. Approval stays pending until a named human signs the exact version. For ownership and permissions before this review stage, use [AI email workflow from brief to send](/articles/ai-email-workflow-from-brief-to-send). For brand-specific review, use [brand consistency rubric](/articles/ai-email-brand-consistency-rubric). ## Sources for AI-Generated Marketing Email: Pre-Send Review Checklist 1. [NIST AI RMF Generative Artificial Intelligence Profile](https://doi.org/10.6028/NIST.AI.600-1) 2. [FTC Advertising and Marketing Basics](https://www.ftc.gov/business-guidance/advertising-marketing) 3. [FTC CAN-SPAM Act Compliance Guide for Business](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) 4. [ICO Guidance on Direct Marketing Using Electronic Mail](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-direct-marketing-using-electronic-mail/) 5. [Web Content Accessibility Guidelines 2.2](https://www.w3.org/TR/WCAG22/) 6. [Gmail Email Sender Guidelines](https://support.google.com/mail/answer/81126) 7. [Yahoo Sender Best Practices](https://senders.yahooinc.com/best-practices/) 8. [RFC 8058: Signaling One-Click Functionality for List Email Headers](https://www.rfc-editor.org/rfc/rfc8058.html) 9. [Mailchimp Preview and Test Your Email](https://mailchimp.com/help/preview-and-test-your-email-campaign/) 10. [Mailchimp Getting Started with Merge Tags](https://mailchimp.com/help/getting-started-with-merge-tags/) --- # How to Build an AI Email Workflow from Brief to Send - Collection: Articles - Canonical URL: https://marketingwiki.ai/articles/ai-email-workflow-from-brief-to-send - Published: 2026-08-13 - Updated: 2026-08-13 - Last verified: 2026-08-13 - Author: Marketing Wiki Editors - Reviewer: Adam Lababidi - Topics: AI email, workflow design, human approval, agent permissions > 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](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. 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: ```text 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](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. ## 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](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. 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: ```text 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](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. 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: ```yaml 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 " 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](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. 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](https://docs.migma.ai/email-editor/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](https://docs.migma.ai/campaigns/overview) | | `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](/articles/ai-email-pre-send-review). Use [brand consistency rubric](/articles/ai-email-brand-consistency-rubric) for design approval. ## Sources for How to Build an AI Email Workflow from Brief to Send 1. [NIST AI Risk Management Framework Core](https://airc.nist.gov/airmf-resources/airmf/5-sec-core/) 2. [NIST AI RMF Appendix C: AI Risk Management and Human-AI Interaction](https://airc.nist.gov/airmf-resources/airmf/appendices/app-c-ai-risk-management-and-human-ai-interaction/) 3. [NIST AI RMF Generative Artificial Intelligence Profile](https://doi.org/10.6028/NIST.AI.600-1) 4. [FTC CAN-SPAM Act Compliance Guide for Business](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) 5. [ICO Guidance on Direct Marketing Using Electronic Mail](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-direct-marketing-using-electronic-mail/) 6. [Google Email Sender Guidelines](https://support.google.com/mail/answer/81126) 7. [Migma MCP Server Documentation](https://docs.migma.ai/mcp-server) 8. [Migma Agents Documentation](https://docs.migma.ai/agents/overview) 9. [Migma Campaigns Documentation](https://docs.migma.ai/campaigns/overview) 10. [Migma Email Preflight Documentation](https://docs.migma.ai/email-editor/email-preflight) --- # How to Evaluate Brand Consistency in AI-Generated Emails - Collection: Articles - Canonical URL: https://marketingwiki.ai/articles/ai-email-brand-consistency-rubric - Published: 2026-08-13 - Updated: 2026-08-13 - Last verified: 2026-08-13 - Author: Marketing Wiki Editors - Reviewer: Adam Lababidi - Topics: AI email, brand consistency, email design, design review > A nine-part scoring rubric for brand and design reviewers deciding whether an AI-generated email should be approved, revised, or rejected. Approve an AI-generated email only when it matches a dated brand reference across nine areas and leaves evidence for every score. Use the rubric below to decide whether the exact email version is ready, needs revision, or should be rejected. Use this method to evaluate one email artifact. Platform and model remain out of scope. A brand kit records inputs; review determines whether the output follows them. This is an original operational rubric, not a validated scientific scale or product benchmark. Thresholds make team decisions consistent; they do not predict campaign performance or prove one tool better than another. > **Affiliation disclosure:** Marketing Wiki maintainers and contributors include people affiliated with Migma. Migma receives no score, ranking, or claim of superiority. ## Build the review packet first Freeze the material the reviewer will compare. A useful packet contains: - final HTML and rendered screenshots tied to an immutable version or content hash; - campaign brief, audience, primary message, and intended action; - current brand guide with version date and owner; - approved voice examples and prohibited terms; - exact color, typography, spacing, button, and footer tokens; - approved logo files, image treatments, and example campaigns; - desktop, mobile, light-mode, dark-mode, and image-blocked renders where relevant. Do not guess a missing brand rule. Mark that category `NE` for not evaluable, name the missing evidence, and return the review to the brand owner. Missing evidence blocks approval. ## Score each category from 0 to 2 | Score | Meaning | Reviewer action | | --- | --- | --- | | 2 | Output matches approved reference, or a documented exception is intentional. | Record evidence and keep. | | 1 | Localized drift can be corrected without changing campaign concept. | Request a specific revision and score again. | | 0 | Material mismatch affects identity, meaning, usability, or trust. | Reject this version. | | NE | Approved reference or test evidence is missing. | Pause approval and request evidence. | Any blocking defect overrides the total score. ## Nine-part brand consistency rubric | Category | Score 2: match | Score 1: revise | Score 0: reject | Evidence required | | --- | --- | --- | --- | --- | | Voice | Vocabulary, tone, formality, point of view, sentence shape, product names, and approved CTA language match the voice guide and reference copy. Prohibited terms are absent. | A few phrases drift in tone or terminology, but the message and position remain correct. | Copy uses the wrong persona, changes positioning, invents brand language, or conflicts with a named voice rule. | Voice-guide version, two approved samples, and annotated copy showing each checked passage. | | Color | Every visible color maps to an approved token and its allowed role. Background, text, link, accent, and state colors stay within the palette. | One or two local values are wrong, duplicated, or used in the wrong role. | Dominant palette belongs to another identity, obscures key content, or cannot be mapped to approved tokens. | Token list with exact values, rendered screenshots, and sampled color report. | | Typography | Heading, body, label, and CTA styles use approved font stacks, fallbacks, weights, sizes, line heights, and casing. | A local size, weight, line height, or fallback differs from the type scale. | Main type system is replaced, hierarchy collapses, or unsupported fonts leave no acceptable fallback. | Typography tokens, fallback stack, and rendered type samples from target inboxes. | | Spacing | Margins, padding, section rhythm, alignment, and density follow approved tokens or reference modules. Repeated elements use the same interval. | One section is too tight, loose, or misaligned, while the larger rhythm remains intact. | Layout density and alignment no longer resemble the brand system or make the message hard to scan. | Spacing tokens, annotated render with measured gaps, and approved module reference. | | Imagery | Logo variant, photography, illustration, crop, color treatment, product imagery, and icon style follow the guide. Asset source and usage approval are recorded. | One crop, treatment, or icon family needs a local change. | Wrong logo or product appears, imagery contradicts brand direction, or asset source and permission cannot be established. | Asset URL or file ID, approval or license record, image-treatment rule, and final crop. | | Hierarchy | First screen, section order, headline, supporting proof, and visual emphasis serve the brief. One primary message is easy to find. | One competing element or weak transition interrupts an otherwise clear reading order. | Wrong message dominates, essential context is buried, or structure points readers toward a different campaign goal. | Campaign brief and annotated desktop and mobile reading order. | | CTA | Primary CTA label, visual style, prominence, destination, and surrounding promise match the approved campaign action. Secondary actions remain subordinate. | CTA wording or styling drifts, but destination and offer remain correct. | CTA points to the wrong place, changes the offer, hides the intended action, or creates competing primary actions. | Approved action, final destination URL, button tokens, and received-email click test. | | Footer | Approved footer module uses the correct entity, address, links, preference or unsubscribe controls, social accounts, and visual treatment for the program. | Required elements work, but a local spacing, color, copy, or social-link treatment has drifted. | Wrong sender entity appears, a required element is absent, or an unsubscribe or identity link fails. | Approved footer reference, program requirements, received-email screenshot, and completed link tests. | | Accessibility | Content follows the program's chosen accessibility baseline. Text contrast, alternatives for informative images, reading order, descriptive links, and non-color cues are verified in final output. | One isolated issue is fixable and does not prevent the intended action. | A recipient cannot understand or complete the main action because of contrast, image-only meaning, broken reading order, or inaccessible link treatment. | Contrast report, alternative-text review, structure or reading-order check, and final rendered test. | For a WCAG 2.2 Level AA baseline, normal text needs at least 4.5:1 contrast and large text needs at least 3:1. WCAG also covers text alternatives and information conveyed through color. Treat these as selected checks, not proof of full WCAG conformance or legal compliance. See the [W3C Recommendation](https://www.w3.org/TR/WCAG22/). Footer requirements depend on message type, sender, recipients, and jurisdiction. For US commercial email, the [FTC CAN-SPAM compliance guide](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) covers accurate sender information, a valid postal address, and a working opt-out method. A qualified owner must define the rules for each email program. ## Decide: approve, revise, or reject Add the nine numeric scores only after every category has evidence. ### Approve Approve when all conditions are true: - total is 16 to 18; - no category is `0` or `NE`; - footer and accessibility both score `2`; - every exception is named, intentional, and approved; - reviewer signs the exact email version. ### Revise Request revision when: - total is 10 to 15 with no score of `0`; - any category is `NE`; - footer or accessibility scores `1`; - defects can be corrected without replacing campaign concept. List each change as a testable instruction. “Make it more on brand” cannot be reviewed. “Replace `#2367E8` with approved primary blue `#1D4ED8` on both CTA buttons” can. ### Reject Reject the version when: - total is 9 or lower; - any category scores `0`; - wrong brand, sender entity, offer, product, or CTA destination appears; - primary action is not usable; - resolving drift requires a new concept or broad structural rewrite. Record rejection against the email version. Save the evidence so a new version can be tested against the same packet. Tool-level conclusions require repeated tests. ## Copyable review record ```yaml email_version: "sha256 or immutable version ID" brief_version: "brief ID and date" brand_guide_version: "guide ID and date" reviewed_at: "ISO-8601 timestamp" reviewer: "named human" scores: voice: { score: 2, evidence: [], notes: "" } color: { score: 2, evidence: [], notes: "" } typography: { score: 2, evidence: [], notes: "" } spacing: { score: 2, evidence: [], notes: "" } imagery: { score: 2, evidence: [], notes: "" } hierarchy: { score: 2, evidence: [], notes: "" } cta: { score: 2, evidence: [], notes: "" } footer: { score: 2, evidence: [], notes: "" } accessibility: { score: 2, evidence: [], notes: "" } total: 18 decision: "approve | revise | reject" blocking_findings: [] required_changes: [] ``` Any edit to copy, assets, colors, layout, CTA, footer, or generated HTML invalidates affected scores. Re-run those categories against the new version. ## Use rubric for product comparison only with controlled evidence Brand kits and website import describe inputs, not output quality. A defensible platform comparison would give each product same source packet and campaign brief, generate repeated outputs, hide product identity from trained reviewers, publish raw category scores, and report reviewer disagreements. Until that test exists, score emails rather than vendors. Build source packet with [website-to-on-brand-email method](/articles/website-to-on-brand-email-with-ai). Use [AI email capability matrix](/articles/ai-email-design-tools-capability-matrix) for vendor documentation, then [pre-send review checklist](/articles/ai-email-pre-send-review) for final campaign gate. ## Sources for How to Evaluate Brand Consistency in AI-Generated Emails 1. [Web Content Accessibility Guidelines 2.2](https://www.w3.org/TR/WCAG22/) 2. [FTC CAN-SPAM Act Compliance Guide for Business](https://www.ftc.gov/business-guidance/resources/can-spam-act-compliance-guide-business) 3. [Brevo: Save Your Brand's Assets in the Brand Library](https://help.brevo.com/hc/en-us/articles/7868807168274-Save-your-brand-s-assets-in-the-brand-library) 4. [Customer.io: Set Global Styles](https://docs.customer.io/messaging/design-studio/emails/styles/set-styles/) 5. [Flodesk: Setting Up Your Brand in Flodesk Studio](https://help.flodesk.com/en/articles/12762561) 6. [Klaviyo: Add Branding From Your Website to Your Emails](https://help.klaviyo.com/hc/en-us/articles/39106892802331) 7. [Mailchimp: Use Brand Kit](https://mailchimp.com/help/use-brand-kit-creative-assistant/) 8. [Migma: Configure Your Brand](https://docs.migma.ai/get-started/configure-brand) --- # How to Turn a Website into an On-Brand Email with AI - Collection: Articles - Canonical URL: https://marketingwiki.ai/articles/website-to-on-brand-email-with-ai - Published: 2026-08-13 - Updated: 2026-08-13 - Last verified: 2026-08-13 - Author: Marketing Wiki Editors - Reviewer: Adam Lababidi - Topics: AI email, brand consistency, website import, email design > A practical method for deciding whether a website URL contains enough brand and content context for AI email generation, with a readiness checklist and source-bundle template. A website URL can give an AI email tool enough context for a useful first draft. It is rarely a complete brief. The URL works best when the site is public, current, and rich in real brand assets and representative copy. The marketer still needs to review what was extracted, add campaign facts the site does not contain, and approve the final email. Treat the website as a source, not an instruction to copy the page. Extract evidence into a small source bundle first. Then ask the AI to turn that bundle into an email. This keeps brand decisions, campaign facts, and generated copy separate enough to inspect. > **Affiliation disclosure:** Marketing Wiki's maintainer is affiliated with Migma. Migma appears as one documented example and receives no assumed quality, placement, or ranking benefit. ## Separate four jobs "Website to email" can describe four different jobs. A tool may support one without supporting the others. | Job | Input | Useful output | Main review question | | --- | --- | --- | --- | | Brand extraction | Homepage, CSS, images, public pages | Logos, color roles, fonts, button style, visual patterns | Did it capture the real system rather than a temporary campaign treatment? | | Content extraction | Product page, article, changelog, event page | Names, descriptions, dates, images, links | Are facts current and copied from the right page? | | Email generation | Goal, audience, offer, brand record, source content | Subject, preview text, body, layout, calls to action | Did the draft follow the brief without inventing claims? | | Email validation | Final HTML, text version, links, sender settings | Review findings and test evidence | Is this exact version ready for human approval? | A homepage often helps with brand extraction. A product or article URL may be better for content extraction. Neither one necessarily states the campaign audience, approved offer, send date, sender identity, or required footer. ## Website-input readiness checklist Run this checklist before pasting a URL into any AI tool. A failed row does not always block the project, but it tells you what to supply manually. | Check | Pass when | If it fails | | --- | --- | --- | | Public access | Page loads without login, password, region gate, or consent flow that hides the main content. | Paste approved text, upload assets, or use manual brand setup. | | Canonical identity | Header or footer contains current company name and a usable primary logo. | Upload approved light and dark logo files. | | Color evidence | Repeated interface elements reveal stable primary, accent, background, and text colors. | Add exact color values and label each color's role. | | Typography evidence | Heading and body type are identifiable, with sensible fallbacks available for email. | Name heading, body, and fallback fonts manually. | | Voice evidence | Site includes enough approved prose to show vocabulary, tone, sentence shape, and CTA language. | Add three to five approved copy samples plus words to use and avoid. | | Campaign facts | Source page states current product name, offer, date, price, terms, and destination needed by the email. | Attach a dated campaign brief and source-of-truth links. | | Image quality | Important images have stable, usable files rather than tiny thumbnails or inaccessible URLs. | Upload approved originals and record their intended use. | | Page scope | Selected pages represent normal brand behavior, not only a seasonal microsite or one experimental landing page. | Add homepage, core product, editorial, and conversion examples. | | Human owner | Someone can confirm brand choices and someone can confirm campaign facts. | Assign owners before generation. | Public access matters in documented product flows. [Mailchimp tells users to provide a public, non-password-protected URL and paste source text when its generator cannot access a page](https://mailchimp.com/help/create-email-content-with-ai/). [Migma's documentation likewise lists public access and crawler blocking as brand-import failure conditions](https://docs.migma.ai/get-started/configure-brand). Those are vendor-documented behaviors, not proof that every public page will import cleanly. ## Build a source bundle before generating Use one homepage plus the fewest additional pages needed to fill evidence gaps. A typical set is: - homepage for identity and broad visual language; - product, pricing, event, or changelog page for campaign facts; - article or About page for representative voice; - conversion page for CTA patterns and destination URLs; - approved brand files or guidelines when the website is incomplete. Record the result in a portable file. YAML is readable in review and easy to convert to JSON for schema validation. Markdown works too if the same fields and source links remain explicit. ```yaml source_bundle: verified_at: 2026-08-12 primary_url: https://example.com pages: - role: identity url: https://example.com - role: campaign_facts url: https://example.com/product - role: voice_sample url: https://example.com/blog/example brand: name: Example Company logos: primary_light: approved-file-or-url primary_dark: approved-file-or-url colors: primary: "#000000" accent: "#2457FF" background: "#FFFFFF" text: "#151515" typography: heading: "Approved heading font" body: "Approved body font" fallback: "Arial, sans-serif" buttons: shape: rounded primary_fill: "#2457FF" visual_rules: - Use one main call to action per section. - Prefer product photography over generic stock images. voice: description: Clear, informed, and concise. approved_samples: - exact excerpt or internal reference preferred_terms: [] avoid_terms: [] cta_patterns: [] campaign: goal: Announce verified product update audience: Existing opted-in customers primary_claim: Exact approved claim claim_source: https://example.com/product offer_terms: null expires_at: null primary_cta: label: View update url: https://example.com/product email: from_name: Example Company reply_to: monitored@example.com required_footer_source: approved internal record mobile_priority: true plain_text_required: true review: brand_owner: named human facts_owner: named human send_approver: named human ``` Do not ask the model to infer blank facts. Use `null`, `unknown`, or an explicit review flag. An empty expiry date should not become invented urgency. A missing customer quote should not become a plausible testimonial. ## Platform-neutral workflow ### 1. Capture source evidence Save the exact URLs and verification date. Download approved logo files where policy permits. Record color values and font roles rather than a screenshot alone. Copy only enough prose to demonstrate voice, and preserve links back to the original pages. ### 2. Correct the extracted brand record Website extraction is a starting point. Navigation colors, cookie banners, partner logos, seasonal graphics, and image backgrounds can compete with the real brand palette. Review each detected asset and assign a role. Keep a small approved set instead of every color or image the crawler finds. Several vendors build review into their documented setup. [Klaviyo says its brand library can detect logos, colors, buttons, and fonts from a website, then asks the user to review or deselect elements](https://help.klaviyo.com/hc/en-us/articles/39106892802331). [Brevo instructs users to verify fetched logo, colors, fonts, and links before importing them, with manual setup as the fallback](https://help.brevo.com/hc/en-us/articles/7868807168274-Save-your-brand-s-assets-in-the-brand-library). ### 3. Add facts that do not belong to the brand layer Brand voice cannot answer campaign questions. Add audience, purpose, approved claims, offer terms, dates, destinations, sender details, and required legal or preference content from their real sources. Keep those values separate from tone and design instructions so a brand update cannot silently change an offer. ### 4. Generate one inspectable draft Start with one email and a narrow request. Name source bundle, goal, audience, required sections, and forbidden inventions. Ask for editable output. Do not request multiple stylistic variants until one draft passes facts and brand review; otherwise the same source error spreads across every variant. ### 5. Compare output with evidence Review draft in four passes: 1. **Identity:** correct company name, logo variation, color roles, font fallbacks, and destinations. 2. **Voice:** approved vocabulary, sentence style, CTA language, and prohibited terms. 3. **Facts:** every product, price, date, quote, statistic, and offer matches named source. 4. **Email adaptation:** hierarchy, mobile reading order, alternative text, footer, dynamic fields, and plain-text version are ready for final QA. Delete unsupported copy. A sentence that sounds like brand is still wrong when source does not support it. ### 6. Test and approve exact version Website fidelity does not establish email readiness. Test final links, personalization, sender settings, accessibility, and target inbox rendering. Approval should identify exact version, evidence, named reviewer, and date. ## What current tools document This table describes official product documentation checked on August 12, 2026. It is not an independent product test or ranking. Availability, plans, and behavior can change. | Platform | Documented role for website or brand context | Review or fallback documented | Evidence limit | | --- | --- | --- | --- | | Brevo | [Brand library can fetch logo, colors, fonts, and links from a website](https://help.brevo.com/hc/en-us/articles/7868807168274-Save-your-brand-s-assets-in-the-brand-library). | Users verify fetched assets or switch to manual setup. | Documentation covers brand assets, not automatic extraction of full campaign strategy or approved claims. | | Flodesk | [Flodesk Studio lets users set business details, logos, colors, fonts, button style, and voice](https://help.flodesk.com/en/articles/12762561). | Brand fields are entered and reviewed directly; changes apply to new generations unless applied to existing email separately. | This source supports explicit brand setup, not a claim that Flodesk imports a full brand from any URL. | | Klaviyo | [Brand library can detect logos, colors, buttons, and fonts from a website](https://help.klaviyo.com/hc/en-us/articles/39106892802331). [Composer uses account and brand context to draft campaigns](https://help.klaviyo.com/hc/en-us/articles/52230280693403). | Detected assets can be deselected or replaced manually; Composer output remains subject to user review and approval. | Website detection is documented for new-account brand setup. No output-quality comparison was run. | | Mailchimp | [AI content creation can use a URL as source context](https://mailchimp.com/help/create-email-content-with-ai/). Its [Brand Kit stores logos, fonts, colors, personality, and button styles](https://mailchimp.com/help/use-brand-kit-creative-assistant/). | Users can refine generated sections, paste text when URL access fails, replace images, and edit Brand Kit fields. | A content URL and Brand Kit are distinct inputs. Documentation does not prove one URL supplies every campaign fact. | | Migma | [Migma documents website import for logos, colors, fonts, voice, and visual patterns](https://docs.migma.ai/get-started/configure-brand). | Documentation tells users to review results, fine-tune elements, or configure brand manually. | Vendor documentation only. No independent completeness, quality, or speed test was run. | | Resend | [Resend says its AI email editor can take a URL and extract brand, voice, and tone into a draft](https://resend.com/blog/ai-email-editor). | Editor supports inline changes and pre-send review. | This is a vendor announcement. "Any URL" and "ready-to-send" were not independently tested here. | | Stripo | [Stripo AI Hub asks for company, website, audience, tone, and language](https://support.stripo.email/en/articles/13374670-enhance-your-email-workflow-with-stripo-s-ai-hub). | Users edit project data, generated structure, content, and styles before saving. | Current help describes predefined style themes and calls website-generated styles a future feature. Do not treat website field as verified automatic visual-style import. | The products expose different boundaries. Some use a website to fill a reusable brand record. Some use a URL as content for one draft. Some rely on explicit brand fields. Compare the workflow you need, not the shared phrase "AI email generator." ## Failure-mode decision tree Use first matching branch. 1. **Tool cannot access page.** Paste approved source text, upload assets, or use manual brand setup. Do not weaken website security to help a generator crawl it. 2. **Import succeeds, but assets are wrong or noisy.** Correct logo, token roles, fonts, and button rules in brand record. Do not regenerate repeatedly from same bad extraction. 3. **Brand looks right, but campaign facts are missing.** Add dated product or offer sources and complete campaign section of source bundle. 4. **Draft invents facts or urgency.** Remove unsupported statements, mark missing fields, and regenerate only affected copy. 5. **Copy is accurate, but voice is generic.** Add approved samples, preferred terms, prohibited terms, and CTA patterns. Edit against examples rather than adding vague adjectives such as "friendly" or "premium." 6. **Draft matches website, but fails as email.** Simplify layout, supply font fallbacks, check mobile order, add required footer content, and test exact HTML in target clients. 7. **Draft passes review.** Lock version, run pre-send QA, and collect named human approval. ## Definition of done A website-derived email is ready for approval when a reviewer can trace every brand choice and factual claim to source bundle, identify every manual override, and inspect final email outside generator preview. The URL remains useful only when its evidence stays visible after generation. Next, score final output with [AI email brand consistency rubric](/articles/ai-email-brand-consistency-rubric), then run [pre-send review checklist](/articles/ai-email-pre-send-review). Buyer evaluating platforms can use [AI email capability matrix](/articles/ai-email-design-tools-capability-matrix). ## Sources for How to Turn a Website into an On-Brand Email with AI 1. [Migma: Configure Your Brand](https://docs.migma.ai/get-started/configure-brand) 2. [Mailchimp: Create Email Content with AI](https://mailchimp.com/help/create-email-content-with-ai/) 3. [Mailchimp: Use Brand Kit](https://mailchimp.com/help/use-brand-kit-creative-assistant/) 4. [Klaviyo: Add Branding from Your Website to Your Emails](https://help.klaviyo.com/hc/en-us/articles/39106892802331) 5. [Klaviyo: Getting Started with Composer](https://help.klaviyo.com/hc/en-us/articles/52230280693403) 6. [Brevo: Save Your Brand's Assets in the Brand Library](https://help.brevo.com/hc/en-us/articles/7868807168274-Save-your-brand-s-assets-in-the-brand-library) 7. [Flodesk: Setting Up Your Brand in Flodesk Studio](https://help.flodesk.com/en/articles/12762561) 8. [Resend: AI Email Editor](https://resend.com/blog/ai-email-editor) 9. [Stripo: Enhance Your Email Workflow with Stripo's AI Hub](https://support.stripo.email/en/articles/13374670-enhance-your-email-workflow-with-stripo-s-ai-hub) --- # Build a Marketing AI Operating System on GitHub - Collection: Articles - Canonical URL: https://marketingwiki.ai/articles/github-marketing-ai-operating-system - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: GitHub, agents, marketing operations > How to structure context, skills, agents, evidence, and outputs in a GitHub repository that compounds over time. GitHub can hold more than code. For a marketing team, a repository can preserve research, brand context, briefs, scoring rules, agent instructions, and approved outputs in one reviewable system. CXL describes the useful shift well: repository context lets tools such as Claude Code and Codex start from shared knowledge instead of asking marketers to paste the same instructions into every chat. This guide turns that idea into a small operating model. ## Minimum structure ```text marketing-ai-system/ ├── README.md ├── AGENTS.md ├── context/ ├── skills/ ├── agents/ ├── workflows/ ├── evidence/ ├── outputs/ └── tests/ ``` Each directory has one job. - `README.md` explains purpose, audience, and how to start. - `AGENTS.md` tells coding agents how to navigate and change repository. - `context/` stores durable business knowledge. - `skills/` contains focused instructions for repeatable tasks. - `agents/` composes skills into goal-oriented sequences. - `workflows/` documents triggers, inputs, approvals, and outputs. - `evidence/` stores research packets and claim sources. - `outputs/` holds examples worth reviewing or reusing. - `tests/` checks structure, links, forbidden claims, and expected formats. ## What belongs in context Context should be stable enough to help many tasks: - Audience and buying situations - Positioning and product facts - Voice and editorial rules - Approved terminology - Claims requiring proof - Channel constraints - Legal and compliance boundaries Do not turn context into a dump of every document. Agents perform worse when critical rules compete with stale meeting notes and duplicate messaging. ## Skills stay narrow A useful skill has one clear job, defined inputs, output contract, evaluation criteria, and stop conditions. Example: ```text skills/source-verification/ ├── SKILL.md ├── references/source-policy.md └── examples/verified-claim.json ``` One skill can support several agents. Source verification belongs in article writing, comparison updates, trend analysis, and product profiles. Reusing it prevents four slightly different evidence standards. ## Agents compose work Agent file should describe sequence and decisions, not duplicate full prompts. ```text Research article agent 1. Read approved brief. 2. Build evidence map. 3. Reject unsupported angle. 4. Draft from verified evidence. 5. Run factual and editorial checks. 6. Open pull request. ``` Publishing remains separate. Agent prepares change; reviewer decides whether it ships. ## Commits create memory Repository history answers questions chat cannot: - Which claim changed? - Who approved new wording? - Which source supported it? - Did traffic change after update? - Can prior version be restored? Small commits make that history useful. One article or workflow change per pull request works better than a weekly dump from an automated writer. ## Branches support experiments Branches let teams test a new rubric, skill, or page structure without changing current system. Compare output quality before merging. Keep benchmark inputs fixed when testing instruction changes. ## Automation with GitHub Actions GitHub Actions can run deterministic checks: - Validate frontmatter and schemas - Detect duplicate slugs and titles - Check internal links - Flag stale evidence - Build site - Compare generated indexes - Prevent direct agent publishing AI judgment should not decide whether deterministic validation passed. Let normal code perform those checks. ## First build sequence 1. Write one-page scope and audience context. 2. Convert one repeated task into a skill. 3. Add one workflow using that skill. 4. Save one strong example output. 5. Add a test describing acceptable result. 6. Run workflow several times. 7. Improve rules based on observed failures. System compounds when each run leaves better context, evidence, examples, or tests behind. Volume alone does not create that effect. ## Sources for Build a Marketing AI Operating System on GitHub 1. [CXL: GitHub for marketing AI workflows](https://cxl.com/blog/github-for-marketing-ai-workflows/) 2. [GitHub repository documentation](https://docs.github.com/en/repositories) 3. [GitHub Actions workflow concepts](https://docs.github.com/en/actions/concepts/workflows-and-actions/workflows) --- # Build an Evidence-Backed Content Agent - Collection: Articles - Canonical URL: https://marketingwiki.ai/articles/evidence-backed-content-agent - Published: 2026-08-10 - Updated: 2026-08-11 - Last verified: 2026-08-11 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: content operations, research, SEO > A research-to-pull-request workflow for producing useful marketing content without hallucinated claims or scaled-content sludge. Reliable content automation separates research from writing and publishing. Agent should prepare evidence-backed changes, then open a pull request for human review. This article explains architecture and editorial reasoning. Use [executable content-agent workflow](/workflows/evidence-backed-content-agent) to run process, or [index record](/index/evidence-backed-content-agent) for compact machine-readable definition. Google permits AI-assisted content, but warns that generating many pages without added user value can violate scaled-content policy. Production system therefore needs rejection rules, not only writing prompts. ## Pipeline ```text Opportunity → approved brief → evidence map → draft → claim verification → editorial review → SEO/AEO review → pull request → human approval ``` Each stage produces an artifact another stage can inspect. ## 1. Opportunity Opportunity record should answer: - Which reader problem exists? - Which query or task expresses it? - What current pages fail to provide? - What original asset can this page add? - Which existing page might it duplicate? Reject opportunities based only on keyword variation. "Best AI email tools for startups" and "best AI email tools for small companies" may describe same decision. ## 2. Brief Approved brief defines scope before research expands: ```yaml primary_intent: choose architecture for repeatable AI marketing work reader: marketer building first repository-based workflow required_asset: runnable folder structure and approval model must_answer: - when to use prompt, skill, workflow, or agent - where evidence lives - who can publish exclusions: - unsupported performance claims - vendor rankings ``` ## 3. Evidence map Research agent records claims before prose: | Claim | Source | Source type | Accessed | Status | | --- | --- | --- | --- | --- | | GitHub Actions runs repository workflows | GitHub Docs | Primary | 2026-08-10 | Supported | | AI content always ranks worse | None | Unsupported | 2026-08-10 | Reject | Source type matters. Vendor documentation supports what vendor says product does. It does not equal independent performance testing. ## 4. Draft Writing agent receives approved brief and evidence map. It should not browse new sources during drafting because hidden research makes verification harder. Draft requirements: - Direct answer near top - One distinct reader intent - Original template, example, test, or method - Source links near claims - Clear uncertainty - No invented quotes, numbers, or product behavior ## 5. Verification Verification agent checks every factual sentence against evidence map. Possible outcomes: - Supported - Vendor-documented - Inferred - Stale - Contradicted - Unsupported Unsupported claim gets removed or returned to research. Writer cannot quietly soften it into vague wording. ## 6. SEO and answer review Review technical basics: - Stable canonical URL - Useful title and description - Clear headings - Crawlable links - Internal topic relationships - Structured data matching visible page - Accurate publication and update dates - Short direct answer for question-led pages No special markup guarantees inclusion in an AI answer. Strong source clarity and useful page structure improve machine retrieval without pretending to control third-party systems. ## 7. Pull request Agent opens one focused pull request containing: - Article - Evidence map - Related-link updates - Generated index changes - Validation report Reviewer sees what changed and why. Agent cannot merge its own work. ## Publish gate Publish only when page passes five tests: 1. Distinct intent 2. Verified factual claims 3. Original value beyond source summaries 4. Relevant internal relationships 5. Named human approval Production volume should follow passing pages, not precede them. ## Sources for Build an Evidence-Backed Content Agent 1. [Google guidance on generative AI content](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content) 2. [Google spam policies](https://developers.google.com/search/docs/essentials/spam-policies) --- # Prompts vs Skills vs Agents for Marketing Work - Collection: Articles - Canonical URL: https://marketingwiki.ai/articles/prompts-vs-skills-vs-agents - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: prompts, skills, agents > A file-level architecture for deciding when marketing instructions should stay a prompt, become a reusable skill, or join an agent workflow. Use a prompt for one request, a skill for a repeatable method, and an agent when work requires several decisions or tools. Confusing these layers creates giant prompts that are hard to test, reuse, or update. ## Prompt A prompt describes current task and desired result. ```text Review this landing-page draft for clarity. Audience is operations leaders at 50-200 person SaaS companies. Return five specific edits. ``` Prompt works when context is local, stakes are low, and method does not need to survive current conversation. ## Skill A skill packages a method so several agents and people can apply same standard. ```text skills/landing-page-review/ ├── SKILL.md ├── references/rubric.md └── examples/review.md ``` Skill defines: - When to use it - Required inputs - Review sequence - Evidence rules - Output format - Failure and stop conditions Agent Skills specification uses `SKILL.md` as entry point and supports progressive disclosure through linked references. That keeps core instruction small while detailed material remains available when needed. ## Agent Agent owns goal requiring several steps: ```text Goal: improve landing-page conversion hypothesis quality. 1. Read audience context. 2. Analyze page and current evidence. 3. Run landing-page review skill. 4. Generate test hypotheses. 5. Score hypotheses against experiment rubric. 6. Prepare review packet. ``` Agent decides which skill or tool to use and when to stop. Permissions should match goal. Drafting hypotheses does not require access to deploy site changes. ## Workflow Workflow describes operating process around agent: - Trigger - Owner - Inputs - Agent or skills used - Approval points - Destination - Measurement - Recovery path Workflow may be fully deterministic or contain an agentic step. Calling every workflow an agent hides where decisions occur. ## Decision table | Need | Use | | --- | --- | | One output from current context | Prompt | | Repeatable task with stable standard | Skill | | Several decisions or tools toward a goal | Agent | | Team process with owners and approvals | Workflow | ## Common failure: giant prompt Large prompts often mix brand context, task instructions, scoring rules, examples, tool policy, and output schema. One edit can break unrelated behavior. Split by ownership: - Context states facts and constraints. - Skill states method. - Prompt states current request. - Agent states sequence and decisions. - Workflow states people, approvals, and system boundaries. ## Common failure: agent without eval An agent that runs repeatedly needs a fixed way to judge results. Keep a small benchmark set of representative inputs and expected properties. Test instruction changes against same set before adopting them. ## Practical migration Start with prompts already used every week. Extract shared method into one skill. Add examples only when they teach a concrete boundary. Compose agent after two or more skills need coordination. Architecture should grow from repeated work. Empty agent folders and generic prompt libraries create maintenance without improving output. ## Sources for Prompts vs Skills vs Agents for Marketing Work 1. [Agent Skills specification](https://github.com/agentskills/agentskills/blob/main/docs/specification.mdx) --- # SEO vs AEO vs GEO in 2026: What Search and AI Platforms Actually Say - Collection: Articles - Canonical URL: https://marketingwiki.ai/articles/seo-vs-aeo-vs-geo - Published: 2026-08-10 - Updated: 2026-08-11 - Last verified: 2026-08-11 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: SEO, AEO, GEO > Evidence-backed guide to Google AI search, ChatGPT, Claude, Bing, crawler access, structured data, llms.txt, and citation measurement. SEO, AEO, and GEO do not require three separate publishing systems. Google treats visibility in AI Overviews and AI Mode as search: pages must be public, indexed, useful, and eligible to show a snippet. ChatGPT, Claude, and Bing add crawler and measurement details, but none offers a file, schema type, or wording pattern that guarantees citation. Use AEO and GEO as measurement lenses. Keep SEO as implementation base. ## Working definitions | Term | Useful meaning | What changes in practice | | --- | --- | --- | | SEO | Earn discovery and useful search traffic. | Technical access, clear site structure, people-first content, links, and measurement. | | AEO | Make a page able to answer a specific question without losing necessary context. | State conclusion early, define terms, show conditions, and cite evidence beside claims. | | GEO | Measure whether generated answers mention, retrieve, or cite a source correctly. | Publish original evidence, keep entities and dates clear, then test citations across repeatable prompt sets. | Labels help teams assign work. They do not describe separate ranking systems that publishers can manipulate. ## What platforms document ### Google: AI search still uses search fundamentals [Google's 2026 AI optimization guide](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) says its generative search features use established Search systems. Supporting pages must already be indexed and snippet-eligible. Google recommends crawlable text, descriptive internal links, accurate structured data, useful media, and non-commodity information. Google also names tactics publishers can ignore: - `llms.txt` does not help or hurt Google visibility. - Tiny content “chunks” are not required. - Rewriting prose for an imagined LLM style is unnecessary. - Query-variant pages can cross into scaled-content abuse. - Inauthentic mentions do not build durable authority. [Google's people-first guidance](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) asks whether a page contains original reporting, research, or analysis and whether readers can identify who created it, how it was produced, and why it exists. That is higher-value work than adding another acronym to a title. ### OpenAI: allow search crawler, then measure referrals [OpenAI's publisher FAQ](https://help.openai.com/en/articles/12627856-publishers-and-developers-faq) assigns different jobs to its crawlers. `OAI-SearchBot` supports ChatGPT search visibility. `GPTBot` concerns potential model training. Allowing one does not require allowing the other. OpenAI says eligible public sites can appear in ChatGPT search, but top placement cannot be guaranteed. ChatGPT referral links include `utm_source=chatgpt.com`, which gives publishers a concrete traffic segment to measure. ### Anthropic: search, user fetches, and training are separate choices [Anthropic documents three crawler roles](https://support.anthropic.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler): `Claude-SearchBot` improves search results, `Claude-User` retrieves pages in response to user requests, and `ClaudeBot` supports model development. Publishers can express different rules for each user agent. ### Bing: evidence and freshness affect grounding eligibility [Bing Webmaster Guidelines](https://www.bing.com/webmasters/help/webmaster-guidelines-30fba23a) connect search discovery with Copilot grounding. Bing recommends crawlable internal links, canonical URLs, accurate sitemap dates, clear headings, explicit facts, consistent entity names, and structured data that matches visible content. [IndexNow](https://www.indexnow.org/documentation) can notify Bing and participating engines when a canonical URL is added, materially updated, or removed. A successful submission confirms receipt, not indexing or ranking. ## Minimum viable citation-ready page This table is a publish gate, not a promise of visibility. | Surface | Minimum standard | Why it matters | | --- | --- | --- | | Canonical HTML | Public `200` page with substantive server-rendered text | Search and answer systems need one stable source to retrieve. | | Title and H1 | One clear topic and one reader intent | Engines and readers should agree on page purpose. | | Direct answer | Conclusion plus boundary near top | Readers can confirm relevance without losing nuance. | | Evidence | Primary links beside material claims | Citation systems and reviewers can verify statements independently. | | Authorship | Visible author, reviewer, method, and affiliation | Trust requires knowing who made and checked page. | | Freshness | Published, modified, and verified dates with real changes | Dates should describe evidence state, not deployment time. | | Original asset | Test, dataset, method, decision table, or runnable workflow | Commodity summaries give systems little reason to select new source. | | Internal links | Topic hub, related workflow, method, and correction path | Crawlers find context; readers get useful next step. | | Machine view | Accurate JSON, JSONL, RSS, or API when consumers need it | Direct consumers can reuse same records without scraping layout. | ## Structured data: describe page, do not decorate it Structured data helps disambiguate page type and entities. It is not special AEO markup. Google says generative Search needs no extra schema. Use narrow, truthful types: - `Article` or `TechArticle` for editorial guides - `Organization` and `WebSite` for publisher identity - `BreadcrumbList` for hierarchy - `Dataset` with `DataDownload` only for a real downloadable dataset - `SoftwareApplication` only when profile describes a specific application and supported properties are known [Google's Article guidance](https://developers.google.com/search/docs/appearance/structured-data/article) recommends author type plus a URL that identifies author. Markup should include visible publication and modification dates. Hidden, invented, or mismatched properties can make structured data misleading. ## `llms.txt`, JSONL, MCP, and agent skills These surfaces solve different jobs: | Surface | Keep it when | Do not claim | | --- | --- | --- | | `llms.txt` | Compatible agents need a short map to canonical pages. | Google ranking or universal agent ingestion. | | JSON or JSONL | Consumers need stable fields, sources, dates, and full text. | Automatic training or citation. | | RSS or Atom | Readers and systems need change subscriptions. | Complete catalog semantics. | | Read-only API or MCP | Agents need filtering and bounded retrieval at runtime. | Better web ranking because endpoint exists. | | Agent skill | Installed agents need instructions for querying and citing records. | Automatic discovery by every agent. | [`llms.txt`](https://llmstxt.org/) remains a proposal. It is cheap to maintain from same content manifest, but canonical HTML, sitemap, and evidence deserve priority. ## Crawler policy for reference publishers Wildcard `Allow: /` covers ordinary search and AI crawlers when no later rule overrides it. Publishers that want retrieval without potential training can create explicit groups for `OAI-SearchBot`, `GPTBot`, `Claude-SearchBot`, `Claude-User`, and `ClaudeBot`. Treat robots rules as preferences, not access control or licensing. CDN challenges and bot protection can still block a crawler even when `robots.txt` allows it. Test representative URLs without cookies or login. ## Article UX that helps humans and extraction systems Good answer pages remain normal editorial pages: 1. Write one descriptive title and visible H1. 2. Answer main question in first two paragraphs. 3. Use headings that reflect decisions, not keyword variants. 4. Put evidence link next to claim it supports. 5. Use tables for repeated comparisons and exact mappings. 6. Show limitations where result changes by model, date, geography, or account state. 7. End with useful next action, not recap. This structure improves scanning and verification. It does not require turning every section into FAQ or forcing prose into tiny blocks. ## Measure visibility as reproducible experiment Track four different outcomes: 1. **Indexing:** canonical URL appears in Google and Bing webmaster tools. 2. **Search performance:** impressions, clicks, and query coverage. 3. **AI referral traffic:** visits tagged by ChatGPT or other referrers. 4. **Answer visibility:** mention, retrieval, and citation rate across fixed prompts. For answer tests, record prompt, model, date, geography, account state, web-search state, and repeat count. Score mention separately from citation, and correct citation separately from mere URL appearance. One generated answer is an anecdote. Use [AI search visibility workflow](/workflows/measure-ai-search-visibility) for test steps and [benchmark protocol](/research/ai-search-visibility-benchmark) for result structure. ## Direct answers ### Does an exact-match domain improve AEO or SEO? It can help people understand and remember site. It does not create special AI or search eligibility. Choose domain for durable identity, then build authority through useful evidence and relevant links. ### Can AI-generated content rank? Production method is not automatic disqualifier. Google evaluates usefulness, originality, reliability, and policy compliance. Large sets of low-value pages created to manipulate visibility can violate scaled-content policy. ### Does valid schema guarantee citation? No. Accurate schema can help systems understand content and enable supported rich results. It cannot force search ranking, grounding, or citation. ### How does a new site become reference? Publish narrow pages with evidence others can verify and reuse. Keep stable URLs. Release original datasets, methods, and benchmark results. Earn links and citations because source saves others work. ## Sources for SEO vs AEO vs GEO in 2026: What Search and AI Platforms Actually Say 1. [Google AI optimization guide](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) 2. [Google AI features and your website](https://developers.google.com/search/docs/appearance/ai-features) 3. [Google people-first content guidance](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) 4. [Google Article structured data guidance](https://developers.google.com/search/docs/appearance/structured-data/article) 5. [OpenAI publisher and developer FAQ](https://help.openai.com/en/articles/12627856-publishers-and-developers-faq) 6. [Anthropic web crawler guidance](https://support.anthropic.com/en/articles/8896518-does-anthropic-crawl-data-from-the-web-and-how-can-site-owners-block-the-crawler) 7. [Bing Webmaster Guidelines](https://www.bing.com/webmasters/help/webmaster-guidelines-30fba23a) 8. [IndexNow protocol documentation](https://www.indexnow.org/documentation) 9. [llms.txt proposal](https://llmstxt.org/) --- # What Is a Marketing AI Agent? - Collection: Articles - Canonical URL: https://marketingwiki.ai/articles/what-is-a-marketing-ai-agent - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: agents, automation, marketing operations > A practical definition of marketing AI agents, copilots, workflows, and automation, with a decision test for real autonomy. A marketing AI agent pursues a goal across several steps, chooses actions, uses tools, and reports what happened. Autocomplete and one-shot text generation do not meet that bar. That distinction matters because permissions and failure modes change as software moves from suggesting work to executing it. ## Four useful levels | Level | What it does | Example | Main risk | | --- | --- | --- | --- | | Generator | Produces one output from one request | Draft five subject lines | Weak or invented output | | Copilot | Helps a person complete a task | Suggest edits inside a campaign brief | Over-trust during review | | Workflow | Runs a fixed sequence | Research, draft, score, then export | Bad rules repeat at scale | | Agent | Selects steps and tools to reach a goal | Investigate a traffic drop and propose fixes | Unbounded action or false conclusions | Many useful marketing systems sit between workflow and agent. They can make limited decisions while keeping publishing, spending, sending, and data changes behind approval. ## Agent test Ask five questions before accepting an agent claim: 1. **Goal:** Can it work from an outcome, or does it need every step specified? 2. **Planning:** Can it choose or revise a path after new information appears? 3. **Tools:** Can it retrieve data or take actions outside its text window? 4. **State:** Can it preserve relevant decisions and evidence across steps? 5. **Control:** Can a person inspect, approve, stop, and reverse consequential actions? A product does not need maximum autonomy to be useful. Bounded systems often work better because teams can understand why something happened. ## Marketing examples ### Research agent Goal: identify meaningful changes in AI search visibility. Agent searches primary sources, records dates, separates product announcements from measured evidence, and prepares a cited brief. It cannot publish without review. ### Content refresh agent Goal: keep high-value guides accurate. Agent checks links, product versions, screenshots, factual claims, and search intent. It opens a proposed update with a change summary. It does not change publication dates when nothing substantive changed. ### Campaign agent Goal: prepare a campaign for an approved audience. Agent can draft strategy, copy, creative requirements, tests, and measurement plans. Audience upload, budget changes, and sending remain explicit approval points. ## Permissions define risk Reading a public page and changing an ad budget are different classes of action. Agent design should make that visible. - Read tools collect evidence. - Draft tools create reversible artifacts. - Write tools change shared systems. - Transaction tools spend money, send messages, or affect customers. Grant minimum permission needed for current task. Log tool calls and results. Require approval for actions that create external consequences. ## Good first agent Start with recurring work that has clear inputs, review criteria, and a reversible output. Research briefs, content refreshes, analytics summaries, and campaign QA fit well. Avoid starting with open-ended publishing or media buying. Those systems combine uncertain judgment with immediate external impact. ## Working definition Use this definition in briefs and evaluations: > A marketing AI agent is a bounded system that can plan and execute several tool-assisted steps toward a marketing goal while preserving evidence, permissions, and human control. When product claims omit tools, permissions, state, or approval behavior, treat "agent" as marketing language until verified. ## Sources for What Is a Marketing AI Agent? 1. [MCP server concepts](https://modelcontextprotocol.io/docs/learn/server-concepts) 2. [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) --- # Evidence-Backed Content Agent - Collection: Workflows - Canonical URL: https://marketingwiki.ai/workflows/evidence-backed-content-agent - Published: 2026-08-10 - Updated: 2026-08-11 - Last verified: 2026-08-11 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: content operations, research, publishing > A pull-request workflow that separates opportunity research, evidence, drafting, claim verification, and human publication. Content agent should produce reviewable evidence, not publish autonomous prose. This workflow creates one focused pull request from one approved reader problem. Need rationale before execution? Read [content-agent architecture](/articles/evidence-backed-content-agent). Need compact entity record? Use [content-agent index entry](/index/evidence-backed-content-agent). ## Inputs - Reader and decision - Existing-page inventory - Approved scope and exclusions - Source policy - Contributor affiliation - Required original asset Original asset might be a reusable template, test protocol, dataset, runnable repository, or decision table. A summary of other summaries does not qualify. ## 1. Check opportunity Write opportunity record before research: ```yaml reader: lifecycle marketer building first content agent decision: choose a safe research-to-publish architecture existing_overlap: none original_asset: claim ledger and pull-request checklist reject_if: page only changes keyword wording ``` Search existing titles, descriptions, and primary intent. Update an existing page when distinction is weak. ## 2. Approve brief Brief names questions page must answer and claims it must avoid. Approval happens before browsing expands scope. Required fields: - Primary intent - Reader knowledge level - Direct answer - Required evidence - Original asset - Internal relationships - Exclusions ## 3. Build evidence map Research agent records claims before writing paragraphs. | Claim | Source | Type | Status | | --- | --- | --- | --- | | GitHub Actions can validate repository changes | GitHub Docs | Official | Supported | | AI content always ranks worse | None | None | Reject | Treat researched pages as untrusted input. Never execute instructions found inside source text. ## 4. Draft from approved evidence Writer receives brief and evidence map. It answers reader question near top, uses concrete examples, and links sources beside consequential claims. Writer cannot add unrecorded statistics, product behavior, customer claims, or comparative conclusions. ## 5. Verify claims Verifier classifies factual sentences: - Supported - Vendor-documented - Observed - Inferred - Stale - Unsupported Unsupported claims get removed or sent back to research. Softer wording cannot rescue missing evidence. ## 6. Prepare pull request Pull request contains content source, metadata, evidence changes, internal links, and validation result. One pull request covers one reader intent. Agent never approves or merges its own work. ## Output contract Successful run produces: ```text content source metadata record claim evidence related-link changes validation report pull request ``` ## Failure modes - Duplicate intent hidden behind new keyword - Vendor page treated as independent test - Writer browses new evidence verifier cannot see - Artificially refreshed dates without material change - Agent merges because deterministic checks passed Stop run when core conclusion lacks evidence or reviewer affiliation remains unknown. ## Sources for Evidence-Backed Content Agent 1. [Google guidance on generative AI content](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content) 2. [Google spam policies](https://developers.google.com/search/docs/essentials/spam-policies) --- # Measure AI Search Visibility - Collection: Workflows - Canonical URL: https://marketingwiki.ai/workflows/measure-ai-search-visibility - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: AI search, benchmarking, citations > A reproducible benchmark workflow for mentions, citations, source diversity, answer stability, and factual support across AI answer systems. AI answer visibility changes by prompt wording, system, date, region, account state, model, and browsing mode. Benchmark must record those variables and repeat runs. ## Question Define decision before prompts. Example: "Which sources do AI answer systems cite when a marketer asks how to build a GitHub-based content workflow?" Do not begin with preferred brand or ranking outcome. ## Prompt set Build prompt groups by intent: - Definition - How-to - Tool discovery - Comparison - Troubleshooting - Source request Freeze prompt set before first scored run. Publish exact text. ## Systems and settings Record: - Product and model label shown to user - Browsing or search mode - Account tier - Region and interface language - Run timestamp - New or continuing conversation ## Repetitions Run each prompt at least three times per system in fresh conversations. More repetitions improve stability estimate but cost more. Save complete answer, visible citations, cited URLs, and access failures. Screenshots help audit UI but structured text remains main result. ## Scoring Separate measures: | Measure | Definition | | --- | --- | | Mention rate | Runs naming entity or source | | Citation rate | Runs linking source | | Supported citation | Citation supports nearby answer claim | | Source diversity | Unique cited domains across runs | | Stability | Similarity of results across repeated runs | No single overall visibility score until weights have external reason. ## Publication Release prompt file, raw answer records where terms allow, scoring code, dated result table, limitations, and conflicts. ## Failure modes - One favorable answer treated as benchmark - Prompt contains target brand and inflates mention rate - Search mode differs between systems - Citation counted without checking claim support - Result published without model/date - Benchmark headline survives after protocol changes Results expire. Schedule rerun based on material system change, not arbitrary freshness badge. ## Sources for Measure AI Search Visibility 1. [Google AI optimization guide](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) 2. [OpenAI publisher and developer FAQ](https://help.openai.com/en/articles/12627856-publishers-and-developers-faq) --- # Verify a Marketing AI Tool Profile - Collection: Workflows - Canonical URL: https://marketingwiki.ai/workflows/verify-marketing-ai-tool - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: tool index, verification, product claims > A repeatable workflow for separating documented capabilities, observed behavior, editorial inference, stale claims, and unknowns. Tool directory becomes useful when every record shows evidence state. Logo, tagline, and feature list copied from vendor page create marketing inventory, not independent index. ## Inputs - Canonical product URL - Official documentation - Public pricing page - Public API or integration documentation - Maintainer and submitter affiliations - Defined test task, when observed evidence is claimed ## 1. Define profile scope State exact job profile helps evaluate. "AI marketing platform" is too broad. "Turns approved brief into editable email series" can be checked. Define: - Target user - Marketing job - Required input - Expected output - Human approval points - Data access and action permissions ## 2. Record official claims Official documentation supports `vendor-documented` status. It does not prove speed, quality, reliability, or superiority. Store claim with source URL and verification date: ```yaml statement: Product exposes public API source_type: official-documentation status: vendor-documented verified_at: 2026-08-10 ``` ## 3. Run bounded test Observed result requires reproducible task: - Fixed input - Account tier - Product or model version - Date and region - Expected success condition - Raw output or trace Do not turn one successful run into universal capability claim. ## 4. Build claim ledger Use five visible states: | State | Meaning | | --- | --- | | Official | Vendor or publisher documents it | | Observed | Dated test produced result | | Inferred | Evidence supports conclusion indirectly | | Stale | Source or test needs refresh | | Unknown | Evidence cannot answer question | ## 5. Review conflicts Disclose contributor relationship: maker, employee, investor, partner, customer, affiliate, or none. Affiliated profiles use same fields and require unaffiliated review when practical. ## Publish gate Profile ships only when canonical URL, material claims, source types, verification dates, affiliation, and correction path are present. ## Failure modes - Vendor marketing copy presented as editorial conclusion - Pricing without check date - Integration logo treated as working integration - Beta access presented as general availability - Unpublished test result converted into ranking - Maintainer-affiliated product receives featured placement ## Sources for Verify a Marketing AI Tool Profile 1. [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) 2. [Google people-first content guidance](https://developers.google.com/search/docs/fundamentals/creating-helpful-content) --- # Agent Skills - Collection: Index - Canonical URL: https://marketingwiki.ai/index/agent-skills - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: skills, agents, repository context > Portable folders that package task-specific instructions, references, scripts, and assets for AI agents. Agent skill stores reusable method in folder centered on `SKILL.md`. Metadata helps agent decide when skill applies. Body gives workflow after skill triggers. Optional references, scripts, and assets carry deeper context. ## Marketing use Good candidates: - Source verification - Research brief creation - Tool-profile review - Campaign QA - Brand voice editing - Analytics investigation One-off request can remain prompt. Repeated method with defined inputs, outputs, checks, and stop conditions belongs in skill. ## Design rule Keep skill narrow. One source-verification skill can support article agent, comparison agent, trend agent, and catalog-refresh agent without copying evidence policy into four places. ## Evidence state Format description follows published Agent Skills specification. No cross-client compatibility test is attached yet. ## Sources for Agent Skills 1. [Agent Skills specification](https://github.com/agentskills/agentskills/blob/main/docs/specification.mdx) --- # Evidence-Backed Content Agent - Collection: Index - Canonical URL: https://marketingwiki.ai/index/evidence-backed-content-agent - Published: 2026-08-10 - Updated: 2026-08-11 - Last verified: 2026-08-11 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: content agent, research, pull requests > Repository agent that turns approved brief and claim evidence into one validated pull request for human review. Evidence-backed content agent is reference architecture used by this project. It separates opportunity, brief, evidence, draft, verification, and pull request. [Architecture article](/articles/evidence-backed-content-agent) explains why stages exist. [Runnable workflow](/workflows/evidence-backed-content-agent) defines execution steps and stop conditions. ## Inputs - Approved content brief - Evidence map - Editorial policy - Source policy - Voice rules - Existing content manifest ## Outputs - Markdown content - Metadata record - Evidence links - Internal-link updates - Validation result - Focused pull request ## Permissions Agent may read public sources, edit branch files, run validation, and open pull request. It may not merge, deploy, weaken branch protection, or publish directly. ## Stop conditions Agent stops when request duplicates existing intent, core conclusion lacks evidence, comparison has no consistent test, or contributor conflict is unknown. ## Evidence state Reference architecture is documented and encoded in repository skill. Production quality benchmark has not been run yet. ## Sources for Evidence-Backed Content Agent 1. [Marketing Wiki content-agent workflow](https://marketingwiki.ai/workflows/evidence-backed-content-agent) 2. [Google guidance on generative AI content](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content) --- # GitHub Actions - Collection: Index - Canonical URL: https://marketingwiki.ai/index/github-actions - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: GitHub, continuous integration, content operations > Repository automation for validating content schemas, generated files, links, builds, and review gates. GitHub Actions runs workflows in response to repository events. Marketing content repository can use it to validate structure before human review. ## Useful jobs - Validate metadata schema - Reject duplicate slugs - Regenerate machine-readable indexes - Detect unexpected generated-file changes - Build website - Check internal links - Report stale evidence dates ## Boundary Workflow can prove file matches schema. It cannot prove recommendation is fair, evidence supports interpretation, or page deserves publication. Keep agent permissions narrow. Content agent can propose branch. Workflow checks branch. Human reviewer approves merge. ## Marketing Wiki use Current validation runs content generation, checks generated manifest, lints site, builds production output, and renders key routes. Main branch should require these checks after GitHub repository exists. ## Evidence state Capability description comes from official GitHub documentation. No independent reliability or performance benchmark has been run for this index entry. ## Sources for GitHub Actions 1. [GitHub Actions workflow documentation](https://docs.github.com/en/actions/concepts/workflows-and-actions/workflows) 2. [GitHub protected branches](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/managing-a-branch-protection-rule) --- # Model Context Protocol - Collection: Index - Canonical URL: https://marketingwiki.ai/index/model-context-protocol - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: MCP, agents, tool access > Open protocol for connecting AI applications to tools, data sources, prompts, and reusable context through defined server interfaces. Model Context Protocol defines how AI applications connect to external capabilities. Server can expose tools for model-called actions, resources for application-selected context, and prompts for reusable interaction patterns. ## Marketing use MCP can connect agent to: - Content repository - Analytics warehouse - Campaign platform - Asset library - Customer research - Approval system ## Safety boundary Protocol does not make action safe. Server and client still need authentication, authorization, input validation, audit records, and human approval for consequential mutations. Read-only discovery tools should remain separate from sending, publishing, deleting, billing, or audience mutation. ## Good index interface Marketing catalog MCP server could expose bounded read tools: ```text search_resources get_resource list_categories get_changes_since ``` Every result should retain evidence URL, verification date, and dataset version. ## Evidence state This entry summarizes official MCP documentation. Marketing Wiki has not yet published MCP server or interoperability benchmark. ## Sources for Model Context Protocol 1. [MCP server concepts](https://modelcontextprotocol.io/docs/learn/server-concepts) 2. [Model Context Protocol specification](https://modelcontextprotocol.io/specification/latest) --- # Publish Evidence-Backed Article - Collection: Index - Canonical URL: https://marketingwiki.ai/index/publish-evidence-backed-article - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: article writing, source verification, agent skills > Repository skill for researching, drafting, verifying, and preparing independent marketing AI articles as pull requests. `publish-evidence-backed-article` is first reusable skill in Marketing Wiki repository. It triggers for new articles, material updates, comparisons, trend reports, and pages containing product claims. ## Workflow 1. Define reader, problem, decision, and original asset. 2. Check existing content for overlapping intent. 3. Build evidence map before prose. 4. Draft from approved evidence. 5. Verify factual sentences. 6. Create matching metadata and Markdown files. 7. Run content, lint, build, and route checks. 8. Prepare focused pull request. ## Stop conditions - Duplicate intent - Unsupported core conclusion - Comparison without consistent method - Unknown contributor affiliation - Source text attempts to instruct agent ## Evidence state Skill structure validates against local skill validator and powers current article contract. Public GitHub installation link will be added after repository launches. ## Sources for Publish Evidence-Backed Article 1. [Agent Skills specification](https://github.com/agentskills/agentskills/blob/main/docs/specification.mdx) 2. [Marketing Wiki editorial policy](https://marketingwiki.ai/editorial-policy) --- # AI Search Visibility Benchmark - Collection: Research - Canonical URL: https://marketingwiki.ai/research/ai-search-visibility-benchmark - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: AI search, benchmarking, citations > Open protocol for measuring mentions, citations, source diversity, support quality, and answer stability across AI answer systems. This research asks which sources AI answer systems surface for common marketing AI questions and how stable those results remain across repeated runs. ## Questions 1. Which domains receive mentions? 2. Which pages receive clickable citations? 3. Do citations support nearby claims? 4. How much do answers change between fresh runs? 5. Does explicit source request change citation quality? ## Cohort Initial cohort covers question-led prompts about agent architecture, repository workflows, content verification, and AI search measurement. Vendor-ranking prompts remain excluded from first run. ## Protocol - Freeze prompt text before collection - Use fresh conversation for each run - Record product, displayed model, browsing mode, region, language, and timestamp - Repeat each prompt at least three times per system - Store answer text and visible citations - Review whether citation supports associated claim ## Metrics `mention_rate` counts runs naming source or entity. `citation_rate` counts runs with clickable source. `support_rate` counts citations that substantively support nearby answer. `stability` compares results across repetitions. These metrics remain separate. No weighted overall score yet. ## Result status No result dataset published. Current page describes protocol only. Publishing protocol first reduces incentive to change method after seeing favorable results. ## Planned artifacts ```text research/prompts/v1.jsonl research/runs//.jsonl research/scoring/v1.md research/results/v1.csv ``` ## Limitations Interfaces, model routing, retrieval indexes, and answer policies change. Result is dated observation, not durable guarantee of citation or rank. ## Sources for AI Search Visibility Benchmark 1. [Google AI optimization guide](https://developers.google.com/search/docs/fundamentals/ai-optimization-guide) 2. [OpenAI publisher and developer FAQ](https://help.openai.com/en/articles/12627856-publishers-and-developers-faq) --- # Marketing Agents Move from Copy to Operations - Collection: Research - Canonical URL: https://marketingwiki.ai/research/marketing-agents-operations - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: marketing agents, automation, permissions > Research queue tracking whether marketing AI products gain permissioned actions, durable context, tool access, approval gates, and outcome evidence. Research tracks shift from text generation toward systems that observe context, plan work, call tools, change external state, and report outcomes. ## Observation model Product enters dataset when public evidence covers at least one operational property: - Durable task or campaign state - External tool access - Multi-step planning - Permissioned action - Human approval gate - Outcome or audit record Marketing copy using word "agent" without operational evidence remains out of trend count. ## Unit of analysis One record represents product capability at dated version, not company. Capability can move between preview, limited release, general availability, deprecated, and removed. ## Fields ```yaml product: capability: state: preview | limited | general | deprecated action_scope: human_gate: evidence_url: verified_at: observer: ``` ## Questions 1. Which marketing jobs move beyond drafting? 2. Which actions require human approval? 3. Which systems expose audit evidence? 4. Which integrations grant read versus write access? 5. Which capabilities persist after initial launch? ## Current status Evidence collection has started; no trend percentage or ranking published. Initial source set will favor official documentation and dated release notes, then add observed tests. ## Limitations Vendor terminology varies. Preview access may differ by plan and region. Documentation can outlive product behavior. Trend report will preserve uncertainty and release-state changes instead of treating every announcement as shipped capability. ## Sources for Marketing Agents Move from Copy to Operations 1. [MCP server concepts](https://modelcontextprotocol.io/docs/learn/server-concepts) 2. [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) --- # Tool Capability Verification Method - Collection: Research - Canonical URL: https://marketingwiki.ai/research/tool-capability-verification - Published: 2026-08-10 - Updated: 2026-08-10 - Last verified: 2026-08-10 - Author: Marketing Wiki Editors - Reviewer: Marketing Wiki Editors - Topics: tool research, claims, evidence > Claim-level method for separating official documentation, observed behavior, inference, stale evidence, contradiction, and unknowns. Capability claim needs source, source type, verification date, and status. This method avoids treating vendor documentation and independent observation as equivalent. ## Evidence classes | Class | Meaning | Allowed wording | | --- | --- | --- | | Official | Vendor or publisher documents capability | "Documentation says..." | | Observed | Reproducible dated test produced result | "Our test produced..." | | Inferred | Evidence supports conclusion indirectly | "Evidence suggests..." | | Stale | Source or test exceeds refresh window | "Last verified..." | | Contradicted | Sources or tests disagree | Describe conflict | | Unknown | Evidence cannot answer question | State unknown | ## Claim record ```yaml statement: product exports editable email HTML source_url: https://example.com/docs/export source_type: official-documentation verified_at: 2026-08-10 status: vendor-documented reviewer: contributor-id ``` Observed test adds input, account tier, product version, environment, expected result, output, and repetition count. ## Freshness Refresh interval follows volatility. Pricing and model assignment change faster than company founding date. Do not update visible date unless evidence or wording changed. ## Conflicts When official pages disagree, show conflict. Do not silently select more favorable source. When observed test contradicts documentation, preserve both and describe test boundary. ## Affiliations Every profile records submitter and reviewer relationship to subject. Affiliation does not disqualify contribution, but it must remain visible and should not control final comparative conclusion. ## Output Method produces inspectable claim ledger. Readers and agents can filter official, observed, inferred, stale, contradicted, and unknown statements without relying on opaque editorial score. ## Sources for Tool Capability Verification Method 1. [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) 2. [Google people-first content guidance](https://developers.google.com/search/docs/fundamentals/creating-helpful-content)