AI campaign builder for ads: drafts you can trust

Search for an AI campaign builder today and you will land in the world of email. ActiveCampaign will draft your welcome sequence, Klaviyo will generate subject lines and flows between list segments, and a dozen CRM platforms will assemble a nurture journey from a prompt. All genuinely useful, and none of it any help if your job is paid advertising: video ads across markets, languages and placements, built from real templates and real footage, delivered to Meta and Google.

This piece defines the term for that second world. An AI campaign builder for ads is a system that turns a brief into a campaign you can actually run: the campaign record, the production plan behind it, and the full creative matrix that plan produces. And it argues for the one property that separates a working builder from a demo: validation. Any model can generate something campaign-shaped. The question that matters is whether the thing you are shown will build.

What an AI campaign builder is when you mean ads#

Strip the email meaning away and define the ads meaning properly. Whether you call it an AI campaign builder or an AI campaign generator, for paid creative it needs to produce three connected things:

1. A campaign: the organising record. Objective, markets, languages, platforms, timing. The thing your team rallies around.
2. A production plan: how creatives actually get made. Which template, which assets, which copy on which route, which output formats for which placements.
3. The creative matrix: the full set of finished ads the plan implies. Three markets, four placements and three product lines is not one deliverable, it is thirty six.

Email campaign generators work almost entirely in copy: a subject line and a body are the deliverable, and the cost of a weak draft is an edit. Ad campaign building is structured production. A video template has named composition fields with types, footage slots with format expectations, and outputs that must satisfy each placement's hard rules. A wrong draft here is not a weak sentence, it is a build that fails or, worse, a build that succeeds and ships the wrong claim into the German market.

In Nubu, the production plan is a flow: a node graph where data, assets and copy pipe into a template and out to placement-specific outputs. If node graphs are new to you, the flows overview and the node catalogue cover the model, and there is a longer piece on why a node editor beats a form for campaign production. Here is the shape of the pipeline the assistant drafts, live:

The builder itself is a docked chat panel available on every product surface in Nubu, with one deliberate exception: Settings, because members, billing and API keys are outside what an assistant should touch. The panel, the conversation and any in-flight work survive navigation. Turns run in the background on Nubu's side, not in your browser, which changes how you use it: send a brief, close the tab, come back to finished work. There is a Stop button when you want to cut a turn short. Model choice is Auto by default, or you pick the provider and model per chat, with a per-chat thinking level, running on your organisation's own OpenAI, Anthropic or Gemini keys.

That is the surface. The substance is what happens between your brief and the card you approve.

Plausible is easy. Correct is the product.#

Large language models are exceptional at plausible. Ask a generic chat tool to plan a campaign and it will produce confident specifics: a media plan with clean headings, template names it has never seen, aspect ratios your template does not export, a discount claim your legal team retired last quarter. The output is campaign-shaped. It is not a campaign. It is homework for whoever has to check it, and checking a confident draft line by line is often slower than writing the plan yourself.

The fix is not a better prompt. It is architecture: a validation pipeline that stands between what the model drafts and what you are ever shown. In Nubu, campaign work arrives in three shapes, and all three are offered cards rather than records. The assistant drafts the campaign itself: name, description, tags, and a structured brief with objective, markets, languages, platforms and timing. It drafts entire flow graphs. And it drafts changes against a flow's current graph. Nothing is created until a human approves, and approval applies the change exactly as if you had clicked through the interface yourself: same permissions, same validation, same audit trail.

Before any flow card reaches you, the draft runs this gauntlet:

1. A valid flow. The draft must hold together as a flow the editor itself would accept. Anything malformed dies here.
2. A rehearsal. The draft is rehearsed in full against your workspace as it stands, whether it edits an existing flow or starts a new one. Your real flow is never touched.
3. The editor's own diagnostics. The rehearsed flow faces the same live checks that light up as red and amber states on the editor canvas. Not a summary, not a second opinion: exactly what you would see on screen if you opened the flow yourself.
4. Offer-time checks the canvas cannot do. Every template and asset the draft references is re-verified against your organisation at that moment, so a template deleted an hour ago cannot ride into a proposal on stale memory. Delivery destination picks are re-verified live against the platform: if the chosen Google ad group no longer exists, the offer is refused with instructions to pick again.
5. A test build. The flow is test-built, end to end, by the same build engine that powers the real Build button. This is the detail worth dwelling on: the number on the card comes from the engine that runs your actual builds, so the estimate can never disagree with production. There is no assistant-flavoured approximation that could drift out of step with the real thing. If the test build refuses, the offer is blocked and the assistant has to fix the flow and try again in the same turn.

