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 proposal is the Agent's; the gate it has to pass is mine, written by hand. Once I split those roles, my comfort level running this against production went up another notch — though it took me another four months to notice that the gate itself had a hole in it.

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.

Not leaving a bad call live for 40 hours

About two months into running this, I found the hole in my own design. A value applied at 02:00 does not show up as a full day of Analytics data until the BigQuery export settles the next morning, around 09:00. And the loop itself cannot evaluate that day until the following night — roughly 48 hours after the change went out.

So a proposal that clears every guardrail but is quietly wrong sits on 10% of my users for two full nights. The crash-free gate only runs once, at the top of the loop, so any degradation that does not crash the app walks straight past it. That is not hypothetical: a proposal that widened the App Open minimum interval shipped, and I only noticed the shortened sessions in the experiment bucket two days later.

The fix was a second, faster signal path that can revert without waiting for me.

Picking a proxy metric

Day 1 retention is simply not readable in time. What I use instead is the share of sessions abandoned within three seconds of an ad impression — I call it the rage-quit rate. Dropping the app immediately after being shown an ad turned out to lead retention damage reliably. Backfilling six months of data, days where that rate moved by +1.5pt or more were followed by a Day 1 retention drop averaging 0.9pt.

I do not route it through Analytics, because that puts me back behind the export. A 15-minute batch increments rolling counters in Firestore instead.

Decide it is not noise before you revert

Fast signals carry their own hazard. A 15-minute window holds few samples, and a naive "revert if it moves +1.5pt" rule flaps constantly. My first version did exactly that and rolled back four times in one day for no reason at all.

Now it computes a 95% confidence interval on the difference between the two bucket proportions and only fires when the lower bound clears zero.

// functions/src/rollback/significance.ts
 
/** 97.5th percentile of the standard normal (two-sided 95%) */
const Z_95 = 1.959964;
 
export type BucketCount = { events: number; quits: number };
 
/**
 * Is the experiment bucket's rage-quit rate meaningfully worse than the
 * fixed bucket's — i.e. is the lower bound of the difference above zero?
 */
export function isSignificantlyWorse(
  experiment: BucketCount,
  fixed: BucketCount,
  minSamplePerBucket = 800,
): { fire: boolean; diffPt: number; ciLowPt: number; reason: string } {
  if (experiment.events < minSamplePerBucket || fixed.events < minSamplePerBucket) {
    return { fire: false, diffPt: 0, ciLowPt: 0, reason: "sample too small" };
  }
 
  const pE = experiment.quits / experiment.events;
  const pF = fixed.quits / fixed.events;
  const diff = pE - pF;
 
  // Unpooled standard error: we only care about detecting one-sided harm
  const se = Math.sqrt(
    (pE * (1 - pE)) / experiment.events + (pF * (1 - pF)) / fixed.events,
  );
  const ciLow = diff - Z_95 * se;
 
  return {
    fire: ciLow > 0,
    diffPt: diff * 100,
    ciLowPt: ciLow * 100,
    reason: ciLow > 0 ? "experiment significantly worse" : "within noise",
  };
}

On top of that, the revert requires fire === true in two consecutive windows. A single significant window can be an artifact of the user mix shifting suddenly — a Play Store feature placement, for instance. That exact false positive happened once in six months.

Running the same test against my own headline number is sobering, and worth doing. The +3.2% eCPM advantage the experiment bucket shows over the fixed bucket comes with a 95% confidence interval of −0.4% to +6.9% when computed on six months of per-user daily revenue. It leans positive, but it straddles zero. The numbers that flatter your own system are the ones most worth putting through the test.

Revert one key, not the whole template

This is where the implementation surprised me. Remote Config exposes projects/{project}/remoteConfig:rollback, which takes a versionNumber and restores it. Convenient — but it restores the entire template. Any manual edit I made to a different key after the Agent's change gets wiped along with it.

So the normal path fetches the template, rewrites only the target key, and uses the ETag as an If-Match optimistic lock. The whole-template :rollback is reserved as a last resort, after three consecutive ETag conflicts on the targeted path.

// functions/src/rollback/revert-key.ts
import { google } from "googleapis";
 
const RC_BASE = "https://firebaseremoteconfig.googleapis.com/v1";
 
