Build a Paid Media Agent for Google Ads with sign-off

A paid media agent for Google Ads ops does not need to be autonomous to be useful — it needs to be trustworthy. This is a build guide for an agent that reads your account through the Google Ads Query Language (GAQL), runs three fixed checks, and stops to ask a human before anything changes. The differentiator is the guardrail, not the model.

The three workflows are the ones agencies already babysit by hand: budget pacing, search-term triage, and target or recommendation audits. Each is grounded in a real Google Ads API resource, so the read layer is concrete rather than aspirational. What makes this an engineering post rather than a manifesto is the boundary: Google's own RecommendationService is a single call away from applying changes for you, and this design deliberately stops short of it.

There is a timely reason this matters right now. Google applied a rewritten Ads Terms of Service to all accounts on July 1, 2026, expanding the automation authority it can exercise on your behalf — while explicitly keeping you responsible for reviewing what those tools generate. That contract change turns a sign-off layer from a nice-to-have into a compliance-shaped gap worth filling. This guide is evergreen; the news is context, not the load-bearing hook.

On July 1, 2026, Google applied a rewritten Ads Terms of Service to every account automatically — no login prompt, no explicit acceptance step. The new language authorizes Google to format, select or generate targets, ads and destinations on the advertiser's behalf through automated program features. It is the first substantive rewrite of that automation authority in years, and we unpack the clause itself in our companion piece on Google's July TOS rewrite and what the AI clause means.

Here is the sentence that should shape your architecture: even as it expands what Google's tools may do automatically, the terms keep advertisers responsible for reviewing, approving, editing or removing any campaigns and ad assets those tools generate or modify. The platform expanded its authority to act and, in the same document, reaffirmed that the obligation to review sits with you. That is not a best practice anymore — it is written into the contract you are operating under.

An agent that reads the account, spots the changes worth acting on, and routes each one to a human for approval is the operational answer to that obligation. It is also just good engineering. The same enforcement direction shows up elsewhere in the platform — our note on Google's tCPA and tROAS target enforcement from August 17 is a concrete example of an automated behavior a target audit should be watching for.

It is worth being precise about what you are building. In Anthropic's engineering framing, workflows are systems where language models and tools are orchestrated through predefined code paths, while agents are systems where the model dynamically directs its own process and tool use. An ops agent that runs three fixed checks and stops for a human is much closer to a workflow with an agentic read layer than to a fully autonomous agent — and that is a feature, not a limitation.

The same guidance recommends pausing for human feedback at checkpoints, particularly before irreversible or high-stakes actions, and warns that autonomy brings higher costs and the potential for compounding errors. In paid media, a wrong budget edit or a bad bidding-strategy switch is exactly the kind of high-stakes, hard-to-cleanly-undo action that belongs behind a checkpoint. The reflex to add autonomy should be resisted until it demonstrably improves outcomes — and missed pacing or search-term drift is solved by a read-and-flag loop without it.

So the shape of the system is deliberate. A scheduled read layer polls the account. A rules layer decides what crosses a threshold. A drafting layer turns each crossing into a specific proposed action — a budget edit, a negative keyword, a recommendation to apply or dismiss. And a sign-off layer, living in Slack or email outside the Ads API, is where a human says yes before any mutate call is ever made. The model is doing the reading and the summarizing; the human is doing the deciding.

The Google Ads Query Language queries the API through GoogleAdsService's Search and SearchStream methods, returning GoogleAdsRow results with the resource attributes, segments and metrics you ask for. A basic anomaly or pacing query is as plain as SELECT campaign.id, metrics.impressions, segments.date FROM campaign with a WHERE filter — and the same shape extends to the two other resources this build needs. That is the entire read surface: three resources, one query language.