Errors block unconditionally. Warnings block too, unless you explicitly say to keep them; the assistant cannot quietly wave its own warnings through. All of which compresses into one line you can hold the product to: a flow you are offered is a flow that builds.

The card you approve carries evidence, not vibes. Three pieces:

• The expected creative total, exact. It comes out of the test build, not out of the model's arithmetic. If the card says 36, the build makes 36.
• A matrix of rows showing the real resolved copy per route: the German headline on the German route, the actual product name substituted in, per output. The sample is capped at 200 rows so cards stay light, and the card says so when a giant flow exceeds it, but the total is always exact.
• On edits, a combination diff: exactly which market, language and version combinations the change adds and which it removes. A count alone can hide a swap. A flow that loses two combinations and gains two different ones reads as no change by count; the diff makes it impossible to miss.

A walk-through: brief in, campaign out#

Here is what this looks like in practice. You run performance marketing for an outdoor gear brand. Autumn sale coming. You open the panel on the Campaigns page and type:

Autumn sale campaign for the waterproof shell range. UK, Germany and France, each in its own language. Meta and Google. Use the template we used for the summer launch. Live from 20 September.

It reads before it asks. The assistant searches your templates for the summer launch template and opens its structure: compositions, typed fields, footage slots, which placements each output fits. It searches your assets for shell-range footage. It reads the German glossary and its claims, because Germany is in the brief and your glossary carries market rules. Then it asks only what the workspace cannot answer: which products headline the sale, and whether France takes the same discount as the UK.

You answer, and then you can leave. The turn keeps running in the background on Nubu's side, not in your browser tab, so closing the laptop does not kill the work; the conversation catches up when you come back.

The campaign card arrives first. Name, description, tags, and the structured brief: objective, markets, languages, platforms, timing. It is an offer, not a record; nothing exists in your workspace yet. You approve it, and the campaign is created exactly as it would be if a colleague had filled in the New Campaign dialog by hand.

Then the continuation. Approve a card and one follow-up run starts automatically, picking up the record you just created. This is a small mechanism with a large consequence: when the assistant says "once the campaign exists I will propose the flows", that is not chat optimism, it is scheduled behaviour. You approve a campaign and the flow proposal begins drafting without another prompt from you.

The flow card is the main event. The whole graph in one card: asset nodes carrying your verified footage, the template node, market and language routing, outputs mapped to placements. Before you saw it, it survived the full gauntlet above, from validity checks through live re-verification to the test build. The card reads: expected total, 36 creatives; the matrix, with the French route showing actual French copy; and one warning, say a placement note you might legitimately accept, which blocks the offer until you explicitly keep it.

Approve, and go look. The flow now exists and opens in the editor as a first-class graph, identical to what the card described and editable like anything built by hand. Drop onto the Preview node and render a single creative ahead of any build; it runs through the same build engine, which by now should not surprise you. When you are ready, you press Build. The assistant does not press Build, ever. The building a creative guide covers what happens from there.

Changes stay honest. Three weeks later you ask for a Black Friday version for Germany only:

Add a Black Friday version to this flow for Germany only. Keep every existing route exactly as it is.

The edit is drafted against the flow's current graph, not a remembered copy, and its card carries the combination diff: German Black Friday combinations added, nothing removed. You approve exactly that.

If you would rather run this on your own work than read about it, a workspace takes a couple of minutes: create one free and paste a real brief.

What grounds the drafts: the read surface#

Validation catches bad structure. Grounding prevents most of it from being drafted in the first place. The assistant plans against what your workspace actually contains, through a deliberately wide read surface:

• Templates. Search and full inspection: compositions, typed fields, footage slots, and a placement-fit verdict per output, so it knows before drafting that your template has no 9:16 composition rather than discovering it at build time.

• Assets. Search and filter across the library, plus visual inspection: it can actually look at an image, or a video's poster frame, before recommending it for a slot. There is a whole piece on finding ad assets with AI search.
• Glossaries and claims. Market rule sets, the claims scoped to them, and an advisory copy check it can run over drafted lines.
• Delivery outcomes. Whether each creative built, rendered and reached its destination, with the reason attached when one did not.
• Workspace reports. Renders completed and failed over a period, creatives by status, templates ranked by output, storage.
• The web, when the workspace cannot answer, via search running on your organisation's own provider key.