export async function revertKey(
  projectId: string,
  key: string,
  previousValue: string,
): Promise<{ reverted: boolean; note: string }> {
  const auth = new google.auth.GoogleAuth({
    scopes: ["https://www.googleapis.com/auth/firebase.remoteconfig"],
  });
  const client = await auth.getClient();
  const token = (await client.getAccessToken()).token;
 
  // 1. Pull the live template along with its ETag
  const getRes = await fetch(`${RC_BASE}/projects/${projectId}/remoteConfig`, {
    headers: { Authorization: `Bearer ${token}` },
  });
  const etag = getRes.headers.get("etag");
  const template = await getRes.json();
 
  if (!etag) {
    return { reverted: false, note: "etag missing; abort" };
  }
  if (!template.parameters?.[key]) {
    return { reverted: false, note: `key disappeared: ${key}` };
  }
 
  // 2. Touch only the target key
  template.parameters[key].defaultValue = { value: previousValue };
 
  // 3. Optimistic lock. A concurrent edit comes back as 409
  const putRes = await fetch(`${RC_BASE}/projects/${projectId}/remoteConfig`, {
    method: "PUT",
    headers: {
      Authorization: `Bearer ${token}`,
      "Content-Type": "application/json; UTF-8",
      "If-Match": etag,
    },
    body: JSON.stringify(template),
  });
 
  if (putRes.status === 409) {
    return { reverted: false, note: "etag conflict; caller should retry" };
  }
  if (!putRes.ok) {
    return { reverted: false, note: `unexpected status ${putRes.status}` };
  }
  return { reverted: true, note: `reverted ${key} -> ${previousValue}` };
}

The previousValue it writes back is persisted to Firestore by apply.ts in the same transaction that applies the change. Decide where you are reverting to before you move forward — otherwise, at 02:00, there is nowhere to go back to.

Three firings, and what they cost

The auto-revert has triggered three times: two true positives, one false. The interesting true positive was the widened App Open interval — the longer gap made the full-screen ad feel like an unexpected intrusion rather than a familiar one, and abandonment went up. Mean time from apply to revert was 41 minutes. Compared with me noticing on the morning of the second day, that is roughly a seventieth of the exposure.

The limits are worth stating plainly. This catches coarse damage that shows up immediately after an impression. The slower kind — an app that becomes a little more tiring to open each week — does not register in a proxy metric at all. Fast signals exist to stop accidents. Deciding whether a change is actually good still belongs to the slow ones.

The flaw I found in month four: relative guardrails compound

One evening, feeling comfortable now that auto-revert was in place, I opened the live value of tunable.app_open_min_interval_sec and stopped. The key I had set at 30 seconds when I started was sitting well past a minute. Auto-revert had never fired. validateProposal had never rejected anything. Every single night's change had genuinely been inside ±15%.

The flaw was in the formula itself. When you measure the delta from the current value, the current value is whatever last night's Agent chose. The reference point moves every night, so no matter how tightly you enforce the per-night limit, nothing constrains the drift across a week.

Here is a seven-night run I did on my own machine, assuming a proposal at the ceiling clears every night.

Seven nights turn 30 seconds into 74 seconds — more than 2.4x — without a single violation. Assuming the ceiling clears every night is a little unkind, but a week where the proposals lean consistently in one direction moves close to this. Fifteen percent a night is also 1.15 to the seventh power, and I worked that out only after counting past sixty on the live value.

My first thought was that the absolute bound would catch it. But bounds for this key is 20-90 seconds. As long as the range is wide enough to be usable in production, 74 seconds sits comfortably inside it. An absolute bound is a ceiling for accidents, not a rein on drift.

Reading the validator again, I found a second hole. validateProposal only ever sees one proposal at a time. AGENTS.md says "at most two keys per run" and "at most one change per key per day," and a per-proposal check cannot verify either of those. Two proposals for the same key, each within ±15%, compound to close to 30% once both land. I had written the guardrail in prose and handed the code only half of it.

The third hole is smaller. Because delta is Math.abs(p.proposed_value - p.current_value) / p.current_value, a current value of 0 yields NaN — and NaN > 0.15 is false. The worse the input, the more cleanly it walked through the gate. It failed open.

Move the reference point from last night to the start of the week

Here is the corrected version. Three changes: a weekly baseline comparison, batch-level validation, and the direction of the comparison operator.

