Building a Budget Guardrail: AI agents That Pause Ads on CAC Spikes

TL;DR

We shipped a budget guardrail during a volatile promo week by wiring OpenClaw workflows into ad APIs so AI agents could freeze risky campaigns and ask for human approval. The system watched CAC in short rolling windows, applied a control band to avoid noise, and paused campaigns only after a Slack check. We leaned on dry runs, idempotency keys, and staged rollouts to avoid accidental outages. The result was less spend wasted above target and a workflow the marketing team trusted enough to keep on after the launch.

The moment CAC went sideways

Two hours into a one day sale, a bundle landed on our homepage and search terms shifted. Our paid search CAC jumped from a 7 day median of 48 to 112 within 20 minutes. Nothing in the ads platform looked obviously broken. The bid rules were still green, budgets had headroom, and the landing pages were live. We had a choice: wait for analysts to triage, or add a guardrail that could pause campaigns when the cost curve bent sharply.

We chose the guardrail. The constraint was simple and unforgiving. It had to be reversible in minutes, explainable to non engineers, and safe against data lag. A false positive would trash revenue, so the first version needed to be cautious and human in the loop.

Framing the guardrail

The shape of the solution came from three constraints we wrote on a whiteboard:

1. The signal must use only data we can compute in near real time from reliable sources.
2. The action must be reversible, logged, and idempotent.
3. The rollout must start small and expand only after we see clean behavior.

Step 1Define the budget risk signal

We needed a simple and legible rule, not a complex model. CAC equals cost divided by attributed conversions for the same campaign and window. To avoid noisy spikes from tiny denominators, we required a minimum spend threshold and at least N conversions before any action. Although we considered a better anomaly detector, a control band around the trailing median performed well and was easy to explain.

We encoded one long tail intent directly into the spec so the team could search for it later: how to pause ad campaigns automatically when CAC spikes. That sentence became the design principle. The guardrail checked CAC every 5 minutes, compared it to a band computed from a 14 day window, and gated actions behind a spend floor.

Step 2Shape the data contract

The workflow needed two inputs and one output. Inputs were campaign level spend and campaign level conversions. Output was a campaign pause or a decision not to act. We pulled spend via the Google Ads API and Meta Marketing API using service accounts, then joined against our warehouse conversions table by campaign id. To reduce flakiness, we excluded same day conversions from the denominator on the first pass and allowed a replay to fill the gap later in the day.

Here is a reduced view of the contract we used inside the workflow:

contract:
  inputs:
    - name: spend_window
      fields: [campaign_id, platform, cost, start_at, end_at]
    - name: conv_window
      fields: [campaign_id, attributed_conversions, start_at, end_at]
  output:
    - name: action
      fields: [campaign_id, platform, action_type, reason, run_id, idempotency_key]

Step 3Build the Playbook in OpenClaw

We wrote a single Playbook that took window bounds and a list of campaign labels as variables, then fanned out per account. The early version calculated CAC, applied a control band, and raised a decision. Only after a Slack approval would it call the platform API to pause.

playbook: pause_on_cac_spike
vars:
  window_minutes: 30
  min_spend: 200
  min_conversions: 5
  band_multiplier: 1.8
  target_label: "guardrail-optin"
steps:
  - id: load_campaigns
    uses: accounts.list_campaigns
    with:
      label: "${{ vars.target_label }}"
  - id: fetch_costs
    uses: ads.get_costs
    foreach: "${{ steps.load_campaigns.campaigns }}"
    with:
      window_minutes: "${{ vars.window_minutes }}"
  - id: fetch_conversions
    uses: warehouse.get_conversions
    foreach: "${{ steps.load_campaigns.campaigns }}"
    with:
      window_minutes: "${{ vars.window_minutes }}"
  - id: compute_signal
    run: node
    with:
      code: |
        const cost = inputs.cost;
        const conv = Math.max(0, inputs.conversions - inputs.same_day_conversions);
        const cac = conv > 0 ? cost / conv : Infinity;
        const thresh = context.median_cac * vars.band_multiplier;
        if (cost >= vars.min_spend && conv >= vars.min_conversions && cac > thresh) {
          outputs.trigger = true;
          outputs.cac = cac;
        } else {
          outputs.trigger = false;
        }
  - id: request_approval
    when: "${{ steps.compute_signal.trigger }}"
    uses: slack.request_approval
    with:
      channel: "#growth-ops"
      message: "Pause ${campaign.name} on ${campaign.platform}? CAC ${cac.toFixed(2)} over band."
      ttl_minutes: 30
  - id: pause_campaign
    when: "${{ steps.request_approval.approved }}"
    uses: ads.pause_campaign
    with:
      campaign_id: "${{ campaign.id }}"
      idempotency_key: "${{ workspace.id }}:${{ campaign.id }}:${{ now().toDateString() }}"
  - id: audit
    uses: events.write
    with:
      type: "guardrail.action"
      payload: "${{ steps.pause_campaign }}"

