Can an AI agent run an ad-creative pipeline end to end?

This is work in progress. I'm publishing the reasoning, not the results, because the reasoning is what applies to other teams.

The pitch: an autonomous agent swarm that generates ad creatives, deploys them, measures them, retires the losers, and promotes the winners, so ad spend becomes a self-optimizing loop. Point it at a budget and walk away.

I spent a while working out how much of it is buildable. On some surfaces, nearly all of it. On others, almost none of it, and a better agent wouldn't change that.

That gap between surfaces applies well beyond advertising.

The six stages

A creative flywheel has six stages:

Generate → Store → Deploy → Measure → Decide → Retire/Promote → (repeat)

Each stage is a different kind of problem, and only some of them are hard.

• Generate is solved, or close to it. Image and video generation is good enough to produce creative variants at volume.
• Store is a versioned asset bank. Object storage and a schema. Not hard.
• Deploy is where the whole thing lives or dies. Discussed at length below.
• Measure is where most implementations quietly fail. Discussed below.
• Decide is a rules engine with an LLM layer for the ambiguous cases. It starts with a human approving each call, and is handed off once its decisions match human judgment.
• Retire/Promote is just Deploy again, in reverse.

Three of the six stages are engineering from day one. Decide starts with a human in the loop until the model earns trust. The two that determine whether the system works at all, deploy and measure, depend on external parties, not on your architecture.

"Agent swarm" is an ambition, not an architecture

The original request called for an autonomous agent swarm. Multi-agent designs aren't wrong, but the phrase commits to an architecture before anyone has checked whether the problem needs one.

The real requirement is a self-reinforcing loop: insight → decision → deployed creative → new signal → back to insight. Whether that is one agent, several coordinated agents, or a scheduled pipeline with an LLM decision layer is a separate design choice.

My strong prior, from having built both shapes: for a loop that runs on a daily cadence against a fixed set of platforms, a scheduled pipeline with an LLM decision layer is the right answer, and a multi-agent swarm is a liability.

The reasoning is the same one that shaped the experiment agent: batch problems permit architectures that interactive problems do not. A daily loop does not need agents negotiating with each other. It needs a DAG, a decision step where judgment is required, and a good audit trail. Multi-agent coordination introduces non-determinism into a system that is about to spend real money, in exchange for flexibility the cadence does not require.

Use a swarm when the problem is open-ended and interactive. Deploying ad creatives on a schedule is neither.

Match complexity to the requirement. The most common failure in this category of project is building infrastructure to support an ambition rather than a workload.

The platform asymmetry

The flywheel behaves completely differently depending on which surface it is pointed at, and the difference has nothing to do with how good your agent is. Most plans skip over this.

Off-platform social: mature APIs, real autonomy

The major social ad platforms expose genuine programmatic advertising APIs. Creative upload, ad and ad-set creation, deployment, pausing, retirement, and automated rules are all available and documented.

On these surfaces the full loop is buildable today. This is where the scaling opportunity lives, and it is also the higher-risk surface, because real money moves fast and an automated system with a bug spends it faster than a human can.

A few practical constraints worth researching for your own case rather than assuming: rate limits and asset limits at the volume you actually need, the distinction between natively-uploaded and creator-sourced ad formats (which affects both what you can deploy and what you can measure), and each platform's stated policy position on automated creative generation at scale. That last one isn't technical, but it can change without warning.

On-platform connected TV: partner-gated, largely manual

Connected-TV and device-level ad surfaces are a different world. Depending on the partner, you may find:

• Manual placement processes with multi-day turnarounds and no self-serve API at all
• Faster turnaround but limited data transparency, so your measurement signal is weak even when deployment is possible
• Roadmapped ad platforms where backend improvements land well before any self-serve tooling

For these surfaces, autonomous deployment is not achievable, and no amount of agent sophistication changes that. There is no API to call. The constraint is commercial and organizational, not technical.

On those surfaces the goal changes from autonomy to faster human-in-the-loop: tooling that prepares the assets, drafts the submission, tracks the turnaround, and reports the results, so the human step takes ten minutes instead of two hours.

It's a less exciting deliverable, and often the higher-ROI one.

Why this matters strategically

If your largest channels are the partner-gated ones, the surfaces where you spend the most are the ones you can automate the least, and the surfaces you can automate are where you have the least volume.

That turns a technical project into a budget question. The flywheel becomes an argument for shifting spend toward surfaces where automation is possible, which means different people need to approve it.

Measurement gates everything

The flywheel's decision quality is bounded entirely by the quality of the performance signal feeding it. An autonomous system making creative decisions on biased data compounds its mistakes, because every cycle reinforces whatever the bias favored.

Three specific traps:

Survivorship bias in the measurement set. If you can only measure the creatives that already succeeded (say, because measurement only works for some ad formats), your system learns only from winners. It will have no model whatsoever of why things fail. It will confidently generate variants of past successes and have no ability to recognize a novel failure.

This is the most dangerous input problem because it is invisible from inside the system. Every metric looks fine.

