Automated QA Before a Paid Placement Goes Live

The last step before a paid placement goes live is watching the finished file all the way through, and it's the step that gets skipped more than any other, because by the time an asset is done it's already been looked at a dozen times during production. Everyone involved is confident it's right. Confidence isn't the same thing as a fresh look, and a fresh look is exactly what catches the misspelled overlay, the caption clipped by the platform's safe area, or the line in the voiceover that technically claims something the brief never asked for.

The pass most teams skip, and why it keeps getting skipped

It's not laziness. It's that a genuinely fresh review — someone who hasn't seen the last six cuts of this asset, watching it start to finish with no context — is expensive to arrange for every single piece of creative a team ships, and most of what ships doesn't need it. The failure mode isn't "nobody ever reviews anything." It's that review happens unevenly: the hero asset for a big launch gets three people's eyes on it, and the fourteenth variant in a testing batch gets uploaded straight from the render queue, because nobody has the bandwidth to give it the same scrutiny and it doesn't obviously seem to need it — right up until it's the one with the typo, spending budget against a mistake nobody caught.

Two tools, two different jobs

There are two separate machine passes worth knowing apart, because they check different things and cost different amounts to run.

analyze_video is the broad read. It extracts sample frames as reusable image references, describes the overall style and format, breaks the video into per-timestamp beats, reads whatever text appears on screen, and — when asked — pulls a full transcript of the spoken audio. It's a general-purpose "watch this back and tell me what's actually in it" pass, useful whether or not the video was AI-generated in the first place.

review_generation is narrower and stricter. It self-QCs a generated image or video specifically against the original prompt, via vision, and returns a structured verdict: whether it matches the prompt, a list of specific issues, a severity rating of ok, minor, or broken, and a suggested fix. It's not asking "is this good" in general — it's asking "does this actually match what was requested," which is a sharper, more checkable question than a general quality opinion.

Why this is explicitly not meant to run on everything

The detail that matters most for how to actually use review_generation is built into its own guidance: offer it after a long job or a workflow run, or when the output seems off — and never auto-run it on every single generation, because it costs credits and adds latency on top of the generation it's checking. That's not a limitation to work around. It's the correct way to think about automated QA in general: a machine review pass is a real cost, applied to catch a real but occasional failure, and running it unconditionally on everything is the same mistake as sending every piece of creative to human review regardless of what it's for — expensive, and dulling to whoever has to act on the results, because most passes will come back clean.

Where the machine pass earns its cost

The judgment call is which assets actually warrant the extra pass, and "is this about to spend money" is a cleaner filter than "does this feel important." A few situations where the pass reliably pays for itself:

• Anything about to carry paid distribution. A creative that's about to have real budget put behind it is exactly the case where a caught typo or a missed brand-safety issue is worth far more than the cost of one review call.
• The output of a long or multi-step job. A full workflow run or a multi-scene movie has more places for something to have drifted than a single-shot generation, and a fresh pass at the end catches drift that accumulated silently across steps nobody re-checked individually.
• Anything where the output already seemed a little off. If a generation looked slightly wrong on a glance, that instinct is worth confirming with a structured check rather than either shipping it anyway or manually re-scrubbing it frame by frame.
• A batch about to go out as a set. Checking every fifth variant in a large batch by hand is a bad sampling strategy — running the automated pass across the whole batch and triaging by severity is both cheaper and more thorough.

Where it doesn't earn its cost: early drafts still being iterated on, low-stakes organic variants nobody's spending against, and anything already getting a full human review pass regardless — the machine check adds latency there without adding much a person wasn't already going to catch.

Reading a severity rating instead of a pass/fail

The three-tier severity output — ok, minor, broken — is what makes the pass usable at batch scale instead of just single-asset scale. A binary pass/fail forces a human to open every failure to find out how bad it actually is. A severity rating lets you triage without opening anything: broken results go straight back for a regenerate, minor issues get a quick human glance to decide if they're worth fixing or shippable as-is, and ok results move forward without anyone's time spent on them at all. That's the actual leverage of automated QA — not replacing a human review, but sorting a whole batch so a human's limited attention lands on the handful of items that actually need it.

Versely walkthrough: the pre-publish pass on a paid asset

A concrete sequence for a video about to carry ad spend:

1. Once the asset is finished, ask the agent to watch it back before publishing: "Watch this finished ad back before I publish it — check the on-screen text, the pacing, and whether it matches the brief."
2. That triggers analyze_video for the full read — a beat-by-beat breakdown of the video, including every on-screen caption and, with a transcript requested, the exact wording of the voiceover, which is the fastest way to catch a claim that legal or compliance would flag.
3. For the sharper prompt-match question — did the generation actually deliver what was asked for — follow up by asking the agent to check the generation against its original prompt: "Does this match what I actually asked for?" review_generation returns the match verdict, the issue list, and a severity so you know immediately whether this needs a regenerate or just a quick look.
4. Route by severity: broken goes back to generation, minor gets a human glance, ok ships. Reserve this whole sequence for assets about to carry spend or ship as a finished batch — not for every draft along the way.

Takeaway

Automated QA works because it's selective, not because it's exhaustive. review_generation is built explicitly to be offered rather than auto-triggered, and that restraint is the feature, not a gap — a machine pass costs credits and latency on every run, and the return on that cost is highest exactly at the moment before spend, not on every intermediate draft. Save the pass for what's about to go live, read the severity instead of re-watching everything yourself, and the last step before a paid placement stops being the one that gets skipped.