Marketing Automation QA: Check Journeys Before Launch With an AI Agent on Rails

Who this is for: marketing-operations specialists and leads. Copy the checklist, split it into rule and judgement checks, then test your current QA with seeded defects. The method is part of AI agent rails: one job, one data scope, one approver, one audit trail.

Before: the manual workflow

Manual journey QA usually means one person reading the canvas the evening before launch. Time pressure turns the review into a skim. Builders often check their own work and see what they meant to build. Knowledge of past mistakes sits with one specialist. Nothing records what was checked, so after an incident nobody can say whether a step was missed or never in the routine.

The marketing automation QA checklist

The marketing automation QA checklist below has 27 items in ten groups, and you can copy it as it stands. Each item is tagged rule when a deterministic check can answer it, or judgement when someone must compare it with the intent. It also works as a campaign QA checklist for one-off sends and as a pre-launch checklist for email workflow testing. It draws on the site's consent guidance and on published checklists from Iterable and Scalero 57.

Audience

• ☐ The audience definition matches the written request, and its version is recorded. (judgement)
• ☐ The audience count sits inside the expected range for this journey. (rule)
• ☐ Standard exclusions are attached: test accounts, staff and open complaints. (rule)
• ☐ No special-category data or close proxy drives inclusion or priority. (rule, then judgement)

Trigger and entry

• ☐ The trigger was fired once in a test and started the right path. (rule)
• ☐ Maximum entries and re-entry settings match the intent. (judgement)
• ☐ An end date exists, or "runs indefinitely" is a stated choice. (rule)

Branching

• ☐ Every step connects onward or exits, with no dead ends. (rule)
• ☐ Branch conditions, including the default path, match the written intent. (judgement)
• ☐ Exit rules remove people who have already done what the journey asks. (judgement)

Timing and wait steps

• ☐ Time zone, send window and quiet hours are set for each market. (rule)
• ☐ Wait steps make sense here and avoid public holidays and blackout dates. (judgement)
• ☐ A frequency cap is present, and overlap with similar live journeys is known. (rule, then judgement)

Content and fallback values

• ☐ Every merge field has a fallback value and renders on test profiles. (rule)
• ☐ Copy fits this audience and matches the offer, price and dates on file. (judgement)
• ☐ Regulated claims and required disclosures have a recorded sign-off. (rule)

Links and tracking

• ☐ Every link resolves over HTTPS to the intended page. (rule)
• ☐ Tracking parameters are present and follow your naming convention. (rule)
• ☐ A conversion event is attached, so the result can be measured. (rule)

Consent and suppression

• ☐ Consent purpose and channel match this message. (rule)
• ☐ Suppression lists are attached, and the send step re-checks them at dispatch. (rule)
• ☐ The template is tagged as marketing, service or legal notice. (rule)

Deliverability

• ☐ Sending domain, authentication and one-click unsubscribe are in place for this stream. (rule)
• ☐ Volume fits the warm-up plan and rate limits for this domain. (rule)

Destinations and sync rules

• ☐ Every destination is allow-listed, and sync-time filters were checked separately. (rule)

Rollback plan

• ☐ A named owner can stop the journey, and the stop steps are written down. (rule)
• ☐ A review is booked soon after the first people enter. (rule)

Consent mechanics behind the suppression items are in the suppression architecture article, and the glossary entry on journey orchestration defines the terms.

What rules do and what the model does

Rules answer questions that have one right answer, and the model answers questions about intent. A rule can confirm that a suppression list is attached. It cannot notice that a branch contradicts what the marketer asked for. The split follows the boundary article, which treats deterministic rule checks as ground truth.

The table assigns each common check to its owner and shows what a failure does.

A model's "pass" never overrides a failed rule, and a model's silence does not mean correct. So the report says "no findings in these checks" and lists them. It never says "passed".

After: the job on rails, step by step

The job on rails runs rule checks first, then the agent, then a person, and the launch approval stays last.

