FIELD REPORT 16 · AI SYSTEMS · HIGH TICKET SALES CLIENT
I wrote the rules for a six figure monthly ad account, then built the agents that run them. Two judgment reviews a day make the cuts and budget steps the rules allow, log every action with its before and after values, and page a person only when a call is outside their authority.
The client sells a high ticket offer through booked sales calls. Paid media runs at six figures a month on Meta and Google, across several ad accounts, with new creative going in all the time.
An account that size asks the same questions every day. Which ads crossed the line and should stop? Which earned more budget, and was the last raise long enough ago? Answered from memory, those calls drift. A favorite ad gets a day it didn't earn, and a good morning gets a raise that should have waited.
So I wrote the doctrine down with a number in every rule. Then I built agents in Claude Code and Python that run it twice a day, act inside it, log what they did, and page a person when a call is outside their authority.
The agents read this file at the start of every run. Under it, the same logic runs as a simulator. Set the inputs to see which rule fires and the log line the agent would write.
Spend reaches 3x the target cost per qualified application with no qualified application: cut. No waiting for another day of data.
Budget goes up in steps of 25%, at least 48 hours apart. Cuts are exempt from the wait.
A test is judged on spend, never on days live. Nothing is cut or raised before it has spent 3x its target cost per qualified application.
Named campaigns the agent can read but never change. If a rule fires on one, it pages a person with its recommendation.
Each review can move the account's net daily budget only so far. Anything past the cap waits for the next review or a person.
TRY A CASE, OR MOVE THE INPUTS
THE CHECKS, IN ORDER
THE CALL
R1 · KILL RULEThe ad spent 3x its target without one qualified application. The agent pauses it now and does not wait for more data.
THE LOG LINE · EXAMPLE FORMAT
08:30 am_review ad_0417 action=CUT rule=R1_kill_3x spend=$950 qa=0 target=$300 (3.17x) status=ACTIVE→PAUSED budget=$400→$0 actor=agent
Illustrative inputs for one ad with a fixed $400 daily budget, so the before and after values are easy to read. The live agent reads trailing windows by lane and by ad from the data lake. R5 applies to a whole review, so a single ad never trips it here.
A scheduled headless run in Claude Code and Python. Everything inside the dashed line it may do alone. Anything outside it becomes a page to a person.
Each account against the spend expected by that hour.
New rejections and policy flags since the last run.
Conversion events still arriving from the site and the CRM.
Account status, payment method and spending limits.
HEALTH CHECK · STEP 02 · EVERY ACCOUNT, EVERY RUNA red item stops the run before any rule fires.
| TIME | OBJECT | ACTION | RULE | BEFORE | AFTER | WHY |
|---|---|---|---|---|---|---|
| 08:31 | Test lane ad set | CUT | R1 kill rule | Active, $250/d | Paused, $0 | 3.1x target spent, 0 qualified |
| 08:31 | Scale ad set A | RAISE | R2 raise rule | $800/d | $1,000/d | Under target, 52h since the last raise, value read back |
| 08:32 | Scale ad set B | HOLD | R2 48 hour clock | $600/d | $600/d | Under target, raised 30h ago, next step in 18h |
| 08:32 | New file | LAUNCH | Ladder | Rung 1 | Rung 2 | Cleared rung 1, cooldown over, a review slot open |
| 08:33 | Protected campaign | PAGE | R4 never touch | $1,200/d | $1,200/d | An ad in it crossed the kill line. A person decides. |
| 08:33 | Net, this review | NET | R5 daily cap | $2,850/d | $2,800/d | −$50 a day across the rows above, inside the cap |
Budgets are illustrative and add up: the cut removes $250 a day and the raise adds $200 (25% of $800), so the review nets out at −$50 a day. Every row carries its before and after value, and the after value is read back from the ad platform, never assumed.
Every file starts at the bottom, where a rejection costs little, and climbs only after surviving the rung it's on. Rung names and settings are an example of the structure.
The grader scores the copy before anything uploads.
A low risk account. New concepts go in together, so reviews run in parallel.
A second review on a different account, and the first qualified signal.
Only files that cleared both test rungs. One at a time, on a floor budget.
Proven winners only. Nothing is tested here.
Two rejections and a file stops climbing for good. A retired file never goes back up the ladder; the idea goes back to the edit.
Example settings: at most two files in review on a rung at once, a 48 hour cooldown between adds on the same rung, a hold of a few hours after an approval before the next add.
Book a call and see if it's a fit.
Guaranteed results in 30 days.Promises an outcome. This line has to change before upload.
Are you tired of doing it all yourself?Asks the reader about a personal attribute, which Meta reviews closely.
Only 3 spots left this week.Scarcity has to be true on the day the ad runs.
The grader reviews and never rewrites. Every flag carries a reason, and a person makes the change. I calibrated its scoring against ads the platforms had actually approved.
Three reports go to people on a fixed rhythm. A watchdog script handles time boxed pushes, and the review reads its log.
YESTERDAY VS THE TRAILING WEEKSHAPE, NOT DATA
From ad spend to closed deals in funnel order, by account and by lane. It lands at 7 AM, before the morning review.
EVERY AD, EVERY WEEKROLLED UP THREE WAYS
Hook rate and hold rate for every ad, rolled up by angle, hook and audience, so the next shoot starts from what keeps working.
EXAMPLE ROWSONE PER LIVE AD
ad_0412under targetINad_0415inside its test windowWATCHad_0417R1: 3.2x target, 0 qualifiedOUTad_0420cost drifting upWATCHad_0423raised this morningININ keeps running. WATCH is inside its test window or drifting. OUT is cut or retired, with the rule that did it. The ops team gets the verdicts without opening an ad account.
ONE PUSH DAYSHAPE, NOT DATA
An overnight brake and a morning raise, plus pacing checks through the day. It writes absolute budgets, never deltas, so a rerun can't double a change. The review reads its log and pages only on an error.
Agents fail quietly. These two taught me the most, so they stay in the report.
The result is an operating rhythm. Judgment calls happen on a schedule and inside written limits, and anyone can read back why a budget moved.
The calls happened when someone logged in, and the reasons lived in their head.
The calls happen at 08:30 and 20:30 against written rules. Every action has a line with its before and after values, and anything outside the rules goes to a person.
The agents read their numbers from the data lake I built for the same client.Field report 04: The data lake behind cut, scale and kill
The rules, schedules and failures come from my own build notes and review logs. Times are the schedule in round numbers. Budgets, log rows, ad copy and scores are illustrative. The client's name and account figures stay private.
Write the rules before the agent. Give every rule a number, or the agent will pick one for you.
Log the before and after value of every action, and read the after value back from the platform. The next run starts from that log.
Give the agent a boundary and a pager. Inside the line it acts without asking. Outside it, it stops and pages a person with a recommendation.
Happy to walk through any of these live.