Splitting Daily Crashlytics Triage Across Five Antigravity Sub-Agents

Fetcher Agent: pull and normalize from Crashlytics

The Fetcher Agent has two jobs. One is to pull raw data from Crashlytics, either through BigQuery export or the REST API. The other is to strip PII and produce a shape that the downstream stages can rely on.

I run six apps, so the agent reads the target app list from a config file. Apps where AdMob revenue is significant get a lower threshold (more crashes flow through), apps that just launched get a higher threshold (only severe crashes flow through). The app-level weighting lives in config, not in the agent prompt.

# agents/fetcher/main.py
import json
import os
from datetime import datetime, timedelta, timezone
from google.cloud import bigquery
 
PII_FIELDS = {"user_email", "custom_keys.user_id", "device.serial"}
 
def normalize_crash(row: dict) -> dict:
    """Convert a raw crash row into PII-stripped normalized form."""
    return {
        "issue_id": row["issue_id"],
        "title": row["issue_title"],
        "subtitle": row.get("issue_subtitle", ""),
        "app_id": row["app_id"],
        "app_version": row["application"]["display_version"],
        "os": f'{row["os"]["name"]} {row["os"]["display_version"]}',
        "device": f'{row["device"]["manufacturer"]} {row["device"]["model"]}',
        "occurred_at": row["event_timestamp"].isoformat(),
        "fatal": row["is_fatal"],
        "stack_top": _top_frames(row["exceptions"][0]["frames"], n=8),
    }
 
def _top_frames(frames: list, n: int) -> list:
    """Take top n frames, preferring app-owned symbols over vendor frames."""
    own_prefix = os.environ["APP_BUNDLE_PREFIX"]
    own = [f for f in frames if f.get("file", "").startswith(own_prefix)]
    rest = [f for f in frames if f not in own]
    chosen = (own + rest)[:n]
    return [{"file": f["file"], "line": f["line"], "symbol": f.get("symbol")} for f in chosen]
 
def fetch(app_ids: list[str], hours: int = 24) -> dict:
    client = bigquery.Client()
    since = datetime.now(timezone.utc) - timedelta(hours=hours)
    sql = """
    SELECT * FROM `crashlytics.firebase_crashlytics.*`
    WHERE event_timestamp > @since
      AND is_fatal = TRUE
      AND application.app_id IN UNNEST(@app_ids)
    LIMIT 50
    """
    job = client.query(
        sql,
        job_config=bigquery.QueryJobConfig(
            query_parameters=[
                bigquery.ScalarQueryParameter("since", "TIMESTAMP", since),
                bigquery.ArrayQueryParameter("app_ids", "STRING", app_ids),
            ]
        ),
    )
    crashes = [normalize_crash(dict(row)) for row in job.result()]
    return {"schema": "crash-batch-v1", "fetched_at": datetime.now(timezone.utc).isoformat(), "crashes": crashes}
 
if __name__ == "__main__":
    out = fetch(json.loads(os.environ["APP_IDS"]))
    print(json.dumps(out, ensure_ascii=False))

Stripping PII at the entry point means downstream logs are clean by construction. For an indie developer running on both stores, this is a mandatory implementation detail rather than a nice-to-have.

A practical gotcha: Crashlytics stack frames mix your own symbols with SDK internals, and naively taking the top eight frames can leave you with zero app-owned frames. The _top_frames helper prefers app-owned symbols first. After that change, the downstream classifier accuracy improved by roughly 30 percent in my measurements.

Classifier Agent: four buckets and a priority score

The Classifier Agent reads Fetcher's output and labels each crash into one of four buckets.

• regression: a file in the top frames was modified in the last 30 days, and this issue_id is new
• known_open: the same issue_id has appeared three or more times in the last 90 days
• external: the top frame lives in vendor code (Firebase, FBSDK, OS APIs)
• device_specific: 80 percent or more of occurrences cluster on one device or OS version

Classification uses Antigravity's codebase search and git log tools. The prompt explicitly demands a 30-day blame for the suspected file, attaching the latest commit author and date to the JSON output.