One reading rule does disproportionate work: search results arrive in pages, and the assistant must keep paging to the end before claiming something does not exist. "You have no vertical template" is only permitted as the conclusion of a complete read, never a first-page guess. Caps are disclosed wherever they bite, so a capped result is never presented as a complete one.

The same read surface answers the small questions that fill a planning day. Ask:

Which of our templates could actually run a vertical Demand Gen video?

and the verdict comes from template inspection, each output comp judged against the placement's real rules, with the failing ones explained. Or ask for the state of the quarter:

How many creatives did we build this month compared with last, and which templates produced most of them?

and the numbers come out of the workspace report, exact counts over the period, not the model's recollection of them. Both are reads, so neither needs a card.

On the write side, the assistant's direct writes are additive only: tagging assets and templates, and creating folders. Everything that matters goes through a card. It can also generate media on your keys, as proper organisation assets: up to four images per run, up to two videos per run (video takes minutes), and it asks before the first generation in a conversation rather than spending unannounced.

A note on languages, because every team asks: markets and languages in Nubu are values you type, not options you pick from a fixed menu. The honest range is any language your connected model can write. How that plays out across a real multi-market flow is its own story: translating video ads at scale. Flows can also carry AI nodes for on-brand copywork inside the graph itself; see using AI nodes.

What it will not do#

The short version, because it deserves its own article and has one. The assistant has no render tool, no publish tool, no spend tool and no delete tool. Not disabled, not permission-gated: structurally absent, because the assistant's toolset simply does not contain them, so there is no prompt injection or model mood that can reach them. Platform uploads are proposals, and everything Nubu creates on Meta or Google lands paused, every time, so nothing goes live without a human act on the platform. And approval cards are frozen at offer time: approving a card can only ever touch the records you were shown, never a re-run filter that sweeps in records you were not; anything deleted or busy in between is skipped and reported, not forced. The full design, including why refusal-by-architecture beats refusal-by-instruction, is in AI proposes, humans approve.

The economics, briefly#

Nubu does not resell model tokens. You connect your organisation's own OpenAI, Anthropic or Gemini keys; the provider bills you directly at their rates, with no credits to buy and no margin added on usage. You choose the model per chat, including the thinking level, so a quick tagging question does not have to cost what a deep planning session costs. Organisations set a weekly assistant budget, and media generation asks before the first spend in a conversation. The full cost logic, including why bring-your-own keys keeps incentives clean, is in bring your own AI keys; platform pricing itself is per seat, on the pricing page.

How to evaluate any AI campaign builder#

Whether or not you evaluate Nubu, these are the questions that expose architecture. Demos will not; each of these will.

1. What does it draft against? A blank page, or your actual inventory? Ask the vendor to show the assistant citing a specific template's field structure, or declining an asset because it inspected it and it did not fit. If drafts are not grounded in your workspace, you are buying a writing tool with a campaign vocabulary.

2. Is validation the build engine itself, or a second opinion? The strongest possible answer is that the check gating a draft is the same engine that runs real builds. A separate "reviewer model" pass inherits the failure mode it is meant to catch: it, too, can be confidently wrong. Ask: is the validator the same engine that builds?

3. What evidence ships with a draft? Exact counts computed by the system, resolved content per route, and diffs on every change. If the card says "this will create your campaign assets" without a number the system stands behind, you will be doing the counting after approval, which is the wrong side.

4. What exactly does approval apply? The records you saw, frozen at offer time, or a query re-run at apply time? The second can legitimately drift between offer and click, and drift plus automation is how bulk mistakes happen.

5. What is structurally impossible, rather than instructed? "The model is told never to publish" is a policy. "No publish tool exists" is an architecture. Only one of them survives a hostile prompt, a confused context, or a bad day.

6. Who bills for the model, and at what margin? Bundled credits mean the vendor picks the model economics and profits when you use more. Your own keys at provider rates mean the builder succeeds only when the work it drafts is worth approving.

Score any tool, including this one, against those six. The pattern behind them is a single idea: generation is cheap, and everything valuable lives in the gap between generated and correct.

Start with one brief#

The fastest evaluation is a real one. Create a workspace, upload or pick a template, and paste the brief for the campaign you are actually running next quarter. Watch what the assistant reads before it asks, what its first card contains, and what evidence arrives with the flow proposal. Then approve it and open the graph it built. The rest of the platform, from the node editor to delivery, is on the features page, and the sister pieces in this series go deep on approval safety, translation at scale, asset finding and key economics.

A plausible draft is a starting point. A validated one is a head start. The difference is the product.