AI Campaign QA Needs a Release Process, Not Just a Green Tick

A campaign can pass its checks and still be the wrong version to send. An AI agent fixes a disclaimer, a colleague changes the offer, and someone adjusts the audience. If the approval belongs to the campaign name rather than the campaign revision, the reassuring green tick may describe something that no longer exists.

That is the question I would put to marketing teams considering automated quality assurance: not just whether AI can find mistakes, but whether the checked work is the work that actually reaches customers.

Campaign checking is becoming a product feature

On 29 September 2026, Braze announced Agentic Standards as part of its expanded AI portfolio. The release describes campaign quality assurance against marketer-defined rules. It says the capabilities are in beta, with general availability for Agentic Standards expected in October. As of 6 October, the implementation documentation still labels it beta; an expected release month is not confirmation of access for every customer.

The documentation describes standards for campaigns and multi-step journeys, covering areas such as audience selection, copy, links and personalisation. Findings can be passed, failed, warned about or ignored. It also explicitly instructs users to rerun an evaluation after changing a campaign or journey.

Those details matter more to me than a claim that campaign review is now automated. A check, a correction and permission to launch are separate decisions. My recommendation is to treat them that way, even when they happen inside one interface.

Approve the release, not the label

Consider a hypothetical retailer preparing an email promotion with an SMS reminder. The agent assembles the messages, a reviewer accepts the offer, and the audience excludes customers who have already purchased. Before launch, a last-minute edit extends the promotion to a different product range.

I would not let the earlier approval quietly carry forward. The revised offer needs checking against the message, landing page and intended recipients. Even if the subject line has not changed, the decision being approved has.

A useful release record would identify the message content, creative, destination, audience definition, exclusions, schedule and version of the review rules. It should also retain the evaluation results and any accepted exceptions. This is a proposed operating model, not a claim that every marketing platform already stores that complete record.

The release owner should be able to answer a plain question: what changed after we last reviewed this? If the answer requires reconstructing a chat conversation, the approval process is too loose for an agent that can make several changes in one run.

Test the checker before trusting the result

Braze's guidance recommends testing standards against known passing and failing examples. I would make that a requirement for the team's own release process, rather than an optional exercise during setup.

Build a small rehearsal set with synthetic recipients and no live sending. Include an acceptable campaign, a message with the wrong destination, a missing personalisation fallback and an audience definition that includes a deliberately excluded test contact. Write the expected outcome before running the checker.

Where a requirement can be checked exactly, I would prefer an exact check: does this link resolve to the intended page, and is the required tracking value present? For questions of tone or ambiguous meaning, an AI assessment can help a reviewer. I would not ask one broad instruction to 'check everything' to stand in for both kinds of work.

Keep the failed examples when the system improves. They form a regression set for the next change to a prompt, template or campaign rule. The point is not to prove the agent can never fail. It is to discover when a change makes a previously caught error invisible.

An ignored issue needs an owner

The documented workflow allows an issue to be ignored for the current evaluation. That is a useful distinction: an intentional exception should not need a fictional explanation that the campaign passed every rule.

My preferred policy would record who accepted the exception, why it is appropriate and which release it applies to. A reviewer might legitimately waive a naming convention for a one-off campaign. That should not silently waive an audience exclusion or turn into a permanent relaxation for every future send.

I would also keep the rule owner separate from the agent that proposes a fix. If an agent can rewrite the standard whenever its campaign fails, the team has not improved quality; it has made the marking scheme negotiable.

Borrow release discipline without importing bureaucracy

Marketing does not need a software engineering department's entire deployment ceremony. It does need a repeatable handoff between building, checking and releasing. For a small team, that could be one versioned review record and one named person authorised to release it.

Before launch, freeze the reviewed revision and resolve or explicitly accept its exceptions. After launch, check the real destination and actual message with an authorised test recipient. Have a named operator who can pause the remaining journey if that readback does not match the approved work. Pausing later sends is a recovery action, not a promise that a delivered email or SMS can be recalled.

In its 2 October coverage of the Braze announcements, CMSWire highlights the responsibility marketers retain for keeping their rules current. I would extend that responsibility to the release record: current rules are only useful if they were applied to the current campaign.

The measure I would watch is not simply how many checks the agent completes. It is whether the team can show that each released revision was checked, its exceptions were understood and an accountable person authorised that exact work. AI can shorten the path to a finished campaign. It should not shorten the evidence needed to send it.