The code above elides integration specifics, but the shape held up under test. We kept the calculation readable and the flow linear. OpenClaw variables allowed the marketing team to adjust spend floors and the band multiplier without a deploy.

Step 4Add human-in-the-loop approval

We wanted the first release to be opinionated but humble. The workflow asked a human to confirm the pause and provided enough context to make a fast decision. The message included campaign name, platform, current CAC, trailing median, and the last three conversion events. The team could approve or reject in Slack with one click. If they ignored the message for 30 minutes, the request expired and no action fired.

The approval shape looked like this in TypeScript:

interface PauseDecision {
  campaignId: string;
  platform: 'google-ads' | 'meta-ads';
  cac: number;
  medianCac: number;
  spend: number;
  conversions: number;
}

function approvalBlocks(d: PauseDecision) {
  return [
    { type: 'section', text: { type: 'mrkdwn', text: `*${d.platform}* ${d.campaignId}\nCAC ${d.cac.toFixed(2)} vs median ${d.medianCac.toFixed(2)} on spend ${d.spend}` } },
    { type: 'context', elements: [{ type: 'mrkdwn', text: 'Last 3 conversions joined by campaign id' }] },
    { type: 'actions', elements: [
      { type: 'button', text: { type: 'plain_text', text: 'Approve pause' }, style: 'danger', action_id: 'approve' },
      { type: 'button', text: { type: 'plain_text', text: 'Reject' }, style: 'primary', action_id: 'reject' }
    ]}
  ];
}

Step 5Make it safe at scale

Two safety rails mattered from day one. First, idempotency. Every action step computed a key from workspace id, campaign id, and date, checked a control table, and no-oped if a match existed. Retries and duplicate events from upstream systems did not duplicate pauses. Second, rate limits and concurrency. We used a token bucket per API and fanned out by account with per account queues. When the Google Ads API returned a 429, backoff used full jitter and the run recorded a soft failure instead of rolling the whole playbook.

We also invested in observability. The workflow emitted a structured event for every decision and every action. Traces tied together cost fetches, conversion reads, approval messages, and pause calls under a single run id. That made incident review straightforward.

Step 6Roll out without breaking the ad team

The first day used a single account, one campaign label, and a dry run. We delivered decisions to Slack and asked the team to approve or reject as if the pause were real. After a clean day, we enabled a subset of campaigns for actual pauses. Two weeks later, we tagged almost all search campaigns with the opt in label and left top of funnel brand terms out.

This is where product links helped the team understand what we had actually built. We shared the page that lists our AI marketing automation features and used the comparison grid to highlight the difference between guardrails and rules. We also pointed people new to the product to ButterGrow, which frames the hosted OpenClaw assistant in plain language.

What the first week looked like

The promo day closed slightly below plan, but the system made three human approved pauses that prevented another 12 percent of spend above target. No one woke up to find a flagship campaign paused without a record. The finance team saw the nightly rollups move in the right direction within 48 hours.

We also found an opportunity. Two of the pauses were from campaigns that used very broad match types. The guardrail did not know that, but the human reviewers added a note and the channel manager tightened match types the next morning.

Tradeoffs and alternatives

The obvious alternative is a set of rules entirely inside the ads platforms. That is faster to get started, but it is hard to keep a single source of truth for CAC and attribution logic across multiple platforms. The guardrail sat in our system of record and used one CAC calculation that the finance team already trusted.

Here is a simple comparison that we used to explain the choice:

Guardrail method	Precision	Ops overhead	When to use
Platform native rules	Medium	Low	Single platform, simple metrics
Warehouse joins then actions	High	Medium	Cross platform, strict finance alignment
Full anomaly model with features	High	High	Large portfolios, on staff data science

We kept the first version readable and auditable. In future iterations, we may add a stronger detector backed by features like time of day and promo flags. For now, the control band and thresholds provide a clean lever for the channel managers.

Failure modes we hit and fixed

We hit three bugs in the first 48 hours.

