Undo That Rewinds Only the Conversation, and Messaging a Subagent Directly: Three Moments I Hesitated

The morning after I updated the app, one line in the changelog made me stop: undo can now rewind the conversation only.

It sounded handy. Then a second thought arrived. If only the conversation goes back, the files the agent already changed stay exactly where they are. Mix those two up, and you can keep working with a conversation that remembers one version of your project while the disk holds another.

This article walks through the two input-related additions in 2.19.1 by the moments where people tend to hesitate. One honest note first: I have not used either feature for long. So I will keep two things apart throughout, what the changelog states and the lines I draw in my own routine.

Reading the changelog and nothing more

The Antigravity 2.0 app v2.19.1, dated September 30, lists two items that matter here. I checked them as of October 8, 2026.

• You can send a message to a subagent directly from the message box.
• Undo can rewind the conversation only.

The same release also adds Markdown-to-PDF export and brings the window back when you click the tray icon on Windows and Linux. For day-to-day decisions, though, it is these two that need a policy.

That is the whole of what the changelog tells us. What happens to your files, or how a subagent's message reaches its parent, cannot be read from a single line. That part you have to verify yourself.

Moment one: you gave the wrong instruction

As an indie developer, I hit this all the time. I ask an agent to adjust the wording on a settings screen of my wallpaper app, and a few neighboring screens get touched as well.

There turn out to be two different things you might want back.

My rule is short. Let the conversation be rewindable as often as you like, and leave responsibility for the files to git. Because rewinding a conversation got lighter, the safety net on the file side is now my job.

Right before delegating, I run a small script that gives the current state a name.

#!/usr/bin/env bash
# agent-checkpoint.sh — name the working tree right before handing work to an agent
# Usage: ./agent-checkpoint.sh settings-copy
set -euo pipefail
 
label="${1:-before-agent}"
ref="refs/checkpoints/${label}-$(date +%Y%m%d-%H%M%S)"
 
# Point at uncommitted changes if there are any, otherwise at HEAD
sha="$(git stash create)"
[ -n "$sha" ] || sha="$(git rev-parse HEAD)"
 
git update-ref "$ref" "$sha"
echo "checkpoint: $ref ($(git rev-parse --short "$sha"))"

git stash create builds a commit that captures your changes without altering the working tree. Attach a ref name to it and you can diff against it or restore from it later.

# See what the agent changed, compared with the checkpoint
git diff refs/checkpoints/settings-copy-20261008-140000
 
# Restore tracked files to that moment
git restore --source=refs/checkpoints/settings-copy-20261008-140000 --worktree -- .

I chose this over a plain git stash because stashing empties the working tree and adds a step to get back. Keeping only a named ref means my work never pauses. One limit: brand-new untracked files are not restored this way. When a request might create new files, I read git status before handing it over.

Moment two: through the parent, or straight to the subagent

The second addition is messaging a subagent directly.

Here my own guesswork enters, so I will mark it as a line rather than a fact. The parent agent is the one coordinating subagents and holding the overall picture. How far a directly sent message reaches that picture is something I have not confirmed on my machine.

So I keep direct messages narrow.

• A small note that stays inside one subagent's task ("please keep that function name as it is")
• A light instruction that does not change the direction of the work

When I want to change direction, or make a call that spans several workers, I still go through the parent. Going direct is convenient, but it also skips the one who sees everything. Use the shortcut only when its effect on the whole stays small. Deciding that in advance cuts down how often I hesitate.

Moment three: three checks before you rely on either

I would avoid trusting a single changelog line on a real repository. In a throwaway repo, three checks are enough.

1. Create one small file and ask the agent to change a single spot.
2. Undo the conversation only, then read git status and git diff. See with your own eyes whether the file stayed changed or went back.
3. While a subagent is running, send it a direct message, and read the parent's next reply to see whether that message shows up in it.

If the third check shows the parent did not pick it up, there is no need to worry. Your line "direct messages are for small notes only" is then simply correct. If it did pick it up, you have evidence for using the feature a little more widely.

Keep the result as a short note with the version attached, such as "as of v2.19.1, it behaved like this." Behavior can change between versions, and a dated note saves you from re-deciding at every update.

What to do next

Start with the three checks in a throwaway repository. Once you know the results, count how often your own work actually calls for rewinding only the conversation.

I intend to hold on to one principle however many features arrive: files belong to git, and rewinding belongs to undo. With that split, a change in either one's behavior will not catch you off guard.