SARA is my autonomous Google Ads optimization system — a production agent that reads account and analytics data every morning, decides what needs to change, executes the routine changes itself, and queues anything consequential for my approval. It cut my weekly optimization time from 9 hours to 2 and the accounts it runs on saw +18% ROAS quarter over quarter. This is the full architectural breakdown: the four layers, the guardrails, what it's allowed to touch unsupervised, and what broke along the way — because the failure modes are the part vendor content never shows you.
The problem: manual optimization doesn't scale
Before SARA, serious account management meant 9+ hours a week of recurring work: search term reviews to mine negatives and new keywords, bid and budget pacing checks, RSA asset performance reviews, and cross-referencing GA4 to catch tracking drift. None of it is intellectually hard — it's reading, pattern-matching, and small adjustments. But it has to happen consistently, and when it slips, decisions get made on stale data. The insight that started the build: this workload is mostly interpretation of structured data, which is exactly what a language model with tool access is good at.
System architecture: four layers
The data layer pulls Google Ads API and GA4 data through MCP, exposing both as typed tools — the model requests "campaign performance, last 7 vs prior 7" and gets structured data back, never touching credentials. The reasoning layer is Claude Code running a senior-media-buyer role prompt: it interprets performance signals against the account's targets and outputs decisions in a fixed, machine-parseable format. The orchestration layer is n8n: scheduled morning pulls, webhooks between steps, and the approval gates that route consequential decisions to a human. The action layer is deliberately the thinnest: a scoped set of mutations SARA may execute directly, with everything else landing in an approval queue instead.
What SARA does autonomously — and what it never touches
Unsupervised: search term harvesting and negative keyword additions, bid and budget pacing adjustments within pre-set bands, RSA asset rotation and pause rules based on asset performance, and anomaly alerts when spend, CTR, or conversion volume moves outside expected ranges. Never unsupervised: new campaign structures, budget increases above a defined threshold, changes to conversion actions or measurement, and anything touching brand messaging. The line isn't arbitrary — it separates reversible, low-blast-radius changes from decisions that reshape the account or the spend envelope.
Building the guardrails
ONE TACTIC A WEEK
Guardrails were designed before autonomy was granted, not after. Every proposed action carries a category, and each category has a permission tier: auto-execute, auto-execute-with-log, or queue-for-approval. Every executed change is audit-logged with the reasoning that produced it, and pacing changes are bounded so no single day's decisions can move budget beyond a set band. Rollback matters most: every mutation is recorded with its prior state, so any change can be reversed in one step.
The gates earned their keep in testing. The real example I keep telling: a conversion tracking glitch made a campaign look like it had collapsed, and SARA's proposed response was a sharp budget cut on what was actually the account's best performer. The anomaly check flagged the discrepancy between Ads and GA4 signals, the decision queued instead of executing, and a human caught it in minutes. An unguarded version of that same system would have torched a live budget on bad data — that incident is why measurement changes stay permanently human.
The build: the agent loop
The loop itself is simple to describe. n8n fires the morning workflow, pulls the data snapshots, and hands Claude Code a prompt with three parts: the role (a senior media buyer with explicit judgment rules and thresholds), the state (current performance windows, pacing status, recent changes and their outcomes), and the required output format — a JSON list of decisions, each with an action type, target, magnitude, confidence, and a plain-language reason. n8n parses that output, executes the auto-tier actions through the API tools, routes the approval-tier ones to me with the reasoning attached, and logs everything. The reason string on every decision is non-negotiable; it's what makes the log auditable and the approvals reviewable in seconds. I'm not publishing the full production prompt, but the n8n tutorial post on this site walks through building a working version of this exact loop.
Results
Two headline numbers. Weekly manual optimization time went from 9 hours to 2 — the remaining 2 being approvals, strategy, and reviewing SARA's log rather than doing the reading myself. And +18% ROAS quarter over quarter on the accounts it runs, which I attribute to consistency: the mechanical work now happens every single morning at the same standard, which no human maintains. This post owns the system story; the CPA-specific outcome on the Printo account — a different, complementary set of numbers — has its own full case study post.
Lessons and tradeoffs
Where autonomy underperforms a sharp human: anything requiring context the account doesn't contain — a competitor's launch, a supply issue, a seasonal nuance the data hasn't expressed yet. SARA reasons brilliantly over what it can see and not at all over what it can't. There's also a real latency-and-cost tradeoff to running a frontier model in the loop daily; it's worth it for accounts with meaningful spend, and hard to justify below a certain size where there isn't enough conversion volume for the reasoning to have signal anyway. What I'd rebuild differently: I'd design the evaluation harness first — replaying historical account states and scoring the agent's decisions against what actually happened — because I built it after the first scare, and it should have gated the first day of autonomy, not the second month.