• A Slack approval expired just as someone clicked Approve. Our step handled the race by checking the decision TTL again at the action step and writing a clear audit log instead of pausing.
• A Meta account returned a transient 500 while listing campaigns. The run wrote a soft failure, retried with jitter, and finished on the second attempt without rolling the batch.
• A conversion table refresh lagged more than usual. Because we excluded same day conversions on the first pass, the denominator was stable. The second pass, scheduled near end of day, reconciled and wrote an informational event.

We also documented an operating manual for when people ask why a campaign paused at a specific time. The run id shows who approved, the CAC and spend at the moment, and the campaign identifiers we used. The audit trail built trust quickly.

Long tail design questions we wrote down

We kept a living document with questions that read like search queries so future project owners could discover them easily:

• build a budget guardrail agent for paid media without overreacting to noise
• policy based marketing automation for ads that is reversible and auditable
• how to structure idempotency keys for campaign actions across retries

If you are considering this pattern, that list is a good place to start.

Lessons we would share with another team

Start with a human in the loop. Make the first version almost boring. Keep equations clear. Name the risks in plain language. Move slowly on actions and fast on visibility. And test the happy path and the noisy path equally. A short runbook and a simple control band beat a clever model that no one trusts.

If you want to understand the broader context of guardrails in growth systems, our analysis on policy engines for marketing guardrails covers the ideas we used here from a product angle. For deeper product discovery or pricing, see the answers to common questions in the FAQ and the section that describes what ButterGrow does.

Implementation notes for engineers

Below is a compact view of two helpers that made day one reliable. The first scopes idempotency to a day and campaign. The second wraps a pause call with backoff and structured logging.

const IDEMP_PREFIX = `${process.env.WORKSPACE_ID}:guardrail`;

function idempotencyKey(campaignId: string, day: string) {
  return `${IDEMP_PREFIX}:${campaignId}:${day}`;
}

async function pauseWithBackoff(client: any, campaignId: string, key: string) {
  const maxAttempts = 5;
  let attempt = 0;
  let delay = 500;
  while (attempt < maxAttempts) {
    try {
      const res = await client.pauseCampaign({ campaignId, idempotencyKey: key });
      console.log(JSON.stringify({ type: 'guardrail.pause.ok', campaignId, res }));
      return res;
    } catch (e: any) {
      const code = e.status || e.code;
      console.warn(JSON.stringify({ type: 'guardrail.pause.retry', campaignId, code, attempt }));
      if (code === 429 || code === 500 || code === 503) {
        await new Promise(r => setTimeout(r, delay + Math.random() * 250));
        attempt += 1;
        delay *= 2;
      } else {
        throw e;
      }
    }
  }
  throw new Error('pause failed after retries');
}

We left the actual client implementation out of this snippet because each team’s SDK differs, but the shape is the same. The wrapper keeps the playbook code clean and the logs easy to query.

Where this fits in your stack

If you already run on ButterGrow, this pattern drops in cleanly because OpenClaw runs the agentic workflows behind the scenes. If you are new to the product, you can try this with a sandbox account. The other articles on the blog include longer guides on analytics, attribution, and workflow design that pair well with this case study.

Our team now uses the same skeleton for lead cost and ROAS. We swap the denominator and plug in a different minimum spend number. The same human in the loop pattern keeps trust high while we raise the level of autonomy over time.

To avoid chasing platform specifics here, see the official documentation for the APIs we used. The Google Ads and Meta docs cover authentication, quotas, and the resources that control campaign state.

This project replaced a set of ad hoc cron jobs with a single agentic workflow that we can reason about. The code is short, the logs are rich, and the rollback is a button instead of a hope.

Our last note from the retro was simple. The right guardrail makes people faster. It is not there to replace judgment. It is there to focus attention where it matters and buy time when something moves.

The pattern is not limited to paid media. Anywhere you have a clear metric, a safe action, and a reversible control, you can borrow the same bones.

ButterGrow gave us that shape and OpenClaw let us build it quickly.

This was the first guardrail we shipped, not the last.

Our next iteration is a bid dial that moves budgets instead of pausing outright when the control band is only slightly exceeded. That will likely be easier for the team to adopt on evergreen campaigns.

We will also experiment with a per product line control band so brand terms and long tail terms get different treatment without splitting the workflow.

If you want to try this pattern with your own stack, you can start a sandbox workspace on ButterGrow and follow the onboarding steps to wire your ad accounts. The product docs show how to get started in minutes, and the feature overview explains the set of capabilities you will use for guardrails and approvals.

References

• Meta Marketing API documentation - Official guide for managing campaigns programmatically.
• Google Ads API documentation - Overview of the official API used to read spend and change campaign state.
• Statistical process control on Wikipedia - Background on control bands and why they reduce false positives.