Attribution that doesn't match the decision. If you are moving to a source-level attribution model, and your measurement vendor does not support that model natively, then the numbers driving your automated decisions come from a custom modeling layer you built. That layer needs the same scrutiny as the statistics in an experimentation system, and it usually gets far less because it's treated as plumbing.

Correlation standing in for incrementality. Before trusting a system to substantially increase spend, you need incrementality measurement: geo tests, holdouts, auction experiments. A creative that correlates with conversions is not the same as a creative that causes them, and a loop optimizing on last-click will happily spend more and more money buying users who were going to convert anyway.

The sequencing implication: measurement has to be fixed before the flywheel is built. Building the loop first and fixing the signal later means running an automated optimizer on a biased objective function, at increasing spend, for however long the fix takes.

The trust model

Assuming the signal is sound, the question becomes how much autonomy to grant and when.

Autonomy should be earned one action type at a time. A single global "autonomous mode" toggle is the wrong shape.

1. 01Recommend. The system produces recommendations and a human executes them. Every recommendation is logged with its reasoning and its inputs. The metric you are watching is not accuracy in the abstract; it is human override rate, broken out by action type.
2. 02Act with confirmation. The system prepares the action fully (creative uploaded, ad built, everything staged) and a human approves with one click. This removes the effort of execution while retaining the judgment.
3. 03Act autonomously within bounds, by action class. Widen per action type, in the order of how reversible the action is.

The step from 1 to 2 is bigger than it looks. Most of the human cost is in doing the thing, not in deciding it. Stage 2 captures most of the value at a fraction of the risk.

• Pausing an underperformer is cheap to get wrong and easy to undo. Automate first.
• Promoting a winner, which increases spend, is expensive to get wrong. Automate later, under a budget cap.
• Generating and deploying novel creative carries brand risk that is not reversible by pausing. Automate last, if at all.

Reversibility is the ordering principle, not confidence. A confidence threshold ("act automatically above 70%") is a reasonable secondary gate, but it should never be the primary one, because it treats an easily-undone pause and an irreversible brand-safety incident as the same class of decision.

Non-negotiables at every stage: a complete audit trail of what acted, on what input, with what reasoning; a kill switch that a non-engineer can hit; and hard spend caps enforced outside the agent's control, so a malfunctioning loop cannot raise its own ceiling.

The budget limit must not be a parameter the system can modify. Put it somewhere the agent cannot reach.

How I wrote the brief

The deliverable I produced was not the plan. It was a brief that instructed another agent to produce the plan: a specification detailed enough that a capable model could research the platform landscape, reason about the architecture, and write the document, with the honesty constraints and structural requirements pinned down in advance.

That is a different skill from writing the plan yourself or prompting casually. Four things mattered:

Separate what is known from what must be researched. The brief explicitly marked company context as given ("use it, don't re-derive it") and platform capabilities as requiring verification. Without that split, a model will confidently restate your own context back to you as though it were a finding.

Specify the honesty requirement structurally, not tonally. Asking for a "balanced" or "realistic" assessment produces hedging. Requiring every capability claim to be sorted into possible now / not possible now / open question, with the third as a required section, produces something you can act on. Give the model a place to put uncertainty and it will use it; give it none and it will resolve uncertainty into false confidence.

Name the anti-goals. "Treat 'agent swarm' as a description of the ambition, not a required architecture" prevented an entire category of over-engineered output. Constraints on what not to assume are more valuable than constraints on what to produce.

Demand the least-bad alternative wherever the answer is no. A plan that says "this isn't possible" is half-finished. A plan that says "this isn't possible, and here is the workflow tooling that captures most of the value" is usable.

Writing specifications like this is becoming a core skill, and it gets less attention than prompt-writing. A prompt gets you an output. A specification gets you an output you can evaluate, because the criteria were set before you saw it.

The open questions

Some of the most useful output was a list of specific questions for partners, vendors, and internal teams. Writing them as answerable questions rather than general risks makes them actionable:

• What does each ad platform's policy actually say about automated creative generation and deployment at our volume, and who at the platform can confirm that in writing?
• When do partner-gated CTV surfaces expose any creative-management API, and what is the realistic timeline versus the roadmap timeline?
• Does our measurement contract permit the raw-export volume a custom attribution model requires?
• What is the smallest incrementality test that would give us enough confidence to raise spend, and how long does it take?
• What is our actual rollback procedure if an automated creative causes a brand-safety incident, and has anyone rehearsed it?

A plan whose open-questions section is specific and answerable is worth more than one that appears complete. Apparent completeness is usually false. The questions are what move the project forward.

What generalizes

The bottleneck in autonomous systems migrates. It starts as model capability, then becomes verification, then becomes permission. Most teams are still solving for the first while blocked on the third.

Automation potential is a property of your integrations, not your architecture. Audit what you are actually allowed to do programmatically before designing anything.

Order autonomy by reversibility, not by confidence.

An automated optimizer amplifies whatever bias is in its objective. Fix measurement first or you are scaling an error.

Saying "this surface can't be automated" is the most valuable sentence in the plan. It redirects effort to where the effort pays.