Search "how to build an AI agent for Facebook ads" and read what comes back. Meta's documentation tells you which API endpoints an agent is allowed to call. Three vendors promise a complete guide and deliver a signup form. One video explains how to start an agency selling agents to other people. And two results down the page, a media buyer on r/FacebookAds is asking the same question you are, in a thread with five comments and no answer.
The category is loud and the build is undocumented. Everyone is selling the outcome. Nobody opens the hood.
So here's the hood. I've been building an autonomous Meta ads agent, and it ran a creative sprint last week: ten ad concepts, generated, screened, and pushed to Meta. This post is the architecture underneath that run. The ten skills, the files they hand each other, and the places where the machine stops and asks permission. I'll also tell you which creative it refused to publish and why, because a guardrail you've never watched stop something is just a claim.
Fair warning up front: the agent has never spent a dollar. That's deliberate, and I'll explain the order of operations later. But if you came for live ROAS numbers, they don't exist yet, and anyone showing you theirs this early is showing you a screenshot.
The short version
- The agent is ten narrow skills, each producing one file the next skill reads. The folder structure is the architecture.
- State lives on disk, not in a chat window. That's what makes a run auditable by someone who wasn't watching, and resumable after it stops.
- A human approves every stage transition. The compliance screener can block a creative outright, and there's no override.
- Last sprint: 10 creatives generated, 9 cleared compliance, 1 blocked for inventing metrics it had no data to support.
- One file makes the loop recursive: last week's winners get written back as patterns, and next week's copy is briefed by them. The learning is a text file you can read, edit, and roll back, not a model you retrain.
Page 1 has no answer
I went looking for prior art before I started building, the way you'd check whether someone had already solved your problem. The search results were a map of the gap.
Meta ships Ads AI connectors, and the documentation is useful for what it is: an agent can create campaigns, edit ad sets, and move budgets through a sanctioned interface. What the docs don't tell you is how to design the thing doing the calling. It's a manual for the wall socket. It says nothing about the appliance.
Below that sits a Meta Blueprint course for building a Business Agent on Messenger, which is a customer-service chatbot and a different product entirely. It ranks because the words collide.
Then the vendors. One sells an "AI Agent For Facebook Advertising" and its complete guide resolves, after a few hundred words of definitions, to a signup. Another scopes its agent to reporting and data analysis, which is the safe half of the problem. Reading a competitor's ads and summarizing your own performance takes real engineering, and it's still only the read path. The write path is where an agent creates campaigns, spends money, and can quietly set fire to an account. That's the half nobody publishes.
And then the two threads: a practitioner on r/FacebookAds who built an ads-research agent and is looking for people to test it, and a marketer in a coding group asking how to create one for ads strategy. Five comments each.
Those two are exactly who this post is for. The thesis post argued that an AI media buyer is a loop rather than a chat window. This post is the loop, with the panels off.
The folder is the architecture
Here's the least glamorous thing I can tell you about agents, and the one that matters most: the directory structure is the design. When people ask what an ads agent looks like, they're expecting a model, or a prompt, or some clever chain. It looks like a folder.
There's a skills directory holding an orchestrator plus nine stage skills, one per job. Then a set of directories for what those jobs produce: angles, copy briefs, creative batches, performance memos. A context directory holds the durable memory, the stuff that persists between runs. And a sprints directory holds run state, which is how the agent knows where it is.
Mine are built as Claude Code skills, so each one is a plain markdown file in a folder, but the pattern isn't specific to that. Any agent framework that can load a scoped instruction file and write its output to disk gives you the same agent skill stack. The framework is an implementation detail. The boundaries are the design.
Every stage writes its output to disk before the next stage starts. That single decision buys three things I wasn't willing to give up.
A human who wasn't watching can audit the whole run. You don't reconstruct what the agent did by scrolling a transcript and hoping. You open the folder. The angles it generated are a file. The copy it wrote is a file. The compliance verdict on each creative is a file, with reasons. If the agent made a bad call in stage three, you can see it in stage three's output, before it contaminated stage four.
A run can be interrupted without losing progress. Gates mean the agent stops constantly. If state lived in a conversation, every stop would risk the thread. Because state is on disk, the orchestrator can read the sprint file, work out that copy is done and assets aren't, and pick up there. When a human has to approve nine transitions, resumability is what makes the gates affordable in the first place.
The artifacts are reviewable by people who don't read code. A creative strategist can open the copy file and tell me variant six is weak. That review is worth more than anything I'd get from watching the agent think.
Chat-based agents keep their state in scrollback. Files don't scroll away.
What a skill actually is
"Skill" is doing a lot of work in this post, so let me pin it down. Two other words come with it: artifact and gate. An artifact is the one file a skill produces. A gate is a stop, where the agent finishes a stage, writes its artifact, and waits for a human to say go.
A skill is a narrow job with three declared parts: what it must read before it starts, what artifact it must produce when it finishes, and the rules it isn't allowed to break along the way. That's the whole idea. It's closer to a job description than a prompt.
The reads matter because they're how context gets scoped. The copy skill reads the angles the research skill produced and the brand's voice rules, and nothing else. It doesn't get the whole repository and a hope that it finds the right file. Narrow inputs are how you get a narrow, predictable job.
The artifact matters because it's a contract. The copy skill has to emit copy variants in a specific shape, because the image skill is going to read them. When the handoff is a file with a known structure, a stage can fail loudly instead of quietly passing garbage downstream.
The rules are where the engineering lives, because they're the parts a skill can't talk itself out of. My compliance skill can't be argued into a pass. My copy skill carries a hard requirement that a fixed share of every batch, between 20 and 30 percent, has to explore outside the patterns already known to work.
That explore quota exists because of a failure mode I find more interesting than any of the flashy ones. An agent that only reinforces its winners converges. It writes the same hook forty different ways, the creative homogenizes, and Meta starts deprioritizing your near-identical ads for the same reason your audience tunes them out. The loop optimizes itself into a monoculture. I've watched human teams do this with no AI involved at all, which is the tell that it's a structural problem rather than a model problem. If you've read how competitor creative fatigue shows up from the outside, you already know the shape of it: a brand running the same concept until the market stops seeing it.
You don't fix convergence with a better model. You fix it by making exploration a rule the optimizer can't optimize away.
The ten skills and what they hand each other
Nine stage skills, one orchestrator on top. Each one reads what the last one wrote.
Market research goes through competitor ads and the offer, and emits a set of angles: the pains, the hooks, the outcomes worth testing. Copy generation turns those angles into ad variants, with the explore quota enforced. The image-prompt builder converts each copy variant into a prompt manifest, which is a more finicky job than it sounds, because the prompt has to carry brand constraints the model would otherwise cheerfully ignore. Asset generation calls the image models and produces a creative folder: the actual files, plus metadata tying each asset to the copy it belongs to.
Then compliance screening, which reads every creative and its paired copy and returns a pass or fail per variant, with reasons. Failures stop there.
The publisher takes what passed and creates the objects in Meta. The performance analyzer reads back what those ads did and classifies each one as a winner, a loser, or undecided. The budget optimizer turns those classifications into budget actions.
And then the ninth skill, which is the one that matters most and gets the least attention: the brief updater. It reads the week's performance memos and rewrites the memory that briefs the next sprint. Which hooks earned their keep. Which formats died. What the copy skill should stop trying.
Take away that ninth skill and everything above it is a pipeline. A perfectly good pipeline, but a straight line: it runs, it produces ads, and next week it runs again exactly as ignorant as it was this week. The write-back is what bends the line into a loop, and it's the difference between an agent that compounds and an expensive content generator. Most demos skip it, because you can't fake it without having run the thing.
The orchestrator sits above all nine. It owns startup, works out where a run stopped, and enforces the gates.
The gate is the product
Here is the opinion this whole series rests on: in an ads agent, the constraints are the interesting engineering. What the thing is prevented from doing is what makes it safe to point at a live account.
An unconstrained model with write access to your ad account is a liability with a personality. The failure stories that circulate in media-buyer circles all rhyme. Something automated made a structural change at 2am, tripped the account back into learning, and torched a week of optimization before anyone opened Ads Manager. Meta's own documentation on the learning phase puts the bar at roughly 50 optimization events in the week after a significant edit. An agent that kills ad sets on 48 hours of noisy data will hold your account in permanent learning while reporting, accurately, that it's being decisive.
This is the part of Meta ads automation nobody demos, because a demo of an agent not doing something is just a screen where nothing happens.
So the agent is fenced in four ways.
A human approves every stage transition. Nine gates. It sounds heavy and it isn't, because most approvals take a few seconds of reading. The ones that take longer are the ones that deserved a person.
The compliance screener can block a creative, and I can't override it from inside the loop. A fail stops that variant. It doesn't get a second opinion from a more agreeable prompt.
No write touches the Meta API directly. Everything goes through a proxy that sits between the agent and Meta and can refuse. Today it forces every ad to PAUSED, rejects anything trying to go live, and enforces a budget cap. The agent never holds the raw access token. That proxy is the subject of its own post, because the design is more interesting than "we added a rate limit," and because the App Review process behind it is a story of its own.
Nothing gets judged on noise. No creative is called a loser until it clears an impression floor. Below that, the verdict is "undecided," which is the answer most dashboards refuse to give you.
The rules that decide when to kill a creative and when to scale one are the same rules a good operator uses. If you've built a real testing framework with kill and promote criteria written down in advance, you've already done the hard thinking. The agent just executes it without getting bored or attached.
What happened when it ran
Everything above is a diagram until the thing runs. So here is last week's sprint.
The agent produced ten copy variants from its research angles and generated ten creatives to match. The compliance screener passed nine.
It blocked the tenth. The image model had produced a mockup of a report interface, and inside that interface it had rendered metrics. Confident-looking numbers, in a product UI, that we have no data to support and never claimed. The screener caught it, marked the variant failed, and that creative did not ship.
That blocked variant earns more trust than the nine that passed. A guardrail that has never stopped anything is a guardrail you haven't tested. This one stopped a creative that a hurried human would plausibly have waved through, because it looked good. It looked like a product screenshot. It was a fabrication, and it was pointed at a platform whose policy team has strong opinions about unsubstantiated performance claims.
The agent then published one of the nine cleared variants into Meta as a paused ad, to prove the publish path end to end. Campaign, ad set, creative, ad. Paused, with a budget cap behind it.
Total spend across every run to date: zero dollars.
That is the honest state of this build. The creative factory works. The screener works and has the scalp to prove it. The publish path works. Nothing has been exposed to a live auction, and until the guardrails have been tried harder than this, nothing will be.
The agent's research skill reads the same data you can
Every angle in that sprint started from competitor ads in Meta's public Ad Library. That's the same source a Mako report runs for you: every live ad a rival is running, their hook patterns, format mix, CTA distribution, and how fast their creative engine is actually shipping.
If you want the finished read instead of the pipeline, look at a real one first. No login, no card.
The memory file is where the loop gets recursive
Everything so far describes a machine that produces ads. Run it every week and you get ads every week, each batch as uninformed as the last. One file changes that, and it's worth understanding properly, because it's the piece that separates an agent from a fast intern with no memory.
It's called winning-patterns.md, it lives in the context directory, and it's the only file the loop writes to itself.
Here's the cycle. The performance analyzer classifies last week's ads: winner, loser, or undecided. The brief updater reads those classifications and turns them into patterns with evidence attached. Not "video works," which is horoscope-grade advice, but something a copywriter could act on: this hook shape beat the ad-set baseline across four creatives, this offer framing lost twice, this format is still undecided after 1,400 impressions and needs another week. Every entry cites the ads it came from. Then next Monday, the copy generator reads that file before it writes a single variant. The sprint is briefed by what the last sprint actually did.
That's the recursion, and notice what it isn't doing. Nobody is fine-tuning a model. There's no training run, no weights, no black box. The learning is a file that gets rewritten, and it compounds because each week's file is the starting context for the next week's work. That design choice is doing a lot of quiet work:
- You can read it. The agent's entire accumulated belief system about your account is one page of plain text. If it starts writing bad ads, you open the file and usually find the bad idea sitting right there in line six.
- You can edit it. Delete a pattern you disagree with. Add one the data can't see, like a brand constraint or something the client said on a call. It's a text file. Ten minutes in that file shapes every ad the agent writes next week, which makes it the most valuable ten minutes an operator spends.
- You can roll it back. It's in version control, so a week of bad conclusions is a
git revert, not a retraining bill.
Two failure modes live in this file, and both are worth knowing about even if you never build one. Stale patterns: a hook that won in October will still be sitting there in March, quietly briefing every sprint, long after the audience got tired of it. Winning patterns need an expiry, or the file becomes a museum. And convergence: this file is exactly what the 20-30% explore quota exists to fight, because a copy skill briefed only by past winners will reproduce them forever. The memory tells the agent what worked. The quota forces it to keep asking what else might.
Mine is empty. Nothing has run live, so there's no performance data to write, and the file holds nothing. It should. If I filled it in now, I'd be writing my own assumptions about Meta and handing them to an agent that would treat them as evidence, then reading them back next week in the agent's handwriting and calling it a finding. Intuition, laundered through a file.
That empty file is my favorite thing in the repository, because it's the one place the build refuses to flatter itself. It's also a test you can run on someone else's agent. Most of you will never build one of these. You're going to get sold one, probably this quarter, probably by someone with a good deck. The architecture above is what you're buying, so it's what you should be asking about.
1. What does it write to disk, and can I read it? If the answer is a chat transcript, there's no audit trail. You can't review what you can't open.
2. Where does it stop and ask me? Ask for the list of gates. "It runs autonomously" is the answer you don't want, whatever the deck says about it.
3. What's in its memory, and where did that come from? A self-improving agent with a full pattern file and no live spend history is showing you somebody's intuition in a trench coat.
4. How many impressions before it kills a creative? With no floor and no "undecided" verdict, the thing is sorting noise and charging you for it.
The loop runs. The write-back works. What it has to learn from starts when the money does, and not one minute before.
What it's already caught me doing
The write-back mechanism does have data to run on, though. Not ad performance yet. My own mistakes.
Every sprint ends with a retro, and every retro appends to a log of anti-patterns, and every anti-pattern becomes a rule a skill enforces on the next run. Two examples from the last one.
The fast image model can't write. I'd been using a cheap, quick model for creative generation on cost grounds. It renders beautiful abstract imagery and it mangles text. Headlines came out with letters subtly wrong, and the logo came back as an approximation of itself. That's fine for a background and disqualifying for an ad. The rule now: anything containing headline text, interface text, or the logo uses the higher-fidelity model, and the fast one is confined to text-free backgrounds. Cost per creative went up. That's a real trade and it belongs in the next post.
The model will invent things that look like data. This is the blocked variant from the last section, promoted into a permanent rule. Product-interface regions in a creative are now either blank blocks or a real screenshot from a fixture file. The model is not permitted to fill them, because when you leave a model an empty rectangle labeled "metrics," it will fill it, and it will do it plausibly.
Notice the shape of both. A failure happens, it becomes a rule, the rule gets enforced by a skill, and the next sprint can't repeat it. That's the same write-back loop the ads version will run on performance data, currently running on the agent's own behavior. It's the loop learning to walk on the only real data it has.
What ships next
Post 3 is the image factory: which models can actually produce test-grade ad creative, what each one costs per usable asset, and the honest arithmetic of creative volume at a real budget. The fast-model demotion I mentioned above made that math worse, which makes it worth writing down.
The order of operations hasn't changed, and I'd rather be boring about it than clever. Architecture first. Sandbox second. Live spend last, and only once the guardrails have blocked things I would have let through.
An agent that can't be stopped is just an unattended one.
FAQ
What is an AI agent skill?
A skill is a narrow, single-purpose job definition an agent loads when it needs it. It declares three things: what it reads before starting, what artifact it produces, and the rules it can't break. Skills keep an agent's context small and its behavior predictable, and they make the whole system reviewable, because each one is a plain file you can read and argue with.
Can you connect an AI agent to Facebook Ads?
Yes. Meta ships Ads AI connectors that let an agent create campaigns, edit ad sets, and move budgets, and the Marketing API has been open for years. Connecting is the easy part, and it's the part every vendor demos. The work is everything that decides what the agent is allowed to do once connected.
How do you stop an AI agent from blowing your ad budget?
Four things, in order of how much they matter. Route every write through a proxy the agent doesn't control, so it never holds the raw API token. Gate the stage transitions so a human sees each batch before it ships. Set an impression floor before any creative can be judged, so nothing dies on noise. And pause at the ad level rather than restructuring ad sets, so you don't reset the learning phase. The proxy design gets its own post in this series.
Is an AI ads agent worth building for a small account?
Depends what you expect from it. At a budget around one to two thousand a month, the realistic creative throughput is five to eight a day, not the twenty-plus the vendor headlines advertise. I ran that math in the thesis post. If you're hoping to replace a media buyer, no. If you want to remove the manual grind of producing and screening creative volume so the human hours go to judgment calls, the numbers start working, and they work sooner for an agency amortizing the build across several accounts than for a single brand.