// agents/classifier/prompt.ts
export const CLASSIFIER_INSTRUCTIONS = `
You are a triage classifier for mobile app crashes.
For each crash, output one of:
  - "regression": file modified within last 30 days AND not previously reported
  - "known_open": same issue_id reported 3 or more times in last 90 days
  - "external": top frame in vendor SDK (Firebase, FBSDK, etc.)
  - "device_specific": occurs in 80% or more of same device or OS
 
Append a priority_score 0-100 weighted by:
  - regression: base 70
  - known_open with recent volume spike: base 60
  - external: base 20
  - device_specific affecting current OS: base 50
 
Multiply by app weight (provided in input) for revenue-bearing apps.
Use codebase-search to verify file existence before classifying as regression.
`;

The trap here is that a new agent will conflate "last 30 days of commits" with "last 90 days of reported issues." Make the prompt explicit: if git log --since="30 days ago" -- <file> returns nothing, lean toward known_open rather than calling it a regression. This single clarification cut misclassification noticeably in my runs.

The app-level weight is where I encode the operational priority. Apps where AdMob revenue is significant get a 1.5x weight; apps still in early launch get 0.8x. The result is that the top of the queue reflects what hurts the business most, not what produces the most raw crash counts.

Repro Agent: draft and run repro scripts in a simulator

For the top five crashes, the Repro Agent drafts a script and runs it under xcodebuild test on iOS or ./gradlew connectedAndroidTest on Android. A repro is considered solid only when the crash reproduces three times in a row.

# agents/repro/runner.py
import subprocess
from pathlib import Path
 
class ReproResult:
    REPRODUCED = "reproduced"
    FLAKY = "flaky"
    NOT_REPRODUCED = "not_reproduced"
    SKIPPED = "skipped"
 
def run_ios_repro(script_path: Path, scheme: str, timeout: int = 300) -> dict:
    """Run an iOS repro three times and decide stability."""
    successes = 0
    failures = 0
    for attempt in range(3):
        try:
            res = subprocess.run(
                ["xcodebuild", "test",
                 "-scheme", scheme,
                 "-destination", "platform=iOS Simulator,name=iPhone 15",
                 "-only-testing", str(script_path)],
                capture_output=True, text=True, timeout=timeout,
            )
            # A crash repro test is supposed to fail.
            if "Test Suite 'All tests' failed" in res.stdout:
                successes += 1
            else:
                failures += 1
        except subprocess.TimeoutExpired:
            failures += 1
 
    if successes == 3:
        return {"status": ReproResult.REPRODUCED, "successes": 3}
    if successes >= 1:
        return {"status": ReproResult.FLAKY, "successes": successes}
    return {"status": ReproResult.NOT_REPRODUCED, "successes": 0}

Three consecutive successes earn the REPRODUCED label. One or two count as FLAKY and force human review downstream. Treating flaky carefully matters in production because a crash that reproduces inconsistently will leave you wondering whether the patch actually fixed it.

A note for indie developers: do not insist on simulator repro for everything. Crashes triggered by device memory pressure or by real-world network latency will never reproduce in a simulator. When the Repro Agent emits NOT_REPRODUCED, it must include the reason so the next stage can switch into a more cautious patching mode.

Patch Agent: a minimal patch plus a regression test

For crashes the Repro Agent confirmed, the Patch Agent produces a minimal patch and an accompanying regression test. This is where Antigravity's strength at codebase-wide diff preview pays off the most.

# agents/patch/prompt_builder.py
import json
 
def build_patch_prompt(crash: dict, repro: dict) -> str:
    """Build the patch prompt for a reproduced crash."""
    return f"""
ROLE: You are a senior iOS/Android engineer working with a 12-year indie developer.
 
CRASH:
{json.dumps(crash, ensure_ascii=False, indent=2)}
 
REPRO:
- script: {repro['script_path']}
- status: {repro['status']}
- successes: {repro['successes']} / 3
 
REQUIREMENTS:
1. Produce a minimal patch that makes the repro script pass (i.e., no crash).
2. Add a regression test in the same module as the crashing file.
3. DO NOT change unrelated public APIs.
4. DO NOT introduce new third-party dependencies.
5. If the fix requires architectural changes, output a "needs-discussion" marker instead of code.
 
OUTPUT FORMAT:
- patch: unified diff
- test: full new test file content
- risk_level: "low" | "medium" | "high"
- rollback_note: 1-2 sentences describing how to revert
"""

