You ask the agent to "fix the login flow," and five minutes in, you watch it create files you have never seen before. Should you hit Stop? And if you do, what state will your project be in afterward?
I run multi-agent flows in Antigravity every day, and that judgment call—stop now, or wait it out—has become one of the most frequent decisions in my workflow. Early on I would just slam the Stop button whenever something looked off, and I kept ending up with half-saved files, dangling untracked files, and checkpoints that no longer mapped to a clean state. The way you stop matters as much as when.
This article walks through the workflow I now use: how to spot when an agent has gone off course, how to interrupt it safely, what to check immediately after, and how to resume without dragging the broken context forward. If you want the deeper question of why agents go off the rails in the first place, see Why Antigravity Agents Run Away and How to Stop Them. This piece focuses on what to do once the run is already in motion.
Three Signs That Tell You to Stop in Five Seconds
I have boiled the "stop or wait" decision down to three signals.
Signal 1: The same tool is being called three times in a row with the same arguments.
For instance, read_file("src/auth.ts") fires three turns in a row, or grep keeps using the same query. This is the early stage of a tool-call loop, and it does not unstick itself. Stop without hesitation.
Signal 2: The plan and the implementation are out of sync. The agent opened by saying "I will use JWT," but five minutes later it is writing session cookies. If you let this continue, you pay later in the form of "is this implementation the real one, or leftover scaffolding from the wrong path?"
Signal 3: It started writing to files you did not want it to touch.
Rewriting package-lock.json, regenerating an entire config file, modifying migrations—these are not permission issues, they are signs that the agent has misread your project's invariants. Stop and re-anchor the instructions.
If none of these signals are present—the tool calls are progressing, the plan and implementation match, the file targets look reasonable—it is usually worth letting the agent finish, even if it feels slow. The "thinking time" is rarely as wasted as it looks.
Three Ways to Interrupt, in Order of Severity
You have effectively three options for stopping an agent in Antigravity. They differ in side-effect cost, so I try them in order.
The Stop Button (the gentle option)
The Stop button at the bottom-right of the chat ends the agent's current turn cleanly. It waits for the in-flight tool call to complete before halting, so file writes do not get truncated mid-flush. Checkpoints from the previous turn stay valid, which makes resumption straightforward.
For Signal 1 (early-stage tool loops), this is what I reach for first. No drama, no broken state.
Cmd/Ctrl+. (the same thing, faster)
The keyboard shortcut Cmd+. on macOS (Ctrl+. on Windows) does exactly what the Stop button does. Useful when your hand is on the keyboard and the chat panel has scrolled out of view. Same behavior, same side effects.
Force-killing the terminal process (the nuclear option)
If the agent has spawned a long-running shell command—a runaway npm test, a script stuck in an infinite loop—open Antigravity's integrated terminal and hit Ctrl+C. This kills the command, not the agent.
The subtle gotcha: when the command terminates, the agent receives "command finished" as a result and decides what to do next. It often interprets a forced kill as a failure and starts trying alternative approaches. If you want the agent itself to stop too, follow Ctrl+C with the Stop button.
Three Things to Check Right After You Stop
The first ten seconds after you interrupt are the most important. Skip this and you will not understand the state you are about to resume from.
1. Unsaved file edits. Look at the sidebar for files marked with the unsaved-changes dot. The agent may have edited files without saving. Open each one and decide whether to save or discard. If a file looks half-rewritten, discarding is the safer call—you do not want to resume from a state where the build is already broken.
2. Git status.
Run git status in the terminal and read every line.
$ git status
On branch main
Changes not staged for commit:
modified: src/auth.ts
modified: src/middleware.ts
Untracked files:
src/lib/jwt-helper.ts
src/types/session.d.tsWalk through the list and decide which files match what you actually wanted. Anything that looks like agent improvisation gets git checkout -- or rm'd right now. Doing this triage immediately means you do not have to ask "did I ask for this file or did the agent invent it?" an hour later.
3. Checkpoint position. Open the Checkpoints panel and find the most recent checkpoint relative to the moment things went wrong. Antigravity creates checkpoints at agent-turn boundaries automatically, so the checkpoint just before the bad turn usually exists. Knowing it is there makes the next decision—resume vs. roll back—much easier.
Two Resume Strategies, and When to Use Each
How you resume depends on whether the agent was mostly on track or fundamentally off.
Strategy A: Same session, with a course-correction message
If the agent was heading roughly the right way and just needs a nudge, stay in the same chat. The context window already contains all the exploration it has done, and reusing that is faster than starting over.
The message template I use:
Stopping here. Keep X from what you just wrote — that part was correct.
Drop Y, that was unnecessary.
Now do Z next.
Spelling out "what to keep, what to drop, what to do next" in three explicit lines prevents the agent from being pulled back into the same mistake by its own prior context.
Strategy B: Roll back to a checkpoint and start a new session
If the agent was on a fundamentally wrong path, resuming in the same session usually replays the same mistake—the broken context is still influencing the next turn. In that case, I roll back to the checkpoint just before the bad turn and start a fresh chat.
Rolling back restores files but leaves committed Git history alone. After the rollback, run git status again to confirm the state matches what you expect.
When you start the new session, include one or two lines about the previous failure. That single hint dramatically reduces the chance of stepping on the same rake.
Implement the auth flow.
Last attempt: the agent mixed JWT and session cookies and ended up
with both half-implemented. This time, use JWT only.
For the mechanics of rollback itself, see Antigravity Checkpoints & Rollback Complete Guide.
Two Habits Before You Start That Make Stopping Easier
Everything above is reactive. The two habits below are preventative, and in my experience they make the difference between "interrupting is stressful" and "interrupting is routine."
Habit 1: Manual commit before risky work
Antigravity's checkpoints are convenient, but they are tied to Antigravity's internal state—they do not survive moving the repo to another machine, and they are slightly less robust than a real Git commit.
Before I hand the agent a sizeable task, I make a manual commit: git commit -am "Before agent: <task>". An empty commit is fine if there is nothing to stage. The point is to have a known-clean reset target. With that anchor in place, I never hesitate to hit Stop, because I know git reset --hard will get me back.
Habit 2: Tell the agent which files are off-limits
In AGENTS.md or Antigravity's project rules (Custom Rules), spell out files that should not be touched.
# Project rules
## Files the agent must not modify
- `package-lock.json` (I update dependencies manually)
- `migrations/*.sql` (DB schema changes need separate review)
- `.env.production` (production secrets)
## Write policy
- If editing one of the above is necessary, propose it in chat
before writing any code.Writing this once meaningfully reduces the rate of Signal 3 events. It does not eliminate them, but in my experience it cuts them by roughly two-thirds.
Closing — Stopping Is Practice More Than Skill
Knowing when to stop an agent is more about reps than about technique. Early on you tend to wait too long, hoping the agent will figure it out. Once you internalize the three signals and trust that your stop won't break anything, your daily throughput goes up noticeably.
Next time you are about to hand the agent a meaningful task, do one thing: make a manual commit first. That single anchor changes how comfortable you are with the Stop button, and the rest of this workflow gets much easier from there.