Google also ships an official, read-only Ads MCP server that is worth knowing about here. It exposes exactly three tools — list_accessible_customers, search (GAQL) and get_resource_metadata — and, by its own documentation, cannot modify bids, pause campaigns or create assets. If you want the read companion to this build wired into Claude or Gemini, our Google Ads MCP server setup guide walks through it. Treat it as a read layer only; the write path in this design never runs through it.

One honest caveat on visibility. If your account leans on Performance Max, its search-terms reporting is rolling out but shows only a subset of terms that generated significant traffic — not the complete, query-level view standard Search campaigns provide. A newer source column does trace which surface a query came from, which is genuinely useful for flagging channel imbalances. Design the triage workflow to treat PMax coverage as partial, and it stays honest.

None of these is a novel idea — agencies already run brittle, manual versions of them. The agent's job is to formalize existing best practice into a repeatable system with a consistent output: a flagged item and a proposed action, never a silent change. For the pacing thresholds, ground your idea of “normal” in real category data — our 2026 PPC benchmarks are a useful reference for what typical spend behavior looks like.

This is the architecture most “agentic PPC” content skips in favor of vague talk about guardrails. Below is the concrete version: for each workflow, exactly what the agent reads, what makes it flag, what it hands you, and the specific Google Ads API surface that your approved action ultimately calls. Every column traces to a real API resource — nothing here is invented.

Read the last column carefully. In all three workflows the agent produces a draft and nothing else. The mutate call — the actual write — only ever fires after a human clicks approve in the sign-off layer. The API services in that column are real, and the agent is fully capable of calling them. The design choice is to make it wait.

ApplyRecommendation is a real, one-call auto-apply path that Google exposes. An ops agent that already queries RecommendationService to build its target-audit digest is a single line of code away from applying those recommendations automatically. That proximity is the whole reason the sign-off design exists: the capability to go autonomous is right there, and the engineering discipline is in choosing not to wire it up.

There is a practical failure mode that makes the case for a review loop concrete rather than theoretical. Practitioners report that auto-applied recommendations and opt-ins can quietly revert — you turn something off, walk through the whole review, and later find it turned back on. A one-time toggle is not a control; a human-approval loop with an audit trail is. So the sensible policy is to route Google's own recommendation types by reversibility and spend impact, and to never auto-apply the ones that move money or switch bidding strategy.

Two separate ceilings govern how a multi-account ops agent behaves. The first is a fixed daily operation quota tied to your developer token's access level. Every Get, Search/SearchStream and mutate counts as one operation; a single mutate request is capped at 10,000 operations, and some action-style requests at 100. Exceeding the daily cap returns RESOURCE_EXHAUSTED. The table below recomputes each tier's cap as a share of Basic Access so you can size a polling loop honestly.

The second ceiling is separate from the daily quota: the API also rate-limits by queries per second, per customer ID and per developer token, using a token-bucket algorithm. There is no single published fixed QPS number — the exact ceiling varies with server load, and violations return RESOURCE_TEMPORARILY_EXHAUSTED. Do not hard-code a magic QPS constant; design for backoff instead. Google's own escalating mitigations are a ready-made checklist: cap concurrent tasks, batch operations into single mutate calls, add a client-side token-bucket rate limiter, and use message queues with coordinated backoff.

The change_event resource is the audit-trail mechanism, and it is easy to over-claim. It returns exactly what changed on a resource — old value, new value, whether a UI or API client made the change, and which user made it, where that is visible in Change History. That is genuinely valuable for reconstructing what happened. But it is retrospective: it reports changes after the fact. It cannot block a change or require sign-off before one happens.

There is also a hard constraint on reach. A change_event query’s WHERE clause on change_date_time is required and must cover a window of at most 30 days within the past 30 days. So the audit trail is a rolling 30-day view unless you archive it yourself. The lesson for the architecture is clean: use change_event to verify that approved changes landed and to catch anything that changed without going through your loop — but build the actual approval gate outside the Ads API, in the Slack or email sign-off step where a human says yes before the mutate ever runs.