I always require risk_level and rollback_note in the output. PR Agent uses both to decide whether the patch is an auto-approve candidate or whether a human must look at it before merge.

Without a strong constraint, the patch agent loves to sneak in unrelated refactors. Bolting DO NOT change unrelated public APIs to the prompt brought the diff scope back to the actual fix. From 12 years of indie work I learned that refactoring and bug fixing should never share a PR — that single rule has prevented more incidents than any tool I have used.

PR Agent: where the human review boundary lives

The PR Agent calls the GitHub REST API and opens a Draft PR. The core of the design is the rule that decides whether the patch goes into the auto-approve-candidate lane or the human-review-required lane.

# agents/pr/decision.py
def decide_review_mode(patch: dict, crash: dict, app_meta: dict) -> str:
    """Auto-approve candidate only when all three conditions are met."""
    if patch["risk_level"] != "low":
        return "human_review_required"
    if app_meta["monthly_revenue_jpy"] > 100_000:
        return "human_review_required"
    if crash["app_version"].endswith(".0"):  # the first dot-zero is dangerous
        return "human_review_required"
    return "auto_approve_candidate"

Even in auto-approve mode, I do not actually auto-merge to main. The PR Agent simply moves the Draft PR to Ready for Review and pings Slack with an auto-approve-candidate tag. The merge button is always pressed by a human.

This is obvious once you think about the regression cost on the apps that carry the revenue. Capturing one extra merge per day matters less than preserving one month of release quality. I am willing to wait the extra day.

When the PR Agent moves a PR into the human review lane, it asks a separate runbook agent to attach a comment summarizing similar past incidents. Reviewing crashes late at night is mentally taxing, and even a small reduction in cognitive load makes a real difference.

Two weeks of production numbers

I ran this pipeline through the first two weeks of May 2026 and compared the numbers to the previous two weeks when a single Antigravity agent was handling everything end to end.

The biggest single win is the jump in auto-reproduced crashes from 11 to 38 percent. The Repro Agent's narrow focus lets it spend all its context on the repro task, and once a crash is reproduced it can be patched the same day. The auto-reproduction percentage is, in practice, the upper bound on "how many crashes I can close today."

Beyond the numbers, the qualitative change is that my #crashlytics Slack channel quietly updates around 7am with Draft PRs sorted into auto-approve-candidate and human-review-required buckets. Walking to the coffee machine and coming back to a tidy queue is a different experience than the mornings I used to spend chasing crashes by hand.

Indie developer takeaways

A few notes if you want to build the same pipeline.

The smaller each agent's scope, the easier the pipeline is to debug. Knowing which stage failed at a glance is what keeps the system maintainable over months. Greedy agents that try to own three responsibilities become unmaintainable after a few iterations.

Decide the human review boundary along two axes: revenue impact and reproducibility confidence. Apps that materially move the monthly P&L deserve a human eye on every patch, regardless of how low-risk the agent claims the change is.

Lock the input and output of each agent to a JSON schema and persist every payload to logs. Months later, when you tune an agent's prompt, you will need to replay old payloads against the new prompt and diff the outputs. That replay capability disappears if the boundaries are not stable.

The next thing I want to try is wiring the Patch Agent into staged rollouts (10%, 50%, 100%). Medium-risk patches would auto-deploy only to the first stage, with the full rollout held for human approval. That would extend the auto-approve lane safely without giving up the production safety net.

Morning crash triage steals creative time from indie developers if you let it. Splitting the work across narrow sub-agents is one practical way to take that time back. If you are running a similar setup, I would love to hear what works for you.