// scripts/admob-tuning/validate.ts
import { AGENTS_GUARDRAIL } from "./guardrail";
import { readWeeklyBaseline } from "./baseline";
 
type Proposal = {
  key: string;
  current_value: number;
  proposed_value: number;
  reason: string;
};
 
type Verdict = { ok: true } | { ok: false; reason: string };
type Baseline = Record<string, { value: number; frozenAt: string }>;
 
// Validate the whole run's proposals together.
// One-at-a-time checks miss duplicate keys and week-scale drift.
export function validateBatch(proposals: Proposal[]): Array<{ p: Proposal } & Verdict> {
  if (proposals.length > AGENTS_GUARDRAIL.maxProposalsPerRun) {
    return proposals.map((p) => ({
      p,
      ok: false as const,
      reason: `batch size ${proposals.length} > ${AGENTS_GUARDRAIL.maxProposalsPerRun}`,
    }));
  }
 
  const baseline = readWeeklyBaseline(); // frozen Monday 02:00
  const applied = new Set<string>();
  const out: Array<{ p: Proposal } & Verdict> = [];
 
  for (const p of proposals) {
    const v = validateOne(p, baseline, applied);
    out.push({ p, ...v });
    if (v.ok) applied.add(p.key);
  }
  return out;
}
 
function validateOne(p: Proposal, baseline: Baseline, applied: Set<string>): Verdict {
  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}` };
  }
  if (applied.has(p.key)) {
    return { ok: false, reason: `duplicate key in same run: ${p.key}` };
  }
 
  const bounds = AGENTS_GUARDRAIL.bounds[p.key];
  if (!bounds) {
    return { ok: false, reason: `no bounds registered for ${p.key}` };
  }
  if (!Number.isFinite(p.current_value) || !Number.isFinite(p.proposed_value)) {
    return { ok: false, reason: "non-finite value" };
  }
  // The old version divided by zero here; NaN > 0.15 is false, so it passed
  if (p.current_value === 0) {
    return { ok: false, reason: "current_value is 0; relative delta undefined" };
  }
 
  // Assert "inside the range" rather than "outside it" so NaN falls to false
  const nightly = Math.abs(p.proposed_value - p.current_value) / Math.abs(p.current_value);
  if (!(nightly <= AGENTS_GUARDRAIL.nightlyDelta)) {
    return {
      ok: false,
      reason: `nightly ${(nightly * 100).toFixed(1)}% > ${AGENTS_GUARDRAIL.nightlyDelta * 100}%`,
    };
  }
 
  const base = baseline[p.key];
  if (!base) {
    return { ok: false, reason: `no weekly baseline for ${p.key}` };
  }
  const weekly = Math.abs(p.proposed_value - base.value) / Math.abs(base.value);
  if (!(weekly <= AGENTS_GUARDRAIL.weeklyDelta)) {
    return {
      ok: false,
      reason: `weekly drift ${(weekly * 100).toFixed(1)}% from ${base.value} (frozen ${base.frozenAt})`,
    };
  }
 
  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 set weeklyDelta to 0.25. A key can still move 15% in one night, but it can never end up more than 25% away from the value frozen at the start of the week. Replaying the table above through the new validator, it stops on night two at 39 seconds — 30.0% from baseline. Two proposals for the same key now fail on the second with duplicate key in same run.

The baseline re-freezes exactly twice: at the start of the week, and whenever I move a value by hand. Agent applications never touch it. If you let the Agent's own writes refresh the baseline, you are back in the same hole under a new name. The reference is not last night — it is the value frozen at the start of the week. That one line resolved four months of quiet confusion.

The same shape hides anywhere a guardrail is expressed as a relative change. If you have a constraint written as "±N% per run," it is worth taking a minute with a calculator to see what N compounds to over a week. I went four months without doing that.

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 (though the 95% CI runs from −0.4% to +6.9%)
• The auto-revert fired three times in six months (two true positives, one false), mean recovery 41 minutes

One caveat on that zero: it covers the three months before I fixed the drift described above, too. It may be less that nothing went wrong and more that the proposals happened not to lean the same way for long enough.

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 is going somewhere real. A monetization stack that grows quietly but never breaks while you look away outlasts one that spikes. Six months of running this has only sharpened that view, and the Agent-driven Remote Config loop is, so far, pulling 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.