When to Hand Your Agent the Next Instruction: Waiting, Interrupting, and Queuing, Measured
Antigravity v2.3.0 added message queuing and Send Now. I measured waiting, interrupting, and queuing against the same yardstick, found that 41% of queued instructions arrive stale, and cut rework from 22% to 9% with a twenty-line stamp.
The agent was working through a file, and I was watching. Maybe two more minutes to go.
In those two minutes, I thought of the next thing I wanted done. I knew I should wait. My hands sent it anyway. The plan the agent had built up collapsed, it started reasoning from scratch, and I ended up slower than if I had simply sat still. This happened often enough that I stopped calling it bad luck.
Antigravity v2.3.0 (released 2026-07-13) added message queuing, which gives those two minutes a third option. You can stack the next instruction while the agent works, or reach for Send Now when you really do want to cut in.
At first it looked like waiting had lost its reason to exist. Then I started queuing, and noticed something. An instruction you queue gets a little older on the way.
Three handoffs, one yardstick
Let me be precise about what I compared.
Method
What happens
Available in
Wait
Let the response finish, then type the next instruction
All versions
Interrupt
Send mid-run and force a replan on the spot
All versions / Send Now in v2.3.0
Queue
Stack it; it runs once the current work completes
v2.3.0 and later
Judged by feel, waiting always loses. The gut says waiting is the slow option, so I stopped trusting the gut and tracked two numbers instead.
Effective wait time — from the moment I think of the instruction to the moment its result is in my hands. Not the moment I'm allowed to press send. Conflate those two and interrupting looks artificially fast.
Rework rate — the share of results I couldn't keep. As an indie developer shipping my own apps, this is the number that actually costs me something. Every redo comes out of tomorrow.
The method was unglamorous: note the time I thought of it, note the time the result came back, mark keep or discard. By hand. I tried automating the keep/discard judgment and the criteria drifted within a day.
One asymmetry worth stating plainly. Waiting and interrupting cover roughly six weeks, from late May through July 12, across 214 follow-up instructions. Queuing covers three days — v2.3.0 rolls out in stages and only just reached my machine — across 90 instructions. Treat the queuing numbers as provisional.
Why interrupting looks fast and isn't
Here is what came out.
Method
n
Effective wait (median)
Rework rate
Wait
131
6m 05s
6%
Interrupt
83
7m 48s
31%
Queue (no stamp)
90
5m 12s
22%
Interrupting has zero wait before you can send. It still lands 1m 43s behind waiting by the time a usable result exists.
Two costs stack up. The first is the replan: the agent drops the plan in flight and rebuilds one that accommodates the new instruction. Median cost, 2m 40s.
The second is abandoned work. A file sits half-rewritten, and the next step treats that half-rewritten state as the ground truth. More than half of the 31% rework traced back to the agent grabbing a mid-edit state and building on it.
Queuing removes both. It also came in 53 seconds ahead of waiting, and — harder to quantify but real — it lets me put the thought down and keep my own focus.
And yet 22% rework. That's the part worth digging into.
✦
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
✦Three ways to hand off an instruction, measured against the same two numbers: effective wait time and rework rate
✦41% of queued instructions ran against a HEAD that had already moved — plus the 20-line script that makes the agent notice
✦Rework dropped from 22% to 9%. The three conditions that call for Send Now, and the one-word test for whether an instruction is safe to queue
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.
A queued instruction runs after the current work finishes. Obvious. The catch is that I have no idea what the world looks like at "after."
A concrete case. I queued: "make retryCount in src/lib/queue.ts read from config." When I queued it, that file and that variable existed exactly as described.
Three minutes later, the in-flight work had finished splitting queue.ts apart. retryCount now lived in src/lib/queue/policy.ts. The agent dutifully looked for queue.ts, didn't find it, created a fresh queue.ts, and put retryCount in it. A perfect duplicate definition.
The agent did nothing wrong. I handed a three-minutes-ago world to a three-minutes-from-now agent.
Going back through all 90 queued instructions: 37 of them (41%) executed against a HEAD that had moved since queuing. 20 of those actually broke, which accounts for almost all of the 22%.
So the weak point of queuing isn't the agent's comprehension. It's that the instruction carries no statement of its own assumptions. Between people, "that file we were just looking at" resolves fine. To an agent three minutes downstream, it doesn't resolve at all.
Stamp the assumptions onto the instruction
The fix was almost disappointingly small. Before queuing, write the current repo state into the instruction body.
#!/usr/bin/env bash# queue-note.sh — attach "what I assumed when I queued this" to an instruction# usage: ./queue-note.sh "make retryCount read from config"set -euo pipefailINSTRUCTION="${1:?pass the instruction text as an argument}"BRANCH="$(git rev-parse --abbrev-ref HEAD)"HEAD_SHA="$(git rev-parse --short HEAD)"DIRTY_COUNT="$(git status --porcelain | wc -l | tr -d ' ')"STAMP="$(date -u '+%Y-%m-%d %H:%M:%S')"cat <<EOF${INSTRUCTION}--- assumption stamp (queued at ${STAMP} UTC) ---branch: ${BRANCH}HEAD: ${HEAD_SHA}uncommitted changes: ${DIRTY_COUNT}Before you start, compare the current HEAD against ${HEAD_SHA}.If it has moved, this instruction was written against a stale world.Do not execute it as written. Ask once, in this shape:"Assumptions changed (${HEAD_SHA} -> current SHA). <summary of what moved>. I think you meant <inferred intent> — should I proceed?"---EOF
Paste the output into the queue. Under twenty lines, and it moved more than I expected.
After the stamp (July 14–16, n=44)
Measure
Before (n=90)
After (n=44)
HEAD had moved at execution time
41%
39%
Rework rate
22%
9%
Agent asked before executing
0%
25%
The staleness itself barely budged. Of course it didn't — a shell script doesn't stop the world from moving.
What changed is that the agent stopped guessing quietly. A quarter of the time it came back and asked. Answering a one-line question is far cheaper than discovering a duplicate definition two commits later and unpicking it.
The 9% that remains is the kind of drift a stamp can't see: the file didn't change, but what it meant did. I don't have a mechanical answer for that one yet.
Three conditions that call for Send Now
Once queuing works, the temptation is to queue everything. Some instructions must not be queued. Three days in, three conditions stand out.
1. When stopping the current work is the whole point. "That approach is wrong, stop" is meaningless in a queue — by the time it runs, the thing you wanted stopped has finished. Send Now.
2. When the current run is visibly broken. Output has gone off the rails, or it's looping. Waiting only buys more waste. I used Send Now 11 times in three days; 7 of them were this.
3. When the instruction doesn't depend on how the current work turns out. "Update the CHANGELOG when you're done" is safe to queue. "Test the thing you just fixed" is not — the thing just fixed is exactly what's still moving.
The third one is the real trap, because it looks safe. Every "that," "the one you just," and "earlier" in your instruction is a pronoun that cannot resolve without a stamp.
So here's the test I use now. Before queuing, hunt through your own sentence for pronouns and rewrite them as proper names. If you can, queue it. If you can't, that instruction belongs to the work in flight — wait.
When versions don't line up
v2.3.0 ships in stages. It can take days to reach a given machine, and while writing this I still had environments sitting on v2.2.1.
Since queuing changes the procedure, I branch on it inside my automation.
#!/usr/bin/env bash# antigravity-version-probe.sh — detect the local version, branch on capabilityset -euo pipefail# Read the version string via CLI; empty where it can't be readRAW="$(antigravity --version 2>/dev/null || true)"VER="$(printf '%s' "$RAW" | grep -oE '[0-9]+\.[0-9]+\.[0-9]+' | head -1)"if [ -z "$VER" ]; then echo "version-unknown: treating queuing as unsupported" >&2 echo "QUEUE_SUPPORTED=0" exit 0fi# Is it >= 2.3.0? Let sort -V decide; don't hand-roll version comparisonLOWEST="$(printf '2.3.0\n%s\n' "$VER" | sort -V | head -1)"if [ "$LOWEST" = "2.3.0" ]; then echo "QUEUE_SUPPORTED=1 (detected ${VER})"else echo "QUEUE_SUPPORTED=0 (detected ${VER} — use Send Now / sequential sends)"fi
sort -V does the comparison because I once compared 2.10.0 against 2.9.0 as strings and got it backwards. Version comparison is not worth writing yourself.
When detection fails, I fall back to "unsupported." Assuming a queue that isn't there makes instructions vanish. Assuming no queue on a machine that has one only costs a little speed. Fall toward the side that doesn't break — the same principle I lean on everywhere else in this setup.
Back to the two minutes
Three days of data is thin, but this is where my workflow landed.
Thought arrives. Try rewriting its pronouns as proper names. If that works, run it through queue-note.sh and stack it. If it doesn't, the instruction is entangled with work in flight — wait. Send Now only to stop something.
Since routing every thought through that fork, the restlessness of those two minutes has faded. Back when it was wait-or-interrupt, waiting felt like self-denial. Now waiting has a reason, and so does queuing.
Shipping apps alone, a single redo pushes tomorrow's plan sideways — the App Store release you meant to cut this week slides to next. So a twenty-line script that takes rework from 22% to 9% isn't really a speed story to me. It's a tomorrow story.
If you want to try this, start by counting. For one week, count how many times you interrupt a working agent. Near zero, and queuing buys you nothing. Past ten, and it's worth keeping queue-note.sh around and stamping what you stack.
I'm early in this myself — 90 and 44 aren't enough to call it settled. I'd like to re-measure with the same yardstick in a month and report back on where these numbers land. Thank you for reading.
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.