Using Antigravity's Retry Feature Wisely — A Smarter Way to Resume Failed Agent Runs

When an Antigravity agent stalls mid-run, is your first reflex to hit the Retry button?

I used to do the same thing. But retrying the same task with the same context almost always fails in the same spot. Retry is not a slot machine reroll — it is a tool for resuming an agent run after you have identified and addressed one likely cause of failure. Once you internalize that distinction, your success rate per token of spend starts to look very different.

This article walks through the decision rules and concrete steps I use in my own daily agent work, with examples you can apply immediately.

What Retry actually does

Antigravity's Retry resumes the previous agent run with the same context. Conversation history, loaded files, and prior tool-call results are all preserved. What gets re-executed is only the next step after the failure point.

This is easy to misread. Suppose the agent failed during a file edit. Retry does not blindly run the same edit again. Instead, the agent reviews the failure log and reconsiders the next action from scratch. In other words, the reason for the previous failure — a broken test, a tool timeout, a parser error — is now part of the information the agent reasons over.

That is why Retry works well in these situations:

• Transient network errors or rate limiting on third-party APIs
• Tool-call timeouts caused by a slow upstream service
• Tests that happened to fail because a dependency was briefly unavailable
• The agent was cycling between a few similar options and needed a nudge
• A file write that collided with a lock held by another process

It does not help when:

• The requirements themselves are vague and the agent is going in the wrong direction
• The external documentation URL it is referencing is out of date
• It is pinned to the wrong version of a library or SDK
• The agent lacks permission or a credential it genuinely needs
• The task itself is ambiguous and has two valid interpretations

In these cases the fix is not Retry — it is context.

Three preparation patterns that make Retry actually work

I almost always perform one action before pressing Retry. That one step usually doubles the success rate, and it takes less than thirty seconds.

Pattern 1: Send a single supplemental message

This is the most effective move. If you know something about why the agent is stuck, send a one-message hint and then hit Retry.

// Example: the agent kept timing out on an API request
This endpoint is routed through the EU region and has high latency.
The default 3-second timeout is usually not enough.
Please set the requests.get timeout to 15 seconds and try again.

A single line like this is often enough to pivot the agent toward a fix that raises the timeout. The key is to describe the specific hypothesis you have about the failure, not a vague instruction like "try harder." The more your hint resembles a code-review comment that you would leave for a teammate, the more useful it becomes.

Pattern 2: Re-attach reference files by hand

As a run progresses, files loaded early on get pushed out of the agent's working context. Antigravity summarizes intelligently, but the fine details are not always retained.

When the failure is about a specific detail in a file — a type definition, a schema, a config — re-attach that file with the @ syntax right before you Retry. Just doing this raises the success rate noticeably. It also works well when the agent is producing code that references fields that no longer exist in the schema: re-attaching the current schema gives it ground truth again.

Pattern 3: Roll back to a Checkpoint first, then Retry

Sometimes Retry alone is not enough, but you want to keep the conversation history intact. This is where Antigravity's Checkpoints feature pairs nicely with Retry.

1. Roll the working tree back to the last Checkpoint before the agent started
2. On the chat side, rephrase the task or add an extra constraint
3. Then run again

This gives you a clean code state plus everything the agent has already learned from the conversation. It is my go-to move during long sessions that start drifting: the filesystem becomes a known-good baseline, but the reasoning the agent built up during the session is not thrown away.

Retry and credits — a cost-aware approach

Pressing Retry without limits burns through credits quickly. Here are the three guardrails I use:

• Stop retrying after 3 consecutive failures on the same task — the root cause is on the context side
• Decide a Retry budget up front per task (for example, a maximum of 5)
• If the same kind of failure appears twice in a row, step in as a human instead of retrying

The third rule is the most important. A useful rule of thumb is "if the same error occurs twice, suspect the setup." For example, if ModuleNotFoundError appears twice in a row, the virtual environment or interpreter path itself is probably wrong. Pressing Retry five more times will not change that. The credits you spend on additional retries in such a state are essentially wasted: you are paying for the agent to repeatedly discover the same wall.

It helps to think of Retry as a small experiment. Each press is a hypothesis test. If you are not changing the inputs — either through a new message, a re-attached file, or a Checkpoint rollback — you are running the same experiment and expecting a different outcome.

For a deeper treatment of failure handling, pairing this with the Antigravity Checkpoints & Rollback deep dive is worthwhile. Designing failure and recovery as a single unit is how agent-driven workflows become stable in practice.

When not to Retry at all

There are situations where Retry is the wrong choice, and you should reach for a different tool instead.

• The agent keeps rewriting the same function in a loop → start a fresh chat and clarify the spec
• An error stems from a missing credential or environment variable → fix the environment first
• The agent has clearly misunderstood the requirement → throw out the conversation and redo the spec
• You notice the agent making increasingly contradictory claims about the codebase — this usually means its context has been polluted and starting fresh is safer

When the agent's state feels "spoiled," starting over in a new session is cheaper than patching it with more retries. My personal rule: if I have retried five times in one conversation, I rewrite the requirements in my own words and begin a new session.

There is a related judgment call about session length. Agent sessions that run for hours tend to accumulate small misunderstandings that compound. If you find yourself reaching for Retry more often as a session drags on, that is a signal to pause, summarize where you are, and start a clean session with that summary as the initial context.

One small experiment for tomorrow

For your next real task, try this: before you press Retry, write one sentence explaining — in your own words — why you think the agent is stuck. Drop that sentence into the chat, then hit Retry.

That single habit will noticeably shift the way Antigravity behaves for you. An agent's behavior is largely shaped by how cleanly you package the information you pass to it. Retry is best treated as a short feedback loop for testing that packaging, not as a way to let the agent try the same thing again. If you want to see this mindset applied at larger scale, Practical Patterns for Antigravity Multi-Agent Design is a natural next read.