Tuning AdMob Placements at Runtime with Firebase Remote Config and an Antigravity Agent

Design principle: give the Agent a narrow lane

The first principle I locked down: do not give the Agent full authority to decide. Remote Config ships directly to live users, so an Agent that goes off the rails can break every user's experience at once. The boundaries I chose are:

• The only parameters the Agent can touch are Remote Config keys marked "dynamic-tunable"
• Any value change is capped at ±15% of the current value, and must stay within a pre-defined absolute floor and ceiling
• The change applies to at most 10% of users (controlled via a Remote Config condition)
• The Agent may only use Firebase Analytics, AdMob, and Crashlytics metrics as inputs. Moving values based on a sentiment read of review text is forbidden

I wrote these boundaries into AGENTS.md as guardrails the Agent is required to read. The relevant section looks like this:

## Constraints on automated Remote Config tuning
 
In this repo, only Remote Config keys with the `tunable.` prefix are eligible
for Agent-driven adjustment. Keys with the `fixed.` prefix must never be
modified by the Agent.
 
- At most 2 keys may be changed in a single tuning pass
- New values must stay within ±15% of the current value
- Changes apply only to the "audience: opt_in_experiment" segment (10% of users)
- Each key may be changed at most once per day
- If the last 24h Crashlytics crash-free users metric drops below 99.0%,
  no automated tuning runs at all (human review required)

Only after this was written down could I hand the Agent the "look at the data and decide" role. The next step was to express the decision loop as an Antigravity Workflow.

The shape of the nightly tuning loop

The loop runs once a day at 02:00 JST and goes through six steps. I picked the dead of night so that the impact of any change is visible by the time I wake up.

1. Pull the last 7 days of metrics from Firebase Analytics (BigQuery export) and AdMob
2. Pull the Crashlytics crash-free users figure. If it is below 99.0%, exit
3. Pull the last 24 hours of Remote Config change history (Firebase Remote Config REST API)
4. Hand all of that to an Antigravity Agent and ask for at most two proposed key/value changes
5. Validate each proposal against the AGENTS.md guardrails. Discard anything that fails
6. Apply surviving proposals to Remote Config and notify Slack

The first version of this had step 4 flow directly into step 6. A few clearly bad proposals slipped through, so I broke out step 5 as an independent validation step. Having a deterministic, hand-written validator sit between the Agent's proposal and production has held up well.

// scripts/admob-tuning/validate-proposal.ts
import { AGENTS_GUARDRAIL } from "./guardrail";
 
type Proposal = {
  key: string;
  current_value: number;
  proposed_value: number;
  reason: string;
};
 
export function validateProposal(p: Proposal): { ok: boolean; reason?: string } {
  if (!p.key.startsWith("tunable.")) {
    return { ok: false, reason: `non-tunable key: ${p.key}` };
  }
  if (!AGENTS_GUARDRAIL.allowedKeys.includes(p.key)) {
    return { ok: false, reason: `key not in allowedKeys: ${p.key}` };
  }
  const delta = Math.abs(p.proposed_value - p.current_value) / p.current_value;
  if (delta > 0.15) {
    return { ok: false, reason: `delta ${(delta * 100).toFixed(1)}% > 15%` };
  }
  const bounds = AGENTS_GUARDRAIL.bounds[p.key];
  if (p.proposed_value < bounds.min || p.proposed_value > bounds.max) {
    return { ok: false, reason: `out of bounds: ${bounds.min}-${bounds.max}` };
  }
  return { ok: true };
}

I do not let the Agent write this validator. The judgment can be delegated, but the validation of that judgment runs through deterministic code I wrote by hand. Once I split those roles, my comfort level running this against production went up another notch.

A gotcha around metric freshness

Anyone running the BigQuery export for Firebase Analytics knows the default: previous-day data lands a few hours into the morning. If your tuning loop runs at 02:00, what it actually has access to is the day before yesterday's data. If you don't recognize this, the Agent will propose changes based on a world that doesn't reflect what you just did.

I always prepend the Agent's context with a freshness note:

Data freshness notes:
- Firebase Analytics: last 24h not included (BigQuery export spec)
- AdMob API: today's figures finalize in the afternoon, so the last 12h are excluded
- Crashlytics: roughly real-time (about 1 hour delay)
 
