ANTIGRAVITY LABJP
Articles/Agents & Manager
Agents & Manager/2026-05-27Advanced

Record & Replay for Antigravity Agents — A Production Pattern to Reproduce Failures in 3 Minutes

How to deterministically replay a failed Antigravity Agent run offline, drawn from a month of running it across four production sites. Covers boundary recording, R2 + KV storage costs, PII masking, and a working TypeScript harness.

antigravity430agents126observability18record-replayproduction71debugging15

Premium Article

Put an autonomous agent into production and sooner or later you hit the same wish: if only I could see that failure again under the exact same conditions, I could fix it in seconds. Running four sites in parallel as a solo developer, that moment came up several times a week. Failures you cannot reproduce are, as a rule, failures you cannot fix — so I built a way to replay an agent's production run offline and deterministically. What follows walks through the design decisions, the code, and the real costs end to end.

A small Monday-morning oddity that logs couldn't explain

A few weeks ago, an automation that posts articles to Antigravity Lab started failing roughly one out of every three Sunday-night runs. GitHub would contain the first 60% of an article, then a string of empty section headings — possibly the worst kind of half-failure, because the symptom is identical from outside but the cause is somewhere deep inside the agent's loop.

When I opened the logs, the last utterance before the agent went silent was different every time. Once it was mid-tool-call. Once it was mid-stream of a model response. The only common thread was that the silence began near a moment of waiting on an external dependency — the model API, GitHub, or Cloudflare KV.

In other words, no amount of reading after the fact let me reconstruct what the agent had seen at that instant, or in what order events had unfolded. Failures you cannot reproduce are, as a rule, failures you cannot fix. This article describes the Record & Replay design I built to escape that situation.

Why "just read the logs" isn't enough

Failures in autonomous agents differ in nature from classic stateless request/response outages, for three reasons.

First, agent state is the accumulated product of nondeterministic interactions between model output and tool output. Even with the same input prompt, the order and phrasing of the model's tool calls drift slightly, and the tool returns drift with them.

Second, agents carry long-form context. Hand the Antigravity Agent Manager more than ten steps of work and your context window quickly grows into tens of thousands of tokens. It is utterly routine for the eventual failure to be rooted in a tool return seven steps earlier.

Third, external side effects often cannot be rolled back. A pushed commit, a created Stripe customer, a written KV key. In production, "just rerun it under the same conditions" is rarely available.

Record & Replay attacks all three at once. Concretely:

  • Record: during the production run, capture every input and output that crosses an external boundary — model, tool, time — as a structured trace.
  • Replay: load the trace and rerun the agent locally in a deterministic loop. External APIs are not invoked; recorded returns are served by stubs instead.
  • Bisect: slice the trace around the failure point and binary-search to find the originating step.

Thank you for reading this far.

Continue Reading

What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.

WHAT YOU'LL LEARN
A working TypeScript harness that lets you replay a failed agent run locally in under three minutes.
Real cost numbers (about ¥48 / $0.30 per month for four parallel sites) for a Cloudflare R2 + KV trace store, with TTL design.
Concrete pitfalls — PII masking, model determinism, timezone drift — surfaced from a month of real four-site operation.
Secure payment via Stripe · Cancel anytime

Unlock This Article

Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.

or
Unlock all articles with Membership →
Share

Thank You for Reading

Antigravity Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.

  • Copy-paste ready implementation code
  • New advanced guides published daily
  • $5/mo or $10 for lifetime access
View Membership →

Related Articles

Agents & Manager2026-05-29
Supervising Long-Running Antigravity Agents — Watchdog and Tiered Recovery
Eight weeks of running AdMob revenue optimization on Antigravity background agents revealed three quiet failure modes. Here is the watchdog plus tiered recovery design I landed on.
Agents & Manager2026-07-05
Protecting Your Agent Stack's Known-Good State with a Single Lockfile — Change-Budget Design for an Era of Simultaneously Moving Parts
When the IDE build, CLI, model, and dependencies all move at once, you can no longer tell which one caused a regression. Here is a change-budget design that pins your known-good state to one lockfile, with working code and operational logs.
Agents & Manager2026-06-17
Tracing Parallel Agents After the Fact: Observability with Structured Logs and Spans
Running multiple agents in parallel on the Antigravity 2.0 desktop makes it impossible to tell which one is doing what. I share an observability design that drops tangled print debugging for run_ids and spans you can trace afterward, with a solo-operator implementation and numbers.
📚RECOMMENDED BOOKS
Build a Large Language Model (From Scratch)
Sebastian Raschka
LLM Dev
Prompt Engineering for LLMs
Berryman & Ziegler
Prompting
AI Engineering
Chip Huyen
AI Eng
* Contains affiliate links
See all →