1. A marketer submits one journey version for launch, and the platform hashes it.
2. The Orchestrator routes the submission to this rail. It reads metadata only.
3. Rule checks run in the rule layer. A failed rule blocks launch, whatever happens next.
4. The Journey QA Reviewer reads the configuration, content, audience counts, rule results and the live journey list.
5. Findings arrive with severity, location, evidence and a suggested fix, plus the list of checks actually run.
6. A person resolves each finding by fixing it or accepting it with a note. Unresolved high-severity findings stay blocked by the rule layer. A fix creates a new version, so steps 3 to 5 run again.
7. The normal launch approval follows. A named approver, who is not the requester, signs the version hash. Any later change voids that approval, and a timeout expires it.

The agent has no write tools at any step. The tool allow-list enforces that, so no prompt can add one. A ledger writer outside the agent records each step.

The rail card

The rail card fixes what the Journey QA Reviewer may do, and each limit sits in a system rather than a prompt. Budget values are yours to set. See the rail card guide for how the fields work.

The session holds two of the three Rule of Two properties 1. It reads untrusted text, because agency copy, feeds and merge fields can carry instructions. It also reads confidential configuration. So it must not gain the third property, changing state. That is why the rail level stays at L2 and does not move up.

What the ledger shows for one run

One run leaves one record, written by the ledger writer and not by the agent. The example below is illustrative, with example value values, in the style of the segmentation walkthrough.

{
  "record_id": "aud_000877",
  "event": "journey.qa.reviewed",
  "rail": "journey-qa-reviewer@v3",
  "submitted_by": "marketer_12",
  "journey": {"ref": "jrn_311@v4", "sha256": "4be1..."},
  "rule_checks": {"run": 14, "failed": ["suppression_attached"]},
  "agent": {"version": "2.1.0", "model": "model-id@version"},
  "checks_run": ["branch_intent", "wait_steps", "copy_fit", "overlap"],
  "findings": [
    {"id": "f1", "severity": "high", "location": "branch_2.exit",
     "resolved_by": "marketing_ops_04", "resolution": "fixed in v5"},
    {"id": "f2", "severity": "medium", "location": "wait_3",
     "resolved_by": "marketing_ops_04", "resolution": "accepted, note n_88"}
  ],
  "ledger": {"prev_hash": "ab41...", "hash": "c7d0..."}
}

Three ways it fails, and the control for each

Journey QA with an agent fails in predictable ways, and each control below lives outside the model.

One more failure is human: under deadline, people skip QA. Make the review a launch prerequisite in the workflow, so the launch button stays locked until a run exists for that version hash.

Metrics that are honest

Honest QA metrics count what got through as well as what got caught. Use the definitions in the AI marketing operations roadmap and baseline them before you add the agent.

• QA catch rate on seeded defects, split by defect type.
• Escaped error rate: errors found after launch per 100 campaigns.
• False-finding rate: findings rejected as wrong, not findings accepted and left alone.
• Submission-to-launch-ready time, measured by your team.
• Override rate. Near zero may mean rubber-stamping, so sample decisions.

Report these by rail and role, not by named reviewer. Annex III point 4(b) of the EU AI Act lists monitoring workers' performance as a high-risk use 2, so take advice before using this data to assess a person.

Run a seeded-defect test on your current QA, with or without an agent:

1. Copy a few recent journeys into a test workspace.
2. Insert known defects: audience, trigger, branch, link, consent and timing.
3. Run your normal QA without telling the reviewers which journeys are seeded.
4. Count catches by defect type, and write down what was missed.
5. Repeat before any change to the model, the prompt or the tools.

How vendor tools compare

Simulators test mechanics and an agent checks intent, so most teams need both. The table reflects vendor pages we opened on 1 November 2026, and features may exist that these pages do not describe.

A script, or nothing, is sometimes the better answer. If you launch few journeys, a shared checklist and a second reader will do. Build the rule checks before any agent, because they catch the costly errors. If all journeys live in one vendor and the content is not regulated, a vendor assistant may be enough: Braze Operator reviews message content and Canvas configuration, and it cannot launch anything that affects users 10. PrivyCDP's product page describes AI-assisted review of workflows, with limits on data access and review of results.

To see how this job fits the wider function, read AI agents for marketing operations, or return to the AI agent rails hub. To write this rail for your own team, download the rail card template.