So at 02:00 today, the most recent Analytics data available is from 5/19.
The effect of any Remote Config change you made yesterday (5/20) cannot yet be
judged. If a change exists from yesterday, mark it as "impact unmeasured" and
hold off on new proposals.

Since adding this note, the Agent has stopped its most dangerous behavior — changing a value immediately after a previous change. Separating "what to prevent with prompts" from "what to prevent with code" is a discipline you have to develop deliberately when you put Agents in production.

Wrapping it in an Antigravity Workflow

Antigravity's Workflow feature ties the whole loop together in a single file. Mine lives at .antigravity/workflows/admob-nightly.yaml:

name: "AdMob nightly tuning"
schedule:
  cron: "0 2 * * *"
  timezone: "Asia/Tokyo"
 
variables:
  app_id: "com.dolice.wallpaper.zen"
  guardrail_path: "scripts/admob-tuning/guardrail.ts"
 
steps:
  - id: fetch_metrics
    run:
      command: "pnpm exec tsx scripts/admob-tuning/fetch.ts"
      env:
        TARGET_APP_ID: "${{ variables.app_id }}"
    timeout: 120
 
  - id: crash_gate
    run:
      command: "pnpm exec tsx scripts/admob-tuning/crash-gate.ts"
    on_failure: abort_workflow
 
  - id: agent_proposal
    agent:
      profile: "tuning-strategist"
      input_from: "fetch_metrics"
      max_iterations: 4
    timeout: 300
 
  - id: validate
    run:
      command: "pnpm exec tsx scripts/admob-tuning/validate.ts --proposal=${{ steps.agent_proposal.output_path }}"
    on_failure: skip_remaining
 
  - id: apply_remote_config
    run:
      command: "pnpm exec tsx scripts/admob-tuning/apply.ts --proposal=${{ steps.validate.output_path }}"
 
  - id: notify
    run:
      command: "pnpm exec tsx scripts/admob-tuning/notify-slack.ts --result=${{ steps.apply_remote_config.output_path }}"

agent.profile references an Agent profile registered on the Antigravity side. The profile definition constrains the tools the Agent may use, the AGENTS.md sections it may read, and the output format it has to produce.

# .antigravity/agents/tuning-strategist.yaml
name: "tuning-strategist"
description: "Reads AdMob and Firebase metrics and proposes Remote Config tunings"
allowed_tools:
  - read_file
  - run_shell: ["pnpm exec tsx scripts/admob-tuning/fetch.ts --help"]
context_files:
  - "AGENTS.md#constraints-on-automated-remote-config-tuning"
  - "scripts/admob-tuning/playbook.md"
output_schema: "scripts/admob-tuning/proposal.schema.json"
max_proposals: 2

Forcing output_schema means I always get a structured JSON alongside the Agent's natural-language reasoning. That JSON is what flows into the validator. If you let an Agent emit free-form text downstream, format drift is guaranteed somewhere. The biggest lesson from running this for six months is to enforce a structured handoff at every Workflow boundary.

How to choose the share of users you tune

Setup talk aside, the hardest operational question is: how large a slice of users do you let the Agent touch? My current setting:

• 90% of the audience runs on hand-set values (the "fixed" bucket)
• The remaining 10% is eligible for Agent-driven tuning (the "experiment" bucket)
• Inside the experiment bucket, a Remote Config condition further splits it into two sub-buckets: one keeps the 7-day baseline, the other applies Agent proposals

I started at 30% for the experiment bucket and stepped it down. At 30%, when the Agent moved a couple of values in close succession, overall eCPM would swing 5-8%. At 10%, the swing stays under 1% and the worst-case blast radius is something I can reason about.

For an indie developer running on AdMob, revenue predictability is everything. Heavy month-to-month eCPM volatility makes monthly set-asides and forward planning harder. My north star is "monthly revenue volatility under 5%," and the experiment bucket size is chosen to stay under that ceiling.

The judgment layer behind the tuning

The playbook (playbook.md) handed to the Agent spells out the order of judgment in prose:

## Priority of judgment
 
1. If crash-free users is below 99.0%, propose nothing at all
2. If Day 1 retention is more than 1.5pt below the 7-day average, only propose
   changes in the direction of reducing ad exposure (negative adjustments)
3. If Day 1 retention is stable (within +/-0.5pt of the 7-day average) AND
   eCPM has fallen below its 14-day low, only propose format-switching keys
4. If none of the above apply, return "no proposal"
 
## Forbidden proposals
 
- Setting the rewarded multiplier above 1.5x
- Setting the App Open frequency above 1.5 per session
- Flipping the Day 0 suppression flag to false (Day 0 is sacred for retention)

Making the order of judgment explicit stabilizes the Agent's proposals. One subtle distinction: keep the judgment in the playbook, not in AGENTS.md. AGENTS.md is for "guardrails I never want to relax"; playbook.md is for "this week's strategy" and is expected to change. Separating these two roles makes the improvement cycle much easier to run.

Slack notification: separating judgment from intent

A final design note about Slack. Every proposal the Agent makes, applied or not, lands in Slack so I can scan it in the first five minutes of my morning. The body looks like this:

[AdMob nightly tuning] 2026-05-21 02:14 JST
 
Metrics evaluated (5/13-5/19)
- Day1 retention: 32.8% (-0.3pt vs 7d avg)
- Interstitial eCPM: $4.07 (-2.4% vs 14d min)
- App Open eCPM: $3.21 (-5.6% vs 14d min)
- Crash-free users: 99.62%
 
Agent proposals (2)
1. tunable.interstitial_frequency_cap: 4 -> 3 (-25.0%)
   reason: eCPM fell below 14d low; reduce frequency to recover unit price
   -> rejected: delta 25.0% exceeds 15% cap
 
2. tunable.app_open_min_interval_sec: 30 -> 35 (+16.7%)
   reason: App Open eCPM trending down; widen interval to preserve unit price
   -> rejected: delta 16.7% exceeds 15% cap
 
Changes applied: 0
 
Note: both proposals were rejected by the guardrail this run.
If you see three consecutive days of all-rejections, revisit the playbook.

When that lands, I decide whether to nudge Remote Config by hand or whether to loosen the playbook. Every Agent proposal — including the rejections — is logged in Slack, so later I can go back and understand exactly why the Agent did or did not act. Making the boundary between Agent decisions and human decisions auditable is, for me, the minimum bar for trusting an Agent in production.

Six months in: what worked and what didn't

After six months in production, the wins are clear and the limits are clearer.

Wins:

• Time spent on daily ad monitoring dropped from 30-45 minutes/day to 5-10 minutes/day
• Zero ad-related incidents (no Day 1 retention drops >1.5pt) in the six-month window
• The experiment bucket eCPM has averaged +3.2% over the fixed bucket

The honest part: the fantasy of "let the Agent loose and watch eCPM soar" has not materialized. The +3.2% is largely because the fixed bucket is run conservatively. The Agent's standalone contribution is inside the noise. Today the Agent's real job is less "make smarter decisions than me" and more "absorb the daily monitoring burden so revenue volatility stays bounded."

Even so, the half-hour I get back every day shows up where it matters — time for art work, time to talk with my kids. Both my grandfathers were temple carpenters, and watching them build things that hold up for decades shaped how I think about systems. I want a monetization stack that can be sustained for the long run, not one I have to babysit. The Agent-driven Remote Config loop, so far, is moving things in that direction.

What I want to try next

Two improvements are queued up.

First, slice the experiment bucket by in-app behavior segments rather than by random 10%. Firebase Analytics audiences let me address "users who watched rewarded at least 3 times in the last 30 days" or "non-IAP users who lasted past Day 7" as separate cohorts, with separate tuning strategies. I already have five audiences defined and plan to wire up matching Agent profiles in the coming month.

Second, use Antigravity Background Agents to have a second Agent review the first Agent's decision log. Weekly: "of the 7 proposals last week, were the 5 rejections appropriate? Were the 2 applied changes still the right call in hindsight?" The conclusions feed back into playbook.md revisions. Continuously evaluating the quality of Agent judgment using another Agent and historical data is, I suspect, going to be a baseline requirement for any indie developer who wants to put Agents into production.

I will be publishing the full code and playbook examples separately on dolice.design. If you are operating multiple apps and tuning AdMob and Remote Config on your own, I hope some piece of this is useful. Thanks for reading.