Cody Schneider, co-founder of the marketing agency Graph, opens a recorded live class with a claim: for the last four months he has managed Facebook ads "almost entirely through Claude Code," with an agent that researches ads, makes them, publishes them, turns the losers off and promotes the winners.[1] That is an agent running a business operation, not writing code, which makes the design worth studying for a company that is not a software shop. In his setup, what holds everything up is a plumbing decision: the agent changes the ad account through one door and studies the results through another.
What the agent is actually doing.
Strip out the tool names and the job has five parts: find what the target customer complains about, turn that into ads, publish them, cut the ones that do not convert, and put more money behind the ones that do. Schneider builds it first on his own computer with a coding agent, then deploys it to a server where it runs "on some type of cadence, whether it's hourly, whether it's daily."[1] His own definition of the result is plain: an agent is "software with a thinking loop with some type of live data stream."[1]
Two things make this harder than a coding task. The agent touches money every time it acts, and it works through a platform with its own rules about how it may be used. Both shape the design.
Writes go through the API. Reads come from a warehouse.
The agent gets a key to Meta's Marketing API, issued through a private developer app and a system user in Business Manager, not a public app submitted for review.[1] Schneider gives that key exactly two jobs: upload new creative, and manage the account (turn off a losing ad, promote a winner, move ads between ad sets). Then comes the warning the whole build rests on: the API is not for "doing the data analysis."[1] He gives two reasons. Both make sense without taking his pitch on trust, though Meta's documentation backs only part of the first.
- Meta rate-limits the Marketing API per ad account.
An analysis pass takes a lot of reads. Meta's documentation scores Marketing API calls per ad account, where "a read API call is equal to 1 point, and a write API call is equal to 3 points." Past the ceiling, requests fail with a throttling error and are blocked for a set period.[2] Reads and writes draw on that one score, so an agent that spends it on reporting can find itself throttled at the moment it needs to pause a losing ad. Schneider goes further and warns that hammering the API can get the ad account banned, "not because they're like against a coding agent interacting with it," but because the call pattern breaks the API's terms.[1] Meta's page stops short of that: it documents throttling, and says that when ad accounts "generate a large amount of abnormal traffic," it will "temporarily reduce the API Rate Limit quota" of those accounts.[2] It does not mention bans, so treat the ban risk as his experience rather than Meta's stated rule.
- Raw rows are not an answer.
Pull an account's history through the API and the agent is left, in his words, trying to work out "what do I do with a 100 million rows of data."[1] He lists what goes wrong when an agent analyzes straight from API pulls: made-up numbers, truncated results, and pagination errors where pages of results go missing.[1] A warehouse turns the same data into something the agent can ask a question of.
So the read side is a pipeline. Ad results, site analytics, and CRM or store data flow into one warehouse, and the agent gets query access to the warehouse, not to the platforms.[1] The pipeline becomes the only thing that reads the platform API in bulk, so it can be paced to the rate limit once, in one place. Meta's own guidance points the same way: for large reporting pulls, it recommends asynchronous and batched requests over many small calls.[2]
The rule travels past ads. Any agent working a rate-limited third-party API on your behalf (a CMS, a booking system, a search console) is better off with a narrow write path and a separate read path it can query as hard as it likes. It has a side benefit too: the write path is short enough to list, and a list is something you can log and review.
Why not the database you already have?
Asked in the Q&A whether a Supabase database (Postgres underneath) would do, Schneider allows that you could pipe the data into it but steers away from it: a query over 100 million rows "could take like literally minutes" there and milliseconds in ClickHouse, the analytics warehouse he names, because the two are "structurally like fundamentally different."[1] He shows no benchmark, so take the numbers as a practitioner's impression. The direction is standard, though. An everyday database stores data row by row, which suits reading or updating one record at a time. An analytics warehouse stores it column by column, which suits adding up one field across millions of records. "Which ads worked last month" is the second kind of question.
He also lists the chores a homemade pipeline has to handle: respecting the rate limit, removing duplicates where the platform returns overlapping chunks, and a data model with, by his count, 42 tables for Facebook ads alone.[1] For a small account, the real question is whether you need any of this yet. The build-or-buy section below takes that up.
One dated aside. Asked whether a Facebook ads MCP server could replace the direct API, he reports that it exposed only a handful of endpoints and could "functionally break" at his call volume, then adds "don't quote me on this": his last look was about four weeks before the class.[1] That is one team's experience at one point in time; check the current endpoint list before you choose either.
Test, promote, retire, remix: a loop with walls.
The account runs as two campaigns.[1] A testing campaign holds several ad sets, each with about five ads competing for that ad set's budget. Schneider notes that Meta's delivery system now does most of the winner-picking itself, steering budget toward the ad it expects to convert. A winner moves to a winners campaign, where it competes against other proven ads and is watched for ad fatigue: the point where the audience has seen it so often that results fall off. Losers are paused. Winners are remixed (same idea, new execution) and sent back into testing. How fast one cycle turns depends on budget against cost per result; in his telling, anywhere from two days to a week.
A loop like this is the kind of operational process owners want to hand off, and the kind that goes wrong quietly, because every step looks reasonable on its own. The source describes the loop. It says much less about the walls around it. These are the four we would put in before letting it run unattended; they are our design, not his.
- A spending ceiling the agent cannot raise.
The agent moves budget between ads inside a total a person sets. Enforce the total in the agent's code, not only in its instructions, and set a spending limit on the ad account itself as a backstop.
→ the agent spends inside the budget; it never sets it - A short list of allowed writes, logged.
Upload, pause, move, shift budget under the ceiling. Anything else (a new campaign, an audience change, billing) goes to a person as a request. Every write lands in a log with the reason the agent gave for it.
- A person decides what counts as a win.
The agent optimizes whatever the account reports as a conversion, so that choice stays human. Schneider's advice is to start with an event high in the funnel, such as a signup, because the platform needs volume to learn, then move deeper (a key action in the product, then payment) as volume allows, and to track no more than about five events.[1]
- A rule that stops the whole loop.
Decide in advance what pauses everything: spend running ahead of plan, a run of rejected ads, a broken pipeline feeding the agent stale numbers. Our runaway-loop worked example shows how a loop without one can run up a bill.
The agent that keeps making the same ad.
The most useful moment in the class is a problem Schneider says his team is still working on.[1] Left to run the loop on its own, the agent "makes a lot of the same stuff unless you introduce like new DNA into the system."[1] It is easy to see how. Each round, it remixes what won the round before, and the next winners come out of that narrower pool. Run it long enough without anything new coming in, and the account fills with variations on a few ideas. Nothing broke; the loop did what it was rewarded for.
His fix comes from outside the loop rather than from the prompt or the model: competitors' ads from the public Facebook and Google ad libraries, and trending short-form video pulled through a third-party service, fed in as raw material for the next batch.[1] He uses the competitor ad libraries for the cold start too: the first batch for a brand with no winners yet. Upstream of both, his ad copy starts from words customers already use: complaints and wishes gathered from forums like Reddit, rather than benefits a marketer guessed at.[1]
The same thing happens outside advertising. Any agent that improves by reusing its own best output (email subject lines, product descriptions, outreach scripts) tends to drift toward sameness, and the symptom looks like stability, not failure. Put a source of new material on the schedule, and check the output for variety, not only for performance.
Build it, buy it, or have it built.
Asked whether a viewer could build all of this alone, data warehouse included, Schneider says it is "totally possible": roughly two weeks to something usable but "monkey patched" (held together with quick fixes), four to six weeks to something he would call enterprise-ready, with the AI tokens spent building it a large part of the cost.[1] He also tells smaller advertisers they may not need the full agent yet. A person running a coding agent on their own computer, with an API key, already saves the hours of uploading and managing ads by hand, and the cloud deployment can wait until the system works.[1] That is advice against his own pitch, which makes it worth weighing.
If the account is small, his own advice is the cheap start: a coding agent on your own machine, a key with the two write jobs, and a person reviewing what it did each day. Add the warehouse when the questions you ask outgrow what the platform's own reports answer, and the cloud deployment when the loop has run long enough that you trust its walls. Our note on the order autonomy is earned in walks the same ladder for agents in general.
What this does not claim.
Vendor source, no results repeated. The class sells the service it describes. We left out every cost-per-result figure in it, because none comes with a baseline or a method.
Meta's rules, checked where we could. The per-account rate limit, the read and write scoring, the throttling, the temporary quota cut for abnormal traffic and the advice to batch large reporting pulls are in Meta's documentation. The risk of an account ban for analysis traffic is the presenter's claim; Meta's rate-limit page does not state it.
The warehouse speeds are an impression. "Minutes versus milliseconds" comes with no benchmark. The row-store versus column-store difference behind it is general knowledge; the numbers are his.
No client record. We have not run this system for a client. The four walls are how we would design it, and the "have it built" column in the table is how we quote, not a measured delivery time.
Running ads and wondering whether an agent could take over the uploads and the weekly pruning? Describe the account through the contact form and you get a free written first read: what we would automate first and what we would leave to a person. Agent builds like this are part of our assistants and agents work.