I've been running an autonomous Google Ads agent on a live account for several months. This post is the full written walkthrough — architecture, decision logic, guardrails, what it gets right and where a human still needs to be in the loop. The video embedded on the mission page shows the actual interface and a real optimisation cycle if you want to watch it run.
What the agent actually does each morning
At 08:00 GST, n8n triggers the cycle. The agent pulls yesterday's performance from the Google Ads API — spend, impressions, clicks, conversions, CPA — and cross-references it with GA4 session and goal data. It builds a picture of where the account stood yesterday relative to a 7-day rolling baseline for each campaign.
From that snapshot it makes three types of decisions. Routine reallocations — shifting budget from a campaign running 40% over target CPA to one converting at target — happen autonomously, within pre-set guardrails: no single campaign budget changes by more than 20% in a day, and the total account daily budget stays capped at AED 200. Negative keyword additions — search terms that spent without converting over a 7-day window — also run autonomously, logged with a rollback payload so any single change can be reversed in one call. Structural decisions — pausing an ad group, creating a new campaign, editing ad copy — are flagged for human approval and don't execute until I review them.
The architecture: Claude Code + n8n + MCP
n8n handles the scheduling and API routing. MCP (Model Context Protocol) exposes the Google Ads API and GA4 as tools the Claude Code agent can call during a reasoning loop — the agent doesn't see raw API payloads, it calls structured tools like get_campaign_performance(last_7_days) and apply_budget_change(campaign_id, new_daily_budget_micros). This matters because it keeps the agent operating at a semantic level rather than parsing JSON blobs — and it keeps the tool surface narrow enough that the guardrail layer can enforce hard limits at the tool call boundary, not inside the prompt.
The guardrail layer sits between the agent's decisions and the actual API calls. Every proposed change passes through a rules check before it executes: is the daily budget cap still respected after this change? Does this keyword negative block one of our own converting terms? Is this entity in a learning phase where changes are prohibited? A rejected decision is logged with the rejection reason — the agent can see its own rejection history and adjust, but it cannot override a guardrail by arguing. That boundary is hard-coded, not prompt-controlled.
The rollback layer
Every mutation writes a rollback payload before it executes — the previous state of whatever entity is being changed, stored in the change log table. If the account's 24-hour CPA rises more than 40% above the 7-day average after a cycle, the watchdog automatically reverts that cycle's changes and sends an alert. This is the prime directive that makes autonomous execution defensible: anything the agent does must be undoable in one call, and a defined trigger condition fires the undo automatically. Without this, 'autonomous' means 'unsupervised and unrecoverable when something goes wrong.'
ONE TACTIC A WEEK
Results after running it in production
Weekly optimisation time dropped from 9 hours to 2. The 2 hours that remain are the structural decisions the agent correctly flags for human review — campaign creation, ad copy changes, anything that requires business context the agent doesn't have. ROAS improved 18% quarter over quarter, mostly from the negative keyword loop catching waste the manual weekly review was too slow to catch. The agent ran 237 autonomous cycles in the first quarter without a single rollback trigger — not because the guardrails are loose, but because the decision scope is deliberately narrow.
The honest caveat: this works because the account structure was already clean before the agent started. An autonomous agent running on a poorly structured account with missing conversion tracking will optimise toward the wrong goal at full speed. The system I run at /work/printo spent 3 months cleaning attribution before any automation touched the bid and budget layer. The agent is the last step, not the first.
Why autonomous doesn't mean no oversight
The agent runs in what I call shadow mode first — it generates decisions and logs them without executing, so you can verify the reasoning matches what a competent human would do before flipping to live mode. I reviewed 3 weeks of shadow decisions before enabling execution on this account. The decisions it made in shadow mode matched what I would have done manually in about 85% of cases; the 15% it got wrong were all structural decisions that the escalation gate correctly flagged anyway and didn't execute.
If you're building something similar, the order matters: instrument and clean your conversion tracking first, run in shadow mode until you trust the reasoning loop, then enable autonomous execution on routine reallocations only. Add structural decisions last, and keep the rollback trigger tight. Autonomous is not a setting you flip on day one.
Related reading
The full results this agent drove for Printo: AED 11.20 CPA, 3,750 conversions on AED 42K spend — and what AI automation services actually cost and deliver in